Timeline for How do defend CSRF against requests that pretend not to be browsers?
Current License: CC BY-SA 3.0
16 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Dec 9, 2016 at 5:44 | history | tweeted | twitter.com/StackSecurity/status/807098632617021440 | ||
Dec 7, 2016 at 23:20 | history | edited | Anders |
edited tags
|
|
Dec 7, 2016 at 23:19 | answer | added | Anders | timeline score: 3 | |
Dec 7, 2016 at 19:31 | answer | added | John Wu | timeline score: 1 | |
Dec 7, 2016 at 16:29 | comment | added | dandavis |
it's simple: don't use the UserAgent header for anything.
|
|
Dec 7, 2016 at 14:17 | comment | added | ineedahero | The question is: "how to defend CSRF against requests that pretend not to be browsers". Clearly, this is a concern about requests that originate from browsers but spoof the user-agent header to pretend not to be from browsers, and thereby pass through undetected. | |
Dec 7, 2016 at 14:16 | answer | added | ThoriumBR | timeline score: 1 | |
Dec 7, 2016 at 14:08 | comment | added | Matthew | No, it isn't... It asks about defending against CSRF attacks, which won't give access to the site. If not providing a referrer allows access to the site, that's a different issue, but it's not CSRF. | |
Dec 7, 2016 at 13:59 | comment | added | ineedahero | None of these answers address the actual question. Right now, the highest voted answer says: > If there is no browser, there is no attack. So just let the non > browsers through. That's true, but does not answer the question. In fact, it restates what was in the original question: > CSRF, however, is strictly a browser vulnerability, and any request that comes from a non-browser is "automatically" (and rightly so) > allowed through. The question was asking how applications can defend against attackers who abuse this behavior by pretending to not be browsers to get free access to the site -- | |
Dec 7, 2016 at 13:46 | answer | added | pineappleman | timeline score: 2 | |
Dec 7, 2016 at 13:13 | answer | added | SilverlightFox | timeline score: 3 | |
Dec 7, 2016 at 12:56 | review | Suggested edits | |||
Dec 7, 2016 at 13:09 | |||||
Dec 7, 2016 at 12:35 | comment | added | Mr. E | What kind of non-browser origined requests are you expecting? And why should it be protected against CSRF? | |
Dec 7, 2016 at 12:34 | comment | added | Matthew | In general, CSRF attacks only work if the request is sent with appropriate headers (cookies, auth headers, etc), which normally only happens in a browser. If they don't come with the other bits, they're not going to have much affect - it shouldn't be possible for an attacker to actually read the appropriate data to affect someone else's session. I'm guessing there is some other context here which isn't included in the question... | |
Dec 7, 2016 at 12:28 | review | First posts | |||
Dec 7, 2016 at 13:39 | |||||
Dec 7, 2016 at 12:28 | history | asked | user132711 | CC BY-SA 3.0 |