Working with a client, I came across a CSRF vulnerability in their existing web application.

Working with a client, I came across a CSRF vulnerability in their existing web application. CSRF is a type of vulnerability where a request (POST) originates from a different domain (ORIGIN) than the target. For example, if the target is vulnerablesite.io and the attacker’s site is evilattacker.com, then the attacker would entice a member of vulernablesite.io to click a page on their site (evilattacker.com). The page that loads will attempt a POST to the vulnerable application, using the victim’s access. The POST will be crafted to do one action, but that action will likely be significant. It could be a POST request to change ownership of an account, create a user on an account, change the email address or login of the account, or reset the password.

What makes a CSRF attack work is a lack of an ORIGIN policy. Technologies like CORS and CSRF-Tokens try to resolve the issue by enforcing the same domain as the origin of all change requests. If a request is originating from a different domain, it should be dropped, ignored or error out.

I found that I could change ownership of an account (on my client’s web application) with a single POST. Compounded with a CSRF vulnerability, it allowed me to come up with a proof of concept that showed one account could take over another account.

I created an account on the client’s test environment. Their web application appeared to not have any CSRF token or mitigation in place.

Using Burp Suite, I captured the traffic via Burp Proxy, when a change of ownership was initiated. It was a single POST, without the need for the original owner to verify the switch.

After I had the POST data, I created a hidden form on a page, and set it up with the same fields, but with my own data on who the new administrator is.

Once the little script was complete, I hosted it on a test machine inside the client’s VPN and went to my test page. It loaded, flashed a redirect to the main web application on the target machine, and initiated the POST. I was now an administrator on the test account.

With the proof of concept in hand, the client patched the issues found.

This article assumes that you have permission to test a target with CSRF vulnerabilities, or you have a vulnerable VM to work with locally.

Almost any scanner (OWASP ZAP, etc.) will detect a lacking CORS or CSRF token, which in itself is not necessarily an indicator of vulnerability, but it does indicate further testing is required. Outside of an automated scanner, one can use the Burp Suite proxy.

Launch Burp Suite and click Proxy.

On the proxy screen, click the button to launch the Browser. This will spawn a Burp Suite Browser, which acts as a proxy and sends all requests back to Burp Suite for analysis.

Once the Burp browser is open, navigate to the target/test domain and then in Burp Suite click “Intercept” to turn it on.

Once Intercept is on, go to the test (target) domain and perform an action like logging in. With intercept on, we are stepping through each step of the requests, pausing after each one. Clicking “Forward” in Burp Suite moves the break point one more step. This allows us to see (and change) the request headers along the way.

During the handshake of a POST (such as performing a login request), note the headers and see if there is an “Origin: [target domain]” listed. If not, then there is likely a CSRF vulnerability that can be tested.

Pre-Requisites:

You have permission to test CSRF against the targetTarget domain that is vulnerable to a CSRF attackYour own host that can host a webserver

This article assumes one has the right to test CSRF on the target. Scope the target. Using a legit account, go through the account and look at all the actions you can do to your own account. Can you add users to it? Can you change ownership of it? Can you change the email address? Can you do a reset password without a email confirmation flow?

Your attack is like firing a single torpedo. Having only one shot, you want it to be effective at disabling the target.

Once you have discovered a single action/POST/DELETE, etc. to use on the test target, use Burp Suite to capture the request itself.

What is needed:

The URL the request is POSTed toThe variables and values of the request

The above data is necessary to craft the attack. Opening an editor of choice, create a new HTML file on a hosted domain within reach of the target. If the target is in a test env. behind the VPN, set up a test web host in the VPN as well. The HTML page hosted will have a hidden form that posts to the the target, sending hidden fields for all the variables required for the POST.

If, for example, the POST passed variables of fname, lname, username, pass, and newuser_email, then a form could be created like so:

<form action="https://[the vulernable site]/useradmin/adduser" method="POST">
<input type="hidden" name="fname" value="Naughty" />
<input type="hidden" name="lname" value="User" />
<input type="hidden" name="username" value="naughtyuser" />
<input type="hidden" name="pass" value="passwwwword" />
<input type="hidden" name="newuser_email" value="naughtyuser@evilattacker.co.uk.you.get.the.idea" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>

Once the victim in this test loads that form, it will initiate a post to the test target. If their session has been logged out, they’ll get a login screen, and if they login the POST will auto happen. If their session is still live, then the page will load and redirect to the application and the POST will be delivered.

The script tag below the form will ensure that the submit action occurs without user input. Just landing on the page triggers a submit.