Each year, Rapid7 penetration testers complete hundreds of internally and externally based penetration testing service engagements. This post is part of an ongoing series featuring testimonials of what goes on beneath the hoodie. For more insights, check out our 2020 Under the Hoodie report.
Cross-site request forgery attacks trick web application users into submitting requests that take actions through their session, such as sending someone a phishing link that would automatically submit a form that adds a new user to their web application.
One way to address CSRF attacks is to implement an anti-CSRF token, such as a hidden form field with a random value that gets validated by the server.
While testing one web application, we discovered that the anti-CSRF token was a session cookie that was set in the browser when the user logged in. That was promising, since the browser would add it to the requests for us. The big question was whether matching the value would be difficult. However, we discovered that the server accepted any anti-CSRF cookie value that was present and was the correct length. So, while the web application had an anti-CSRF token, that token wasn't actually being validated in any useful way by the server. The value didn't matter, so we could just supply our own (provided it was the right static length).
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Subscribe
Reviewing some of the functions for our admin-level user, we picked the request for submitting password ..
Support the originator by clicking the read the rest link below.
