我不清楚使用Django表單的csrf標記。我在表單提交中有這個,我看到它是動態生成的。如果捕捉我的會議與提琴手,並嘗試提交我的表單沒有該令牌,我得到一個403錯誤。但我不明白的是,我可以使用提琴手來提交儘可能多的數據,因爲我需要使用相同的標記,所以我不明白這個標記的安全性。如果有人剽竊你的表格,他們可以使用相同的標記。Django csrf標記如何工作?
我是否缺少一些額外的步驟來確保令牌始終是唯一的?
我不清楚使用Django表單的csrf標記。我在表單提交中有這個,我看到它是動態生成的。如果捕捉我的會議與提琴手,並嘗試提交我的表單沒有該令牌,我得到一個403錯誤。但我不明白的是,我可以使用提琴手來提交儘可能多的數據,因爲我需要使用相同的標記,所以我不明白這個標記的安全性。如果有人剽竊你的表格,他們可以使用相同的標記。Django csrf標記如何工作?
我是否缺少一些額外的步驟來確保令牌始終是唯一的?
然後你的應用程序準備好表單,Django爲當前用戶會話使用csrf標記。所以,黑客只能爲自己的登錄生成表單。
要模擬atack,您可以嘗試打開表單會話,輸入內容並在設置中更改SECRET_KEY
時,重新加載服務器並提交表單數據。
現在您已收到csrf錯誤消息,becouse csrf令牌取決於SECRET_KEY
。
詳情請閱讀docs
我使用它來支持表單提交而不是登錄,所以當我進行測試時,我只是使用與第一次提交時相同的密鑰並且它可以工作。當然,如果我刪除或更改密鑰,它會失敗。 – rocketdoctor
的CSRF token
只ensures that only forms that have originated from trusted domains can be used to POST data back。因此,它不驗證數據或表單發送的數據量,但數據來自合法域(通常是您的站點)的表單。因此名稱:跨站請求僞造保護。
從docs:
每次CSRF令牌改變用戶登錄
「偷」或修改使用Firebug 自己令牌,Chrome瀏覽器開發 工具等。不是一個漏洞。
攻擊者無法竊取用戶瀏覽器的CSRF cookie。
如果有人訪問(通過中間人攻擊或者XSS)您csrftoken
cookie,那麼這是一個漏洞:
的CSRF保護不能防止中間人中間人攻擊, 所以使用HTTPS和HTTP嚴格傳輸安全。它還假設驗證了HOST頭部,並且在您的站點上沒有任何跨站點 腳本漏洞(因爲XSS漏洞已經讓攻擊者執行了CSRF漏洞允許的任何操作,而且 嚴重得多)。
黑客你的表單?請解釋這種情況! –