3
votes

Lot of people talk about implementing CSRF to stop cross site attacks on a webpage. But i think it is pretty easy to compromise CSRF and make requests to a server.

So how it works ?

  1. You start with a page, render a form and keep a hidden field with CSRF token.
  2. When form is submitted the other page will expect CSRF token in order to validate the request.
  3. While validating the request, server will check CSRF token with a secret to see if token is valid.
  4. Now the secret itself is stored in session or cookie.

Which means if i go to a website, copy the CSRF token from the webpage, and session value from browser network tab. After this i can construct a CURL request, set these values and make as many requests as i can.

So what is the need of CSRF at all ?

1

1 Answers

8
votes

The scenario you define is not CSRF.

Your scenario

Alice goes to Bob's website. Alice gets a cookie from Bob's website. Alice uses that data to make a request that she designed to Bob's website.

This is fine. Everything going on here is between Alice and Bob.

If Bob can't trust Alice to send good data, then that is a different problem entirely.

CSRF scenario

Alice goes to Bob's website. Alice gets a cookie from Bob's website. Alice goes to Mallery's website. Mallery's website triggers a form submission to Bob's website. Bob accepts the data because it came from Alice's browser with Alice's cookie.

i.e. Mallery's site is forging a request from Alice to Bob's site.

The anti-CSRF token is designed to prevent Mallery from making the request through Alice's browser (because Mallery can't get the token to put in the form data, so can't match the token in the cookie).