Cross-Site Request Forgery

False Positives in Burpsuite

When testing CSRF(Cross Site Request Forgery) vulnerabilities most of the testers use Burpsuite engagement tools which will generate CSRF POC to test against the target.

While doing the testing in most cases application testers just check with burpsuite POC to verify if target is vulnerable or not. however in some cases this could be a false positive due to how developer handles the application CSRF control implementations. to demonstrate this i would like to explain a practical case where i was encountered the similar situation. during the test i was decided the application is vulnerable to CSRF which will change the user account password. but usually i do further analysis and manual analysis to verify any vulnerability which is raised by a tool.

when i tested the application CSRF with burpsuite ‘Test in browser’ option, burpsuite will give URL to paste in the browser to view the response of that particular CSRF request.

When i testing the CSRF in this way, i can change the password of the user account. which means application is vulnerable to CSRF vulnerability which will change the user account password. however when i testing this with generated HTML page the vulnerability is not exploitable after first attempt and not able to change the user password after first attempt !. strange right ?. so i just checked at the ‘Referer’ header. (but still there is something suspicious because i can change the password at first attempt in generated HTML!) The reason to test ‘Referer’ header is because of the generated POC of burpsuite does not contains ‘Referer’ header but ‘Test in browser’ option will request with ‘Referer’ header. to confirm this i intercepted the generated HTML request with burp proxy and added the ‘Referer’ header.

After testing ‘Referer’ header, it was observed that header is not the problem, meanwhile the user account password is changing when i go through the ‘Test in browser’ option but password is not changing when i using the generated HTML after first attempt. so went through the application source code to find out what type of CSRF prevention is in use. unfortunately not able to find anything related to CSRF prevention. after some period i just checked the generated CSRF POC of the burpsuite, suddenly i just noted that there is a parameter ‘1620213050393’ passing through the URL GET request for the password change.

By analyzing this parameter i came to a conclusion that the application developer generating this value to check the password change request authenticity. the reason ‘Test in browser’ option flagged as CSRF is, the value is newly generated to verify password reset request hence it is a legitimate request, however in HTML POC option worked only at first attempt because the generated value is only legitimate when it’s used at first time, the second and further attempts does not contains the newly generated value for that request.

so basically in real world scenario, an attacker need to send this payload to the victim to successfully compromise the user account with password change. however because of this ‘value’ parameter, password change GET request will be denied at server end. so the application is not vulnerable to CSRF at this point. i never go further to bypass this control however what i want to say is, when testing with tools even like bursuite, always stick to manual verification and analysis of the vulnerability, because control and prevention mechanisms may vary to each and every developer.