Skip to main content

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