Timeline for Why is CSRF protection only applicable to web services with browser clients?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 19, 2021 at 22:18 | comment | added | Kevin | @Peteris: If it's on the same domain as something else (which is targeted at browsers), then cookies will be reused. Those cookies might or might not give rise to CSRF attacks. I did not say that a CSRF attack necessarily exists, only that the form or endpoint should be evaluated to determine whether or not an attack exists. | |
| May 19, 2021 at 22:16 | comment | added | Peteris | @Kevin if it's not used by legitimate users through a browser, then noone's browser ever has a stored cookie that might be stolen/reused with a CSRF attack. If a browser is fooled into making a cross-site request, it would be identical to whatever an attacker could make directly; you could steal an user's browser session if one existed, but the point is that such sessions don't exist in this case. | |
| May 19, 2021 at 20:09 | history | edited | Douglas Leeder | CC BY-SA 4.0 |
Emphasis that the service must be non-browser exclusive before disabling the protection.
|
| May 19, 2021 at 17:05 | comment | added | Joshua | It's actually kind of wrong. Just because it's meant to be called by something else doesn't mean a CSRF attack doesn't exist (stealing login from some other web app on the server to log into this endpoint). | |
| May 19, 2021 at 9:23 | vote | accept | hotmeatballsoup | ||
| May 19, 2021 at 7:05 | comment | added | slebetman | .. If your API is accessed via an app or a hardware device then there is no UI for the user to login to your site and usually (with the exception of you displaying your page in a Webview - which is after all an embedded browser) there is no javascript engine to execute 3rd party scripts. So unless it's a browser CSRF is not useful | |
| May 19, 2021 at 7:03 | comment | added | slebetman | One example, your website depends on cookies to maintain login session. User logs in to your website. An attacker injecting some javascript (via comments, some library you use, hacking your webserver etc.) can now make requests for the user's personal information because the browser will automatically attach the cookie to any request to your URL (so all requests, even those not made by you or your user, are logged in). This is CSRF. Obviously this only happens because the code is running in a browser.. | |
| May 18, 2021 at 21:59 | comment | added | Kevin | Note however that a form (or HTTP POST endpoint) which is designed for a non-browser client may still be accessible to a browser client. Your threat model should concern itself with whether a browser can be fooled into submitting a (valid) cross-site request, not with whether or not you intended for browsers to submit any requests at all. | |
| May 18, 2021 at 14:21 | comment | added | hotmeatballsoup | Awesome answer @Douglas (and +1!) and it mostly makes sense, but I'm a little fuzzy on what you mean when you say "CSRF protection relies on the server correlating something the browser sends automatically (the cookie) with something in the form (the token)". Any chance you could give me a specific (but simplified) example of a CSRF browser attack when CSRF protection is and isn't enabled? Seeing the comparison between the two (protection enabled/disabled) will probably fill in all the missing pieces for me. Thanks again so much! | |
| May 18, 2021 at 14:05 | history | answered | Douglas Leeder | CC BY-SA 4.0 |