Java - CSRF-Weak
Running the app on Docker
Now that the app is running let's go hacking!
Reconnaissance
CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the attacker and a legitimate request sent by the victim.
CSRF attacks target functionality that causes a state change / data mutation on the server, such as changing the victim's email address or password, or purchasing something. Forcing the victim to retrieve data doesn't benefit an attacker because the attacker doesn't receive the response, the victim does. As such, CSRF attacks target state-changing requests.
It's sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called "stored CSRF flaws". This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.
Lets start the application and login with the default credentials.
When we are loggedin to the application we can see that we can set our favorite color and this will be stored in the session of the user.
If we inspect the request with an intercepting proxy we can see that the application is performing a POST request that results in a data mutation, storing our favorite color into the session of the user and displaying this back to the user in the HTML website.
![](https://skf.gitbook.io/~gitbook/image?url=https%3A%2F%2Fraw.githubusercontent.com%2Fblabla1337%2Fskf-labs%2Fmaster%2F.gitbook%2Fassets%2Fjava%2FCSRF-Weak%2F3.png&width=768&dpr=4&quality=100&sign=137310e8&sv=1)
Also we can see that the application is using a csrf_token
Looks like it's Base64 encoded, try decode it.
The csrf token is simply username + time.
Checking the application code we can how this csrf_token is being implemented.
Exploitation
In order to to exploit this vulnerability we need to set up our evil webserver to do the malicious CSRF using a POST request from and sending the weak csrf_token with. We could achieve this by creating the following express application:
Save the snippet above to > evil_server.py and run the commands below to install some dependencies.
Of course you can also run your app on whatever service you want it does not have to be python flask.
Now that the service is running we want to serve the malicious piece of javascript that is responsible for performing the malicious CSRF POST request.
Save the snippet above to > templates/evil.html and run the command below to start our evil application.
Now when we have in the browser tab our active session of the application we can open a new tab where we will load our evil page we just created.
This will now create a POST request to the application and changing the value of blue to the new value of 'Hackzord!' As you can see the Referer is set to our evil website where the request originated from and we have our forged csrf_token with the request.
Also when we refresh the original page of the application we can see that the new vaulue has been replaced with the content of our evil app.
Additional sources
Last updated