Cross Site request Forgery (CSRF) is a type of security vulnerability that occurs when an attacker tricks a user’s web browser into unintentionally making a request to a web application on which the user is authenticated. This can lead to the execution of unauthorized actions on behalf of the user without their knowledge. To prevent CSRF attacks, websites often use tokens or other mechanisms to ensure that requests are legitimate and initiated by the user. Let us start by discussing a common bypass against CSRF.
CSRF scenario where token validation is solely dependent on the token’s presence, an attacker could potentially exploit the vulnerability by completely removing the token and still sending a malicious request to the target website. Since the server only checks for the token’s existence and doesn’t validate its origin, the absence of a token might go unnoticed, allowing the attacker to forge and submit unauthorized requests on behalf of the user without the protection of a valid token.
The purpose of our challenge was to find the weakness of the CSRF token functionality and exploit the attack to display the hidden flag.
We can observe that we have the register functionality in which we would require to register two different users. Once we have registered, we need to login as one of the users to proceed with the challenge.
Once logged in we can observe the home page is visible with different modules such as product, profile. On analyzing each of the functionality we observe that the blog module contains only one image which is clickable. This can be found upon manually inspecting the page source or by spider crawling the website using tools such as Katana or OWASP ZAP.
We found the hidden functionality which the developer might still be working on or might have forgotten to remove the functionality.
In the transfer credits functionality, we can send credits to another user by providing the email address of that user and the number of credits that we want to transfer.
By default, each user is given 100 credits. Now we transfer 10 credits to another user that we created, and we can observe that the credits are deducted from our available credits.
Now we fill the required details, click the Transfer Credit button and intercept the request in Burp Suite. We can identify that the application uses a CSRF token. On observing this token different test cases come to our mind. One of which is to remove the token value.
Since removing the token value did not work another test case that immediately come to our mind is to remove the entire token completely. We can observe that by sending the request the flag is visible to us and we have found the hidden flag. But this is just the detection that we have performed.
We generate the CSRF POC of the request to which we found the flag and we change the email of the other user to that of our own.
<html> <body> <script>history.pushState('', '', '/');</script> <form action="https://ctf.securityboat.in/nov2023/user.php" method="POST"> <input type="hidden" name="email" value="email@example.com" /> <input type="hidden" name="avcredit" value="100" /> <input type="hidden" name="txcredit" value="100" /> <input type="hidden" name="operation" value="transfer" /> <input type="submit" value="Submit request" /> </form> </body> </html>
We assume that the attacker will use some social engineering technique to send the request to the victim. On clicking this URL, the form will execute and unknowingly the victim will transfer the credits to the attacker. We perform this on the other user that we created, and we can observe that we are again able to access the hidden flag.
At SecurityBoat, we post various challenges and extend recognition, including rewards and shoutouts, to the successful participants of these challenges. To participate in such challenges, follow us on , LinkedIn, and Instagram. Twitter, LinkedIn, and Instagram.
Our latest blogs and solution to challenges are available here.