The history of an issue trying to prevent CSRF attacks

A couple of months ago we faced an issue in one of the projects in which I was working on due to a this Google Chrome update, due to a bug in the version of Apache OpenIDc module that our application was using. Our application stop working in Chrome browser, so with the help of a Frontend Engineer from my Team we started to investigate this weird issue with a high impact for us because our business critical application wasn’t working at all.

Root Cause

After being investigating for a while we found out the root cause of the problem, an issue in the Apache OpenIDc module used by our application. Apparently if your application was served by more than one domain, this module didn’t set any value at all to the SameSite cookie attribute. If we combine this situation with the Google Chrome update mentioned before, it caused causing that Chrome browser stopped loading our application.

When we were sure about the root cause of our issue we notified the problem in the Github Apache module repository so Apache module developers could fix it, and in some days they released a new version of the module with the issue fixed, we confirmed it updating the module in our application and our issue disappeared.

CSRF attacks

The update made by Google in the Chrome 80 version had as target to make some changes in the browser behavior to protect our web applications from some attacks known as Cross-Site Request Forgery (CSRF).

But what exactly is a CSRF attack, according to OWASP organization this kind of attacks could be defined as:

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.

A CSRF attack works because browser requests automatically include all cookies including session cookies. Therefore, if the user is authenticated to the site, the site cannot distinguish between legitimate requests and forged requests. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application and privileges of the user. For example, this attack could result in a transfer of funds, changing a password, or making a purchase with the user’s credentials.

Defenses against CSRF

  • Use a framework with built-in protection from CSRF
  • If the previous scenario is not your case and you’re using a framework without this protection, you must add CSRF tokens in your application in requests which are changing state (requests which cause actions on the site)
  • Define a value to SameSite cookie attribute in your application because this attribute helps the browser decide whether to send cookies along with cross-site requests.
  • Additional actions to protect you from this kind of attacks:
    • Use custom headers
    • Verify the origin with standard headers
    • Use double submit cookies
  • Use same mitigation techniques to prevent Cross Site Scripting (XSS), because also they are working to prevent CSRF attacks
  • Do not use GET requests for state changes in your application

Google Rollback

At the end we fixed the issue in our application but days later that we apply the fix in our productive environment Google decided that due to this global crisis without any previous precedent in our history, (COVID-19), to rollback this change in their browser.

Reference links:

“The supreme art of war is to subdue the enemy without fighting”
— Sun Tzu

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s