Allow disabling xsrf protection per an endpoint#58717
Allow disabling xsrf protection per an endpoint#58717mshustov merged 15 commits intoelastic:masterfrom
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) |
| return (request, response, toolkit) => { | ||
| if (disableProtection || whitelist.includes(request.route.path)) { | ||
| if ( | ||
| disableProtection || |
There was a problem hiding this comment.
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.
@joshdover what is the appropriate place to track v8 breaking changes after #40768 was closed?
There was a problem hiding this comment.
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.
NIT: can't this be inlined to remove the local var?
There was a problem hiding this comment.
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... |
azasypkin
left a comment
There was a problem hiding this comment.
Looks good overall, but I found one issue while testing with a real route. Thanks for the quick turnaround on this one!
azasypkin
left a comment
There was a problem hiding this comment.
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 .....
| 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.
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: falseserver.xsrf.whitelist. it meant to be used for IdP endpoints only, which we can switch toxsrfRequired: falseChecklist
For maintainers
Dev Docs
Route configuration allows to disable xsrf protection for destructive HTTP methods: