About CSRF: Attacker designs a webpage that sends requests to a vulnerable website for action like change in password, etc. Now, if a user who is pre-logged-in to the vulnerable website, comes to the attacker’s webpage and does the action, the attacker can send his own parameters in the request to the vulnerable site. Thus, the attacker sends a cross-site request, forging it with his own parameters. Hence the name, CSRF.
Defending against CSRF
There is no silver bullet to defend against this attack. We list out good practices which help in avoiding CSRF vulnerability on your website.
CSRF Token and Cookie
The web server sets a CSRF cookie in GET request. Further, in all the POST (or other transaction) requests, a CSRF parameter is passed in headers or as a hidden form parameter. The server validates the CSRF parameter value and the CSRF cookie value according to the algorithm and a secret, both only known to the server. This technique of validation is called the Double submit cookie technique. The attacker will not be able to send the correct CSRF token and CSRF cookie pair, thus the server will reject the request.
Signed Cookies
Both the CSRF cookie and the user authentication cookie should be signed using a secret only known to the server. This prevents the attacker from manipulating the value of the cookies because he will not be able to correctly sign them.
Cookie Attributes
Both the CSRF cookie and the user authentication cookie should have the following attributes set:
- The SameSite cookie attribute should be set to either Strict or Lax. None should be avoided. This prevents forwarding these cookies from the attacker's webpage to the web server.
- The Secure cookie attribute should be set to true. This prevents cookies to be forwarded to HTTP connections.
- The httpOnly cookie attribute should be set to true. This prevents the accessibility of these cookies in frontend JS.
Read more about these attributes on MDN Web Docs.
Re-using Popular Libraries
To mitigate CSRF risk, we can use popular libraries available in various languages and frameworks, to avoid re-inventing the wheel. Following are some examples.
Language | Framework | CSRF protection package |
---|---|---|
Node.js | Express | csurf NPM package |
Node.js | Koa | koa-csrf NPM package |
Golang | Gin, Goji, Echo | gorilla/csrf from gorilla toolkit |
Conclusion
In this blog, we discussed CSRF attacks and how they can be mitigated. If you want help in eliminating this vulnerability, you can get in touch with True Sparrow, that’s us.