-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow disabling xsrf protection per an endpoint #58717
Allow disabling xsrf protection per an endpoint #58717
Conversation
It meant to be used for IdP endpoints only, which we are going to refactor to disable xsrf requirement per a specific endpoint.
Pinging @elastic/kibana-platform (Team:Platform) |
Pinging @elastic/kibana-security (Team:Security) |
@@ -31,7 +31,11 @@ export const createXsrfPostAuthHandler = (config: HttpConfig): OnPostAuthHandler | |||
const { whitelist, disableProtection } = config.xsrf; | |||
|
|||
return (request, response, toolkit) => { | |||
if (disableProtection || whitelist.includes(request.route.path)) { | |||
if ( | |||
disableProtection || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that we added server.xsrf.disableProtection
in spalger#6 for testing purposes solely. I'm wondering if we want to collect all test-only API in the one document to have a better understanding of API surface in case of future refactoring. (in addition to --migrationgs.skip
, /internal/saved_objects/_migrate
etc)
if (has(settings, 'server.xsrf.whitelist')) { | ||
log( | ||
'It is not recommended to disable xsrf protections for API endpoints via [server.xsrf.whitelist].' + | ||
'It will be removed in 8.0 release. Instead, supply the "kbn-xsrf" header.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshdover what is the appropriate place to track v8 breaking changes after #40768 was closed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this doc: docs/migration/migrate_8_0.asciidoc
src/core/server/http/http_server.ts
Outdated
const kibanaRouteState: KibanaRouteState = { xsrfRequired }; | ||
|
||
this.server.route({ | ||
handler: route.handler, | ||
method: route.method, | ||
path: route.path, | ||
options: { | ||
// Enforcing the comparison with true because plugins could overwrite the auth strategy by doing `options: { authRequired: authStrategy as any }` | ||
auth: authRequired === true ? undefined : false, | ||
app: kibanaRouteState, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: can't this be inlined to remove the local var?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can, but I want to make sure that kibanaRouteState
implements KibanaRouteState correctly.
This declaration doesn't show an error for unknown properties, for example:
app: { xsrfRequired } as KibanaRouteState
ACK: reviewing... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, but I found one issue while testing with a real route. Thanks for the quick turnaround on this one!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, tested locally - worked perfectly!
Side note: maybe in the future we may not accept this option for "non-destructive" HTTP methods at compile-time so that xsrfRequired: true
on GET
wouldn't confuse API consumers, like you've done for body?: Method extends ....
.
@@ -147,16 +147,22 @@ export class HttpServer { | |||
for (const route of router.getRoutes()) { | |||
this.log.debug(`registering route handler for [${route.path}]`); | |||
// Hapi does not allow payload validation to be specified for 'head' or 'get' requests | |||
const validate = ['head', 'get'].includes(route.method) ? undefined : { payload: true }; | |||
const validate = isSafeMethod(route.method) ? undefined : { payload: true }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hapi doesn't support handlers for the head
method hapijs/hapi#795
* add xsrfRequired flag to a route definition interface * update tests * deprecate server.xsrf.whitelist It meant to be used for IdP endpoints only, which we are going to refactor to disable xsrf requirement per a specific endpoint. * update docs * do not fail on manual KibanaRequest creation * address comments * update tests * address comments * make xsrfRequired available only for destructive methods * update docs * another isSafeMethod usage
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* add xsrfRequired flag to a route definition interface * update tests * deprecate server.xsrf.whitelist It meant to be used for IdP endpoints only, which we are going to refactor to disable xsrf requirement per a specific endpoint. * update docs * do not fail on manual KibanaRequest creation * address comments * update tests * address comments * make xsrfRequired available only for destructive methods * update docs * another isSafeMethod usage
Summary
Closes #53823
This PR:
xsrfRequired: false
server.xsrf.whitelist
. it meant to be used for IdP endpoints only, which we can switch toxsrfRequired: false
Checklist
For maintainers
Dev Docs
Route configuration allows to disable xsrf protection for destructive HTTP methods: