3 ms·
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 i
by 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 agoXSRF 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.