Attacking Sites Using CSRF

From CSRF to user information leak, XSS and full account takeover.

Vickie Li
Vickie Li
Aug 16, 2019 · 4 min read
Image for post
Image for post
CSRF and turf. (Photo by Chensiyuan on Wikimedia Commons.)

The criticality of a CSRF vulnerability depends heavily on where the vulnerability is located. Sometimes, faulty CSRF protection mechanisms lead to inconsequential issues like unauthorized setting changes or emptying a user’s cart. Other times, they lead to much bigger issues: user information leak, XSS and even one-click account takeovers.

Here are a few cases that I have encountered in the wild of CSRFs leading to severe security issues. Often, these are a combination of CSRF and other minor design flaws.

CSRF sometimes causes information leaks as a side effect. Applications often send or disclose information according to user preferences. If these setting endpoints are not protected from CSRFs, they can pave the way to sensitive information disclosures. One way of achieving CSRF based info leaks is to play with these requests.

For example, a paid service on a web app that I have worked on sends monthly billing emails to a user-designated email address. These emails include the street addresses, phone numbers, and limited credit card information of the user. The email address to which these billing emails are sent can be changed via the following request:

POST /change_billing_emailREQUEST BODY:email=NEW_EMAIL &csrftok=12345

The CSRF validation on this endpoint was broken. The server accepts a blank token and the request would succeed even if the csrftok field is left empty. After making a victim send the following request, all future billing emails would then be sent to ATTACKER_EMAIL (until the victim notices the unauthorized change), thereby leaking the street address and phone numbers associated with the account to the attacker.

POST /change_billing_emailREQUEST BODY:email=ATTACKER_EMAIL &csrftok=

Self-XSS is almost always regarded by security teams as a non-issue because they are difficult to exploit. However, when combined with a CSRF, self-XSS can often be turned into a stored-XSS.

For example, on a financial site that I have come across, users are given the ability to create nicknames for each of their linked bank accounts. The account nickname field is vulnerable to self-XSS: there is no sanitization, validation or escaping for user input on the field. However, this is a field that only the authorized user can edit and see, so there is no way for an attacker to trigger the XSS directly.

Unfortunately, a CSRF bug also exists on the endpoint used to change the account nicknames. The application does not properly validate the existence of the CSRF token, so simply omitting the token parameter in the request will bypass CSRF protection. For example:

POST /change_account_nicknameREQUEST BODY:nickname=<XSS PAYLOAD> &csrftok=WRONG_TOKEN

This request would fail.

POST /change_account_nicknameREQUEST BODY:nickname=<XSS PAYLOAD>

While this request would successfully change the user’s account nickname, and store the XSS payload. The next time a user logs into the account and view her dashboard, the XSS would be triggered.

These are some of the easiest account takeovers that I have discovered. And these situations are not uncommon either. Account takeover issues occur when there is a CSRF issue in an account validating functionality like creating a password, changing the password, changing the email address, or resetting the password.

For example, here’s a bug that I have discovered in a client’s web app.

The web app allows social media sign-ups. And after a user signs up via social media, they have the option to set a password via the following request:

POST /password_changeREQUEST BODY:oldpassword= &newpassword=XXXXX &csrftok=12345

Since the user signed up via their social media account, no old password is needed to set the new password. So if CSRF protection fails on this endpoint, an attacker would have the ability to set a password for anyone who signed up via their social media account and has not set a password.

And unfortunately, that’s exactly what happened on this particular endpoint. The application does not validate the CSRF token properly and accepts an empty value as the csrftok parameter. So essentially, the following request will set the password of anyone (who doesn’t already have a password set) to ATTACKER_PASS.

POST /password_changeREQUEST BODY:oldpassword= &newpassword=ATTACKER_PASS &csrftok=

Now all an attacker has to do is to embed this request on pages frequented by users of the site, and she can automatically assign the password of any user who visits those pages to ATTACKER_PASS. After that, the attacker is free to log in as any victim with their newly assigned password.

CSRFs are super common and very easy to exploit. While the majority of CSRFs that I have encountered proved to be low severity issues, sometimes an oversight on critical endpoints can lead to severe consequences.

If you are a developer, pay extra attention to the CSRF protection mechanisms deployed on critical endpoints.

If you are a hacker, think about what role the functionality plays in the context of the entire application when you encounter a CSRF. How does the endpoint affect the rest of the application? How could you escalate the vulnerability based on that knowledge?

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Vickie Li

Written by

Vickie Li

Professional investigator of nerdy stuff. Hacks and secures. Creates god awful infographics. https://twitter.com/vickieli7

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Vickie Li

Written by

Vickie Li

Professional investigator of nerdy stuff. Hacks and secures. Creates god awful infographics. https://twitter.com/vickieli7

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store