CODEWITHSUNDEEP
javascriptdjangosecuritycookiescsrf
Jenia Be Nice Please
Jenia Be Nice Please

Reputation: 2703

csrf token confusion. i can just get it with wget, no cross-origin problems. what's the point then?

I don't understand fully the point of csrf token protection. That's the token that says that the POST is coming from my site.

But anyone has access to that token by just verifying their cookie content. I don't understand then, how is this token protecting me?

To get the csrf cookie, can i make an ajax call to the server and just set the cookie that way? Will that break the csrf protection?

Upvotes: 0

Views: 1112

Answers (2)

SilverlightFox
SilverlightFox

Reputation: 33588

csrf token confusion. i can just get it with wget, no cross-origin problems. what's the point then?

The part you're missing is cookies - wget will not send the cookie from the victim's browser along with the request.

The Synchronizer Token Pattern associates the CSRF token (which is visible in a hidden <input> field within the HTML) with the session cookie. If another user makes a request to get the CSRF token from your page, as they are not logged into the same session as their victim, this token will not be useable in their attack.

A CSRF attack works like follows. Imagine the following code on www.evil.com, a site that the attacker has managed to get their victim to visit (e.g. via a facebook post or an email):-

<form method="post" action="https://www.example.com/executeAction">
    <input type="hidden" name="action" value="deleteAllUsers">
</form>

<script>document.forms[0].submit()</script>

As the victim is logged into your site (www.example.com) as an admin user, the form submission works and all users are deleted from your system.

The Synchronizer Token Pattern is the recommended way to fix this vulnerability. The CSRF token is a cryptographically secure random string. When a legitimate user loads your form and submits it, your system will check that the token POSTed matches the one expected. Any attacker cannot read the token from your site as any cross site access is protected by the Same Origin Policy

There is another prevention method known as Double Submit Cookies (which may match the method you are talking about). This works in a similar way, although there is no server side state of the CSRF token stored. This requires a cookie value to match a CSRF token that is submitted with the form, but as the attacker cannot set this cookie nor read it, they do not know the value to set the form submitted value to in order to match the cookie.

Upvotes: 2

Pointy
Pointy

Reputation: 414006

CSRF attacks involve malicious code hosted somewhere. The idea is this:

  • Attacker lures you to site, and your browser loads malicious code
  • Malicious code, in the context of that site it came from, attempts to carry out a POST to some known URL at some other secure site: your bank, your hospital, whatever.

If you happen to be logged in to the secure site, then your browser will have a secure session cookie for it. When the malicious code attempts the POST, then, your browser will dutifully send along the cookie. The bad code doesn't know what the cookie value is, but it doesn't have to.

The malicious code does, however, need to know everything else about how to put together the parameters for the POST request to be carried out. That's where the secure CSRF token idea comes from. The malicious code can't actually see what's on the pages in your browser from the real secure site. Thus, a secure site that expects a CSRF token won't see one when the malicious code attempts its POST operation.

(There are probably other variations on this; I'm not a security expert and I don't have exhaustive knowledge of attacks like this.)

Upvotes: 2

Related Questions