CSRF : Introduction
CSRF means Cross-Site Request ForgeryWith that being said, let us see what is it to get an understanding of it so that we can exploit it
According ot OWASP, Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
So you can see how powerful this attack can be, of course when the web application is vulnerable, let's try to exploit it from the very basics, or you can say, from the ground up
Requirements1. A web browser (kinda obvious, right)
2. A web server (am using XAMPP)
3. DVWA
4. Mind (as I don't want you to just blindly reproduce everything said in the tut and getting no knowledge)
5. A proxy ( this is optional as it will allow you to see how your request is going and what is repsonse)
SetupJust setup DVWA and set its security to
LOW as we are starting and then move onto the CSRF section.
Here, you see an option to change your password, a regular password changing prompt, huh? Just enter a new password, type again to confirm and click on change (I used
trying as the new password), you'll see something like this.
Now see the URL, it has the request it sent to the server getting reflected in the URL bar of your browser (please note that this is not a case always but since it is showing here, we'll take the advantage of this) or otherwise you can pass the request from the proxy and see what is it requesting the server
Putting the hands in the mud : Beating Low SecurityIn the URL bar, change the
password_new=trying&password_conf=trying to
password_new=it_works&password_conf=it_works and submit it and you'll see your password got changed to
it_works. Yeah, I know this is the same what we did above but it was just to make sure you don't forget it
Now, think you are not a DVWA user but you need to change his password to
System7 and you know that it is vuln to CSRF and you also know the request (what was in the URL bar), so, let's see how you'll exploit it.
Make an HTML page with minimal code so as to accomplish the task.
Here is the source of my HTML page that I used.
<html>
<head>
<title>Change Password ;)</title>
</head>
<body>
<a href="http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=System7&password_conf=System7&Change=Change#">Click me ;)</a>
</body>
</html>
Here, we just constructed a URL that will change the password to System7. To get this executed, you can use social engineering and get the dumbass click on it and his password will change.
That was the
LOW security CSRF on DVWA. Now, we'll see how to evade a simple filter that is applied to make the web app secure but that doesn't makes it secure.
Getting deeper in mud Set the DVWA Security to
Medium and come back to CSRF again
Now if you try to change the password via that html file, you'll see an error.
As you can see, it says
That request didn't look correct. and you failed to change the password. We can take 2 approaches here, White box and black box but since we have access to source code, we'll take the white box approach. When you click on
View Source button, you see the source code and what actually tests the authenticity of the request is this line
// Checks to see where the request came from
if( eregi( $_SERVER[ 'SERVER_NAME' ], $_SERVER[ 'HTTP_REFERER' ] ) )
About
eregi function, it checks the occurrence of first string into the second string and returns the length of the matched string else returns FALSE.
I dunno what the fuck was wrong with my system today, I was unable to intercept the request or I would have shown you what was causing the problem.
Solution -> In the eregi function, we see that
$_SERVER[ 'SERVER_NAME' ], which is
127.0.0.1 in our case is being searched withing the
HTTP_REFERER field in the password changing request. Good thing is we can set this (or any header field calue on our own), but that is done in PHP, so we'll write a PHP file that will contain the following code:
<html>
<?php
header("Referer: 127.0.0.1");
?>
<a href="http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=Fucked&password_conf=Fucked&Change=Change#">Click me, I'll do it now ;)</a>
</html>
Save it as
do_it.php in your web root directory and open it.
Now click on the
Click me, I'll do it now and you'll see the password changed in the URL bar.
You can also verify this thing in your proxy
so, hope you guys got the basics of CSRF.
Any questions??
