“Defend the Web” write-up (HTTP Method / Intro)
“Defend the Web” write-up (HTTP Method / Intro — HTTP POST exploitation and bypassing CSRF token protection)
CSRF (Cross-Site Request Forgery) is a type of attack that compels an authenticated user to perform undesirable actions on a web application. An attacker can deceive users of a web application into performing activities of the attacker’s choosing using social engineering techniques (such as delivering a link via email or chat). If the target is a regular user, a successful CSRF attack can drive them to make state-changing requests, such as transferring funds or altering their email address. CSRF can compromise the entire web application if the victim is an administrative account.
The CSRF attack might occasionally be stored on the susceptible site itself. These defects are known as “stored CSRF faults.” This can be done by simply placing an IMG or IFRAME element in an HTML field, or by a more elaborate cross-site scripting assault. The severity of the assault is exacerbated if the attacker can store a CSRF attack on the site. Because the victim is more likely to view the page carrying the attack than any random page on the Internet, the likelihood is increased. The possibility is additionally raised because the victim is almost certain to have already been authenticated on the site.
In this challenge, the password is already given, and you are asked to submit it as a POST request method to log in to the page. Let’s dive into it.
One of the methods to exploit the HTTP POST request is to create an HTML form with the provided password and then execute the file. To do so, open up any text editor and type the following HTML codes, then save the file as “anything.html”.
Then double-click on the file and execute it.
Normally, with this method, we should be able to log in, but in this case, the developers have implemented a security measurement against the CSRF attack. So, to bypass it we need to modify our “.html” file and run it again. Let’s refresh the browser and inspect the page elements.
In the source code field press on “Crtl + F”, and search for the word “token”.
We found three hits. Select the first one, right-click on it, and from the drop-down menu, click on the “Edit as HTML” option.
Form the editable field, select the code, and copy it.
Go back to your HTML code and edit it as follows.
Now, look for other tokens. Once you find one, select it and edit it as HTML.
This token is located inside the “form” field, so we need to copy this token and paste it inside the “form” field of our HTML code.
Now, save the file and then double-click to run it. Once the file is executed, you’ll be able to log in to the page and pass the challenge.
Countermeasure techniques that do not work against CSRF attacks.
Over time, a lot of poor solutions for guarding against CSRF attacks have emerged. Here is a handful that we advise you to stay away from.
Using a password-protected cookie
Remember that every request will result in the submission of all cookies, even the secret ones. Regardless of whether the end-user was duped into sending the request, all authentication tokens will be transmitted. Furthermore, the application container uses session identifiers to associate a request with a specific session object. The session identifier makes no attempt to verify that the end-user intended to send the request.
Only POST queries are accepted.
For the execution of business logic, applications might be developed to only accept POST requests. A common fallacy is that a CSRF attack cannot be carried out since the attacker cannot create a bad link. Unfortunately, this reasoning is flawed. An attacker can use a variety of techniques to mislead a victim into submitting a falsified POST request, including a simple form placed on the attacker’s website with hidden information, as we did in this example. This form can be activated either automatically by JavaScript or manually by the victim who believes the form will do some other action.
Transactions with Multiple Steps
Multi-step transactions aren’t enough to keep CSRF at bay. CSRF is conceivable if an attacker can foresee or deduce each stage of the finished transaction.
Rewriting URLs
Because the attacker cannot predict the victim’s session ID, this might be considered a viable CSRF prevention strategy. The user’s session ID, on the other hand, is visible in the URL. We don’t think it’s a good idea to solve one security problem by adding another.
HTTPS
HTTPS is ineffective against CSRF on its own. HTTPS, on the other hand, should be considered a need for any preventative measures to be reliable.