CODEWITHSUNDEEP
ajaxsecuritybrowsercsrfcsrf-protection
thelastone
thelastone

Reputation: 565

Why can't a malicious site obtain a CSRF token via GET before attacking?

If I understand correctly, in a CSRF attack a malicious website A tells my browser to send a request to site B. My browser will automatically include my B cookies in that request. Although A cannot see those cookies, if I'm already authenticated in B the request will look legit, and whatever action was asked will be successfully performed. To avoid this, every time that I visit a page of B containing a form, I receive a CSRF token. This token is associated to my session, so if I make a POST to B I MUST include such token; otherwise B rejects my request. The benefit of this scheme is that A will not have access to that token.

I have two questions:

Thanks!

Upvotes: 36

Views: 3471

Answers (4)

Bharathwajan
Bharathwajan

Reputation: 53

The CSRF token is generated on the server-side when a user session is initiated. This token is unique to the session and is not directly exposed to the client.

The generated CSRF token is embedded into the HTML form as a hidden input field. This hidden field is not visible to the user but is included in the form submission.

When a user submits the form, the browser automatically includes the session cookie in the request. However, the CSRF token is not automatically included by the browser. It must be explicitly extracted from the hidden field and included in the request.

Even if an attacker manages to trick a user into clicking a malicious link, they cannot directly access the CSRF token from the client-side so he/she wont get the token to perform malicious action

Upvotes: 0

Sathvik
Sathvik

Reputation: 654

Site A: A malicious site attempting to exploit the user's session.
Site B: A legitimate site where the user is logged in.
GET Method: In general, CSRF protection is not applied to GET requests because they do not modify or change server-side data/state. However, if you configure it to do so, it becomes vulnerable.

With CSRF Enabled:

A --[GET token || (Session ID of B)]--> Server  
     <--[Response: Token]-- Server  
Browser(SOP Blocks Response Body)
A --[POST malicious transaction || (Session ID of B)]--> Server  
     <--[Response: Failed (No Token)]-- Server  
Browser(SOP Blocks Response Body)

In this case, Site A (the malicious site) requests a CSRF token acting as B using the session ID. The server sends a valid token, but the browser's SOP blocks the response body. Without the token, Site A cannot perform the malicious transaction.

With CSRF Disabled:

A --[POST malicious transaction || (Session ID of B)]--> Server  
     <--[Response: Success]-- Server  
Browser(SOP Blocks Response Body)

Here, Site A (the malicious site) requests a malicious transaction acting as B using the session ID. Since CSRF protection is disabled, the server performs the action without token validation. Although the browser's SOP blocks the response body, the changes still occur.

Upvotes: 0

Gabor Lengyel
Gabor Lengyel

Reputation: 15570

Your description is correct.

If site A tells your browser to go to B and get the token, that's fine, but as it is a cross-domain request, A will not have access to the token in Javascript (this is a browser feature). So when A tells your browser to go back to B and actually do something, it still cannot include the token in the request.

That is, unless B set the token as a cookie. Evidently, that would be flawed, because the token cookie would also be sent, thus negating any protection. So the token in this case must be sent as either a form value or a request header (or something else that is not sent automatically like a cookie).

This also means that if B is vulnerable to cross-site scripting, it is also vulnerable to CSRF, because the token can then be stolen, but CSRF is the smaller problem then. :)

Upvotes: 20

solarhell
solarhell

Reputation: 181

Correct.

Site A can't get site B's csrf token because of the browser's CORS strategy.

And we need to validate the request's referer(It can be forged). https://en.wikipedia.org/wiki/HTTP_referer

It is also a good practice to validate the crsf token in url(AKA query string).

FYI,Laravel, a popular web framework, uses a hidden CSRF token field in the form to prevent csrf attack.

Upvotes: 0

Related Questions