Django CSRF cookie accessible by javascript?

Question

On django website, https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ it states:

The CSRF protection is based on the following things:

1. A CSRF cookie that is set to a random value (a session independent nonce, as it is called), which other sites will not have access to.
2. ...

Then, it also states the csrf token can be obtained from cookie by javascript:

var csrftoken = $.cookie('csrftoken');

Aren't these two statements conflicting? Say there is a Cross Origin attack, then the attacker can just obtain the CSRF token from cookie, and then make a POST request with the CSRF token in the header? Can someone explain this please?

UPDATE

I realize now that, only the javascript from the same origin is allowed to access the cookie. A follow-up question is:

If a POST request automatically adds the cookie as part of the request, and django's csrf cookie value is the same as csrf token, then a malicious cross source request will still have the correct CSRF token anyways? (in cookie)

Answer 1

I believe that this post answers your updated question:

Because of the same-origin policy, the attacker cannot access the cookie indeed. But the browser will add the cookie to the POST request anyway, as you mentioned. For this reason, one must post the CSRF token from the code as well (e.g. in a hidden field). In this case, the attacker must know the value of the CSRF token as stored in the victim's cookie at the time she creates the malicious form. Since she cannot access the cookie, then she cannot replicate the token in her malicious code, and the attack fails.

Now, one might imagine other ways of storing the token than in the cookie. The point is that the attacker must not be able to get it. And the server must have a way to verify it. You could imagine saving the token together with the session on the server-side, and storing the token in some "safe" way on the client side ("safe" meaning that the attacker cannot access it).

Here is a quote from OWASP:

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.

In the end, the security needs two things:

• The CSRF token must be sent from the code, which means that the malicious code must know it.
• The CSRF token must be stored in some "safe" place for comparison (the cookie is convenient for this).

I am not a specialist, but this is my understanding of the problem. Hope it helps.