4 ms·

> i'm not sure though how a bearer token would prevent CSRF. imo it's roughly the same as a session with a long expiration time. You said it yourself. Bearer

> i'm not sure though how a bearer token would prevent CSRF. imo it's roughly the same as a session with a long expiration time. You said it yourself. Bearer tokens have to be added manually, while cookies are automatic. So simply issuing a request to a backend will not include the bearer token, and you (as the attacker) have no way of actually gaining that token from your cross-site context.

stefs 4y ago
as far as i understand, that's not necessarily the case; a malicious CSRF triggers a completely valid request by tricking the user to open an url while logged in. imo the principle works for both sessions and token based auth as long as the token based auth frontend application exposes an url that triggers the action. ok, now that i think about it: providing an url that triggers the (malicious) action is a necessity for session based auth but only a possibility in token based auth.
- dwaite 4y ago
  XSRF is of the class of confused deputy problems; the site expects that the browser will only let the end-user that was authorized perform actions, but the reality is that the browser on its own has no concept of user choice or consent for web content. The hypermedia aspect means that content by third parties can by default initiate actions, which would override the first-party presentation by the site for user consent. So XSRF protections make it so that third party content cannot successfully initiate those actions. Prime examples are: - SameSite cookies, where the initial request from another domain will not have cookies presented. - The local content adding session-related parameters unknown to third parties, such as an OAuth access token in a header or a session cookie repeated as a form parameter. These protect against the third party being able to initiate actions and pick up any background implicit authorizations being provided by the browser, such as session cookies or HTTP Basic authorization headers.

stefs 4y ago

as far as i understand, that's not necessarily the case; a malicious CSRF triggers a completely valid request by tricking the user to open an url while logged in. imo the principle works for both sessions and token based auth as long as the token based auth frontend application exposes an url that triggers the action. ok, now that i think about it: providing an url that triggers the (malicious) action is a necessity for session based auth but only a possibility in token based auth.

dwaite 4y ago
XSRF is of the class of confused deputy problems; the site expects that the browser will only let the end-user that was authorized perform actions, but the reality is that the browser on its own has no concept of user choice or consent for web content. The hypermedia aspect means that content by third parties can by default initiate actions, which would override the first-party presentation by the site for user consent. So XSRF protections make it so that third party content cannot successfully initiate those actions. Prime examples are: - SameSite cookies, where the initial request from another domain will not have cookies presented. - The local content adding session-related parameters unknown to third parties, such as an OAuth access token in a header or a session cookie repeated as a form parameter. These protect against the third party being able to initiate actions and pick up any background implicit authorizations being provided by the browser, such as session cookies or HTTP Basic authorization headers.