What is Cross-Site Request Forgery?
Cross-site request forgery, also known as XSRF, is a web security vulnerability, where an attacker tricks the client, browser in this case, to perform malicious acts on a website unintentionally. More specifically, A XSRF attack forces a user to send a forged HTTP request to a web application.
Cross-Site Requests
Before we dive deeper into what a XSRF is, let’s focus on what a Cross-Site Request is first. Let’s say you’re browsing a website, and you come across an embedded video on that website. The video may appear to be on that website but it’s actually being embedded from YouTube. The website was able to request data from another website on your behalf. This normally isn’t an issue and can heighten a user’s experience on your web application. However, what if this request is authenticated via a session cookie? The web server receiving this request processes the client as authenticated because the session cookie says the user is authenticated. Now the trust between a server and user has been compromised.
Cross-Site Request Forgeries
Now it’s time to learn how to create our own XSRF! #hacker😈(USA Government, if you’re reading this, please don’t arrest me) So how exactly does a XSRF attack work?
Two things must happen to produce a XSRF attack:
1) The attacker tricks a logged in user into loading a page or clicking a link, when the user clicks the link, the script injected by the attacker runs.
2) The attacker sends a legitimate-looking HTTP request from the user’s browser. The website processes the request without distinguishing whether the request is sent by the actual user or the XSRF attacker.
Since cross-site requests don’t need permission, an attack can abuse this and send requests without the authenticated user’s consent.
Let’s create our own!
Let’s say our target is trying to change his password on a regular website. The underlying HTML form for this would look like the following:
<body>
<p> Input your new password </p>
<form action="/new_password" method="post">
<input type="text" name="password" placeholder="Change your password">
<button type="submit">Submit</button>
</form>
</body>
The method attribute of the form specifies that this is sending a POST request to the ‘/new_password’ route. So when the user presses the submit button, the data inputted in the form is sent to the ‘/new_password’ route.
Now let’s begin our forgery😈
Let’s copy the exact same form, but change a few things.
<form id="xsrf" action="http://example.com/new_password" method="post">
<input type="text" name="password" value="ImProHacker">
</form>
<script>
document.getElementById('xsrf').submit();
</script>
Now that we’ve got our form coded let’s put it on our malicious website.
document.getElementById('xsrf').submit();
The code above is finding the element with the id “xsrf”, which in this case is our form, and is submitting it. Let’s walk through what’s happening when the form gets submitted. The form request is going to the same exact website where the legitimate form was posting it’s request at. Because the user’s browser has a current session id the original website won’t question where this request is coming from because the user is authenticated. This means the website will process the request, changing the victim’s password to “ImProHacker”. Now we have access to the users whole account and are able to do anything we want with it. (Let’s just hope no one catches us)
How can I stop this?
If you’re a web application developer this is really bad news for you. As long as a request is sent from a client with a session id, you’re accepting it. How can we stop this?
Well, think about it, how can you tell if this request is coming from a source you are authenticating? You’d have to have some form of identification on what requests you want to accept. That’s where unique tokens come into play. XSRF can be avoided by creating a unique token in a hidden field which would be sent in the body of the HTTP request. That way you can verify if every request sent to your server is authorized.
Conclusion
XSRF were really dangerous in 2017. Nowadays, most web frameworks will handle the authentication tokens for you automatically via helper methods. But it’s still recommended to be knowledgeable of these attacks and ways to prevent them, just incase you come across a framework that doesn’t offer this form of security.
More Information