My Pentest Log -11- (CSRF in ASP)
Greetings everyone from the Basilica,
Today, I would like to inform you about a situation I encountered while testing an ASP-based website.
1. I was informed by our project manager that I would conduct tests on private.com.
2. I reviewed the scope form for the target of interest and completed the necessary verification procedures and started the pentest phases.
3. Since it is an ASP-based application, I was quite nervous, if you ask why:
ASP-based applications can have much stricter security measures than PHP-based applications, because ASP comes with various security measures by default. From this, you can understand that ASP applications always start security tests 1–0 ahead.
4. Anyway, I rolled up my sleeves and started fighting with the ASP-based application, thankfully I found various levels of vulnerability detection, but what really interested me was the “__RequestVerificationToken” value that I encountered in almost every ASP application forms.
5. Actually, from a security perspective, it is a mechanism developed against CSRF attacks in ASP applications.
So what does this mean for us?
When you want to investigate a CSRF vulnerability on any form in an ASP application, it is very difficult to trigger the CSRF vulnerability if the “__RequestVerificationToken” value is implemented correctly because a correctly implemented “__RequestVerificationToken” value is changed every time by a secure random mechanism and its use is terminated as soon as it is changed. From this point of view, you can understand that a very good precaution has been taken against CSRF vulnerability in ASP applications.
If you want more detailed information, you can read the excellent blog below:
6. I noticed that some critical forms on private.com have “__RequestVerificationToken” value and I started to sweat.
7. So how can we bypass the “__RequestVerificationToken” and expose the CSRF vulnerability:
As I just mentioned, if the “__RequestVerificationToken” value is implemented correctly, it is very difficult to bypass this.
However, I started to research what I can do to overcome this and took a look at the best practices, I learned that some developers made various mistakes while applying this token value on their applications. I reviewed various mistakes that can be made based on Best practices and realized that it was one of the mistakes made in my private.com test.
The target application was making the “__RequestVerificationToken” value that it had produced for the relevant users available to other users as well, it was an incredible error, it took me almost 1 hour to realize this situation.
From this point of view, I was able to easily bypass the CSRF protection on the relevant forms, as it allows the application to use the token value generated for one user on another user.
8. I was able to finish the day with high motivation by writing the current situation in my report with the necessary evidence and explanations.
Here are the addresses I used while researching this situation:
A. https://security.stackexchange.com/questions/143351/pentest-results-questionable-csrf-attack
B. https://stackoverflow.com/questions/14051456/whats-the-use-of-the-requestverificationtoken
In summary:
When you spend time on some of the “headings” and “parameters” you come across, you can find out what problems they prevent and what they can cause if not applied correctly, and you can reveal various vulnerabilities.
