0

This is an unconventional approach of CSRF that I came across while doing the pentest for an Android mobile application. The original request is as follows (NB: Values have been edited):

POST /edit/ HTTP/1.1
User-Agent: example Android (22/5.1.1; 320dpi; 720x1280;
Accept-Language: en-US
Cookie: cookies
Authorization: Bearer LPT:2:bearertoken
LP-U-DS-USER-ID: 69837
LP-U-RUR: VLL
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: edit.example.com
Connection: close
Content-Length: 484

sLPned_body=SLPNATURE.{"_csrftoken":"KpQCVh7TYsfcSFS0PHP1zsiV1hxkjk3B","username":"tester123","first_name":"tester123+tester","userid":"69837","device_id":"android-456b04ea5a32050d","biography":"#tester\n#testing","_uuid":"2da6821d-c609 t-900c-9f6e-51as443280f5","email":"[email protected]"}

When performing a CSRF an attacker can't predict the values for CSRF token, since it is validated in the request and it is rejected with an error 'token missing' even if the token was present in the request. At this point I started playing with the headers and came to know that instead of the token it is validating the user-agent. At the time of CSRF request the user agent is as shown below:

Mozilla/5.0 (Linux; Android 5.1.1; LS-5014 Build/LMY47V; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/46.0.2490.76 Mobile Safari/537.36 example Android (22/5.1.1; 320dpi; 720x1280;

But if I change the User Agent as in the original request which is the user agent of the respective application,

Example Android (22/5.1.1; 320dpi; 720x1280; 

The token will accept any value and the request is returned with 200 response.

Is there any way so that I can override the user agent while I am performing CSRF? I have never seen such a scenario anywhere else or read about it.

1 Answer 1

3

No it's not possible to circumvent this CSRF-protection in a classical CSRF attack. Using the user-agent- header to submit the anti-CSRF-token is just like using any custom header, which is one of the currently preferred methods of CSRF-protection.

An attacker could only 'fake' the user agent via a XSS, or a malign browser extension (or browser). But in such a case the attacker wouldn't have to use a CSRF-attack to do what he wants, because XSS > CSRF.

I also found a related answer from 2016: How do defend CSRF against requests that pretend not to be browsers? Which concluded:

"The attacker can not succesfully modify the User-Agent header unless you allow her to do so."

4
  • 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 . Commented Jun 24, 2020 at 18:18
  • 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.
    – Elie Saad
    Commented Jun 24, 2020 at 19:04
  • @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. Commented Jun 24, 2020 at 19:55
  • 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.
    – Elie Saad
    Commented Jun 25, 2020 at 11:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .