Django上的網站，https://docs.djangoproject.com/en/dev/ref/contrib/csrf/它指出：Django CSRF cookie可以通過javascript訪問？
然後，還規定了CSRF令牌可以從餅乾用JavaScript來實現獲得：
var csrftoken = $.cookie('csrftoken');
是不是這兩個語句衝突的？假設存在Cross Origin攻擊，那麼攻擊者只能從cookie獲取CSRF令牌，然後在頭中使用CSRF令牌發出POST請求？有人可以解釋這個嗎？
我現在認識到，只有來自同一產地的JavaScript被允許訪問該cookie。後續問題是：
如果POST請求自動添加cookie作爲請求的一部分，和Django的CSRF cookie值是一樣的CSRF令牌，然後一個惡意的跨源請求將仍然有正確的CSRF令牌無論如何？ （在cookie中）
我相信this post回答您的問題更新：
因爲同源策略的，攻擊者無法確實訪問該cookie。但正如你所提到的那樣，瀏覽器無論如何都會將Cookie添加到POST請求中。出於這個原因，必須從代碼中發佈CSRF令牌（例如在隱藏字段中）。在這種情況下，攻擊者必須知道在創建惡意表單時CSRF令牌的值存儲在受害者的cookie中。由於她無法訪問Cookie，因此她無法在其惡意代碼中複製該令牌，並且攻擊失敗。
現在，人們可能會想象存儲令牌的其他方式比在cookie中。關鍵是攻擊者一定不能得到它。服務器必須有一種方法來驗證它。您可以設想將令牌與服務器端的會話一起保存，並在客戶端以某種「安全」方式存儲令牌（「安全」意味着攻擊者無法訪問它）。
下面是OWASP報價：
一般情況下，開發人員只需要在當前會話生成一次此標記。在初始生成該令牌之後，該值存儲在會話中，並用於每個後續請求，直到會話過期。當最終用戶發出請求時，服務器端組件必須驗證請求中令牌的存在性和有效性，與會話中找到的令牌相比較。如果在請求中找不到令牌，或者提供的值與會話中的值不匹配，則應中止請求，應重置令牌並將事件記錄爲正在進行的潛在CSRF攻擊。
最後，安全需要兩兩件事：
我不是專科醫生，但這是我對這個問題的理解。希望能幫助到你。
從名稱CSRF（Cross Site Request Forgery）中，您已經可以猜測攻擊者必須執行來自「跨站點」（其他站點）的請求。
「理解CSRF攻擊的關鍵是要認識到，網站通常沒有驗證的請求從授權用戶來了。相反，他們只覈查請求來自授權用戶的瀏覽器來了。」 - quoted here
因此，對於那些不阻止CSRF攻擊的網站，攻擊者可以從任何地方發送惡意請求：瀏覽器，電子郵件，終端...由於網站不檢查請求的來源，它認爲授權用戶提出了請求。
在這種情況下，在每個Django表單中，都有一個名爲「CSRF令牌」的隱藏輸入。該值在表單呈現時隨機且唯一地生成，並將在請求完成後進行比較。所以請求只能從授權用戶的瀏覽器發送。沒有辦法（我知道的）攻擊者可以獲得這個令牌並執行可以被Django後端接受的惡意請求。
夠清楚？
可能重複[什麼是CSRF保護真的（在Django中）？]（http://stackoverflow.com/questions/10242263/what-is-csrf-protection-really-for-in-django） –