Timeline for CSRF Bypass using User-Agent
Current License: CC BY-SA 4.0
7 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 25, 2020 at 11:45 | comment | added | Elie Saad | I raised my question because there are some points discussed in articles and documentations describing what each browser does for the User-Agent header. After conducting some tests, Chrome refuses to set the header considering it unsafe, and Firefox sends the request with its own User-Agent header in an OPTIONS request, requesting the server to allow the user-agent header key to be allowed. Weird implementation, but secure by default. CSRF won't work in this way indeed. | |
Jun 24, 2020 at 19:55 | comment | added | Martin Fürholz | @ElieSaad Please checked the linked answer for an explanation why that won't work. Apart from that, a CSRF-attack does not work by setting the token to a "random value". The very thing this CSRF-protection does, is verifying that the correct CSRF token has been submitted. | |
Jun 24, 2020 at 19:04 | comment | added | Elie Saad | Looking at it, it's based on the user-agent being used. If someone recreates that attack using XHR they will be able to circumvent the CSRF token by setting any random value and replacing the user-agent. I failed to properly map this answer to the actual attack. If both of you could discuss this better to try and get a better grip on this. | |
Jun 24, 2020 at 18:18 | comment | added | Joel Deleep | So there is no point in mentioning the same in the final report , I was confused because the user agent header is not in the forbidden header list according to firefox documentation . | |
Jun 24, 2020 at 18:14 | vote | accept | Joel Deleep | ||
Jun 24, 2020 at 17:49 | history | edited | Martin Fürholz | CC BY-SA 4.0 |
added 223 characters in body
|
Jun 24, 2020 at 17:35 | history | answered | Martin Fürholz | CC BY-SA 4.0 |