Testing for CSRF can be worth it.

CSRF (pronounced sea-surf hehe), or rather client-side request forgery, used to be one of most dangerous attacks a web application could experience. Essentially, while a user is logged in and authenticated, a web application sets a valid session state through the use of cookies. When the client sends a request to the web application server, the server will first authenticate the cookies to verify the client can do whatever action it requests before it performs the action. By default, cookies are sent with most HTTP requests, even across other sites. In a CSRF attack, an attacker gets a logged-in victim to visit a malicious site that will send a request to the web application pretending to be the victim. For example, user A, who is logged into bank.com, will visit attacker.com, which sends a POST request to the bank server (with user A’s credentials) to transfer $1000 out of A’s account into the attacker’s account. Because the request contains the authorized cookies, the transfer is validated.

A simple google search of “is csrf dead” will reveal many articles and blogs talking about how CSRF is mostly a non-issue. OWASP (the Open Web Application Security Project) ranked the attack in the top 10 most critical security risks in their 2007 and 2013 lists, but by their 2017 list, CSRF was gone. Note: those 3 lists were the only 3 published between 2007–2017.

Much of this is because newer web frameworks, the use of content management systems, and use of CSRF-prevention techniques is much more prevalent than before. One common protection mechanism is the use of a nonce token. Any request that can change the state of web app will feature a unique nonce token, which will be cryptographically generated by the server on a per-request or a per-session basis, and this token must match in both the client request and on the server to be validated. Additionally, newer browser version are starting to set default protections against cookies be forwarded to external sites.

However, even in 2022, there are major bug bounties being rewarded for CSRF vulnerabilities in big companies.

Stripe is one of the largest payment platforms on the internet. It is one of the most well-known software and used APIs to manage online transactions. Amazon, Lyft, Google, and even Medium uses Stripe.

In February 2022, two individual, separate HackerOne users, d_sharad and rodolfomarianocy , both reported the same bug to Stripe’s security team. On Stripe Dashboard, there was a CSRF bug that allowed attackers to trigger requests from a different site that modified a user’s Stripe account. This was due to a code change that when deployed deactivated the CSRF protection mechanisms for the dashboard. The summaries do not indicate exactly what modifications were able to be made, but Stripe stated that the bug didn’t allow for an attacker to get user data. Additionally, because of its lower severity rating, I’m assuming that an attacker could make significant changes to the account, such as changing passwords. Payments were additionally protected because of defense-in-depth mechanisms, such as requiring Re-Captcha and password re-entry.

Each HackerOne user was rewarded with $2500, totaling the bug bounty to $5000. Stripe verified that no account was actually attacked through this exploit, and even though this bug caused minimal damage to accounts, it represents a potential attack vector for other chained exploits that could raise the severity level of an attack. Looks like CSRF is not necessarily dead after all.

Thanks for reading through and please leave any constructive feedback, suggestions, or questions below! If you enjoyed, please consider following me on Medium. Contact me at [email protected], follow me on twitter, and connect with me on LinkedIn!