First of all this post isn’t about providing you directly with the answer to this challenge but to help you understand how to complete it. I have been penetration testing for about 10 years now and I found this challenging. Once I understood how this vulnerability manifested itself it was quite easy to complete. I hope this post will help you solve this lab.

Immersive Labs give a great written example of how CSRF works but I find visualising it much easier.

In the example shown in the image below the criminal is able to post a message to a legitimate site such as a social media site and as part of that post is able to cause anyone who renders the message to post to the bank site. This post to the bank site could be something like a transfer request e.g. www.bank.com/transfer?from=user&to=criminal&amount=1000000. Now there are some pre-requisites here.

Firstly they have to be a user of the bank but the main requirement is to have the user render the message in a way that causes a HTTP GET or POST request. There are few ways this can be done such as using HTML tags like one for an image which can be stored on a remote server but it could be as simple as having them click on a link manually. Secondly if user has not logged out of their bank website or the cookie lifetime is set to an inordinate amount of time the user is vulnerable to this sort of attack.

So that’s how this vulnerability works but how does this apply to the lab given there is only one website. This is where I really struggled with this because I am used to CSRF involving 2 websites. You need to find a way to post a message to the site and within your message embed a method of invoking the scraper to make a post. Hint, some posts already have things embedded in them. Once you replicate a way of embedding the post once the scraper accesses your message they will automatically post a message and you just need to go back to the site and you will see the username that makes the post. The diagram below shows how it should work.

One thing Immersive Lab doesn’t do is help you understand how to prevent this style of attack. There are number of methods that can be used to defend against this and it wouldn’t be unrealistic to expect all of these methods to be used.

Firstly any website that requires users to login should use a short cookie lifetime so that if the user leaves the browser for a length of time future attempts to use the cookie will not allow access to the site. Websites should also invalidate user sessions on the server side if session hasn’t been used for a while in combination with an inactivity timer on the page just in case the user has accidentally left the page open. In addition, any sensitive function such as a bank transfer or creating a new user account should require additional authentication. For modern banking websites this is normally done by using a hard or soft token code in addition to the request so that the site knows the user actually requested the action. Lastly, websites should use a CSRF token which is a random value, called a NONCE, that the site passes to the user prior to the request, if the user does not pass the nonce back to the server then the server knows that this is a CSRF attempt.

If you get stuck feel free to drop me a message on the TechVets Discord, I am the user DiveMonkey.