A cross-site request forgery (CSRF) attack is one which forces authenticated users to perform unwanted actions on the web application they were authenticated to use. This is done using an external site the user has visited and which triggers the action.
In this recipe, we will obtain the information from the application to see what the attacking site needs do to be able to send valid requests to the vulnerable server. Then, we will create a page to simulate the legitimate requests and trick the user into visiting the page while authenticated. The malicious page will then send requests to the vulnerable server and, if the application is open in the same browser, it will perform the actions as if the user had sent them.
To perform this CSRF attack, we will use the WackoPicko application in vulnerable_vm: http://192.168.56.102/WackoPicko. We need two users, one will be called v_user, the victim, and the other one will be called attacker.
We will also need to have BurpSuite running and configured as a proxy in the web server.
- Log in to WackoPicko as
attacker. - The first thing the attacker needs to know is how the application behaves, so if we wanted to make the user buy our picture, having BurpSuite as a proxy, we would browse to:
http://192.168.56.102/WackoPicko/pictures/recent.php - Pick the picture with the ID 8
http://192.168.56.102/WackoPicko/pictures/view.php?picid=8. - Click on Add to Cart.
- It will cost us 10 Tradebux, but it will worth it so click on Continue to Confirmation.
- On the next page, click on Purchase.
- Now, let's go to BurpSuite to analyze what happened:
The first interesting call is
/WackoPicko/cart/action.php?action=add&picid=8and is the one that adds the picture to the cart./WackoPicko/cart/confirm.phpis called when we click the corresponding button and it may be necessary to use it to purchase. The other one that is useful for the attacker is the POST call to the purchase action (/WackoPicko/cart/action.php?action=purchase), which tells the application to add the pictures to the cart and to collect the corresponding Tradebux. - Now, the attacker is going to upload a picture to force other users to buy it. Once logged in as
attacker, go to Upload, fill in the requested information, select an image file to upload, and click on Upload File:
Once the picture has been uploaded, we will be redirected to its corresponding page, as you can see here:
Pay attention to the ID that it assigns to your picture, it is a key part of the attack. In our case, it is 16.
- Once we have analyzed the purchasing requests and have the ID of our picture, we need to start the server that will host our malicious pages. Start the Apache server as root in your Kali Linux as follows:
service apache2 start - Then, create an HTML file called
/var/www/html/wackopurchase.htmlwith the following contents:<html> <head></head> <body onLoad='window.location="http://192.168.56.102/WackoPicko/cart/action.php?action=purchase";setTimeout("window.close;",1000)'> <h1>Error 404: Not found</h1> <iframe src="http://192.168.56.102/WackoPicko/cart/action.php?action=add&picid=16"> <iframe src="http://192.168.56.102/WackoPicko/cart/review.php" > <iframe src="http://192.168.56.102/WackoPicko/cart/confirm.php"> </iframe> </iframe> </iframe> </body>This code will send the
add,review, andconfirmrequests of our items to the WackoPicko server while showing a 404 error page to the user and when it has finished loading all the pages, it will redirect to the purchase action and close the window after one second. - Now, log in as
v_user, upload a picture, and log out. - As the attacker, we need to be able to guarantee that the user goes to our malicious site while still logged into WackoPicko. While logged in as
attacker, go to Recent and select the picture that belongs tov_user(the one we just uploaded). - We will enter the following comments on this picture:
This image looks a lot like <a href="http://192.168.56.1/wackopurchase.html" target="_blank">this</a>
- Click on Preview and then Create:
As you can see, HTML code is allowed in the comments and, when
v_userclicks on the link, our malicious page opens in a new tab. - Log out and log in again as
v_user. - Go to Home and click on Your Purchased Pics, there should be no attacker's pictures.
- Go to Home again and then to Your Uploaded Pics.
- Select the picture with the attacker's comments.
- Click on the link in the comment.
When this loads completely you should see some WackoPicko text in the box and the window will close by itself after a second so our attack is complete!
- If we go to Home, we can see that the
v_userTradebux balance is now 85.
- Now go to Your Purchased Pics
http://192.168.56.102/WackoPicko/pictures/purchased.phpto see the unwillingly purchased image:
For a CSRF attack to be successful it needs preconditions. Firstly, we need to know the requests and parameters required to carry out a specific operation and the response we will need to make in all cases.
In this recipe, we used a proxy and a valid user account to perform the operation we wanted to replicate and gather the required information: requests involved in the purchase process, information required by these requests and the correct order in which to make them.
Once we know what to send to the application, we need to automatize it so we set up a web server and prepare a web page which makes the calls in the right order and with the right parameters. By using the onLoad JavaScript event, we ensured that the purchase was not made until add and confirm were called.
In every CSRF attack, there must be a way to make the user to go to our malicious site while still authenticated in the legitimate one. In this recipe, we used the application's feature which allows HTML code in comments and introduced a link there. So, when the user clicks on the link in one of their pictures' comments, it sends them to our Tradebux stealing site.
Finally, when the user goes to our site, it simulates an error page and closes itself just after the purchase request is made—in this example we didn't worry about presentation so the error page can be improved a lot in order to be less suspicious to the user—this is done with JavaScript commands (a call to the purchase action and a timer set to close the window) in the onLoad event of the HTML's body tag. This event triggers when all elements of the page are fully loaded, in other words, when the add, review and confirm steps have been completed.