A short guide to cross-site request forgery attacks



Photo from Negativespace.

This is a follow-on post to my post on clickjacking attacks.

I found this article from Auth0 (https://auth0.com/blog/cross-site-request-forgery-csrf/) while reading the one on clickjacking.  As before, it's worth reading.  Here's a summary.

What CSRF attacks are

CSRF, aka "c-surf", is an acronym fro Cross-Site Request Forgery.  The attack is where a malicious site uses another site's active session cookie to do something in the place of the user.  E.g. if you're logged in to your bank and go to a site in another browser tab, the other site could use the bank site's active session cookie to transfer money.

How to prevent them

User

Log out of websites, especially sensitive ones.

Back end

The article and OWASP do a good job of explaining the details, so I'll link to them here and give an overview.

  1. Check the origin header of the request.  This is fraught with peril.  Use as a last resort.
  2. Create an anti-CSRF token and store it in the session data on the server.  Send a copy to the client.  When the client responds, the responses will contain the anti-CSRF secret.  You can compare the client’s anti-CSRF secret to the secret stored with the session information.
  3. ✨ Use the double submit cookie strategy. This is the way to go because it doesn't require you to keep track of sessions on the server.  Basically, the idea is:
    • Put a secret value in a hidden input field in the form on the page.  This will be sent to the server along with the other form submission data.
    • Put the same secret value in an HTTP-only cookie that you send to the client.
    • When the form submits, compare the secret in the cookie to the secret in the form submission data. If they match, then the request came from a reliable source: an attacker wouldn't have the value from the HTML form.
For implementation, see the Auth0 (TLDR: use the csurf NPM package with the 'cookie' option).


Comments

Post a Comment

Popular posts from this blog

Optional object property access

Image
  Photo by Hannah Joshua on Unsplash Options: they aren't just for day traders any more! I just read a post by Dr. Axel Rauschmayer about null and undefined ( link to article ).  Here's a summary of some of the more interesting items about optional object property access and the nullish coalesce operator. The ?. operator is equivalent to "if the property exists, return it else return undefined". You can chain the ?. operator for nested objects: it will return undefined the first chance it gets. The ?? operator is like the `or` operator (||) except that it only passes through null and undefined. Examples: The ?. operator is equivalent to "if the property exists, return it else return undefined". let obj = { foo: 42 }; obj?.address // undefined obj?.foo //42 You can chain the ?. operator for nested objects: it will return undefined the first chance it gets. let users = [     { name: 'Tom', address: { line1: '1234 Main St.', line2: { city: '
Read more

How is an application like a bride's outfit? - 1 minute read

You've heard the tradition of a bride wearing "something old, something new, something borrowed, something blue."  Well, that's somewhat like a good piece of code.  Here's why: Something old: code you've already written (don't repeat yourself) if you can. Something new: customize the old framework. Something borrowed: similar to the 'something old', if you can find code that someone else has already written and has shared, use it!!  Libraries were written to be used! Something blue: OK, I admit this one is more of a stretch than the others, but bear with me: in this case, 'something blue' is to make something really useful for the user . . . and that starts with character!  Your users will use your application if it's easy to use and solves a problem, but they won't love it unless it's entertaining.  Caveat: Clippy  is proof that this last point needs to be taken with a grain of salt: sometimes, applications are better of
Read more