TA貢獻1942條經驗 獲得超3個贊
我自己回答一下：
首先，我說的第一步通過中間頁用 GET 方法請求表單頁面，獲取到 token，這個沒問題，第二步，把獲取到的 token 用于動態(tài)構造的表單中發(fā)送 POST 請求，這個也可以實現(xiàn)，但是第二步請求 token 驗證不會成功。
關鍵在于 session 機制，通過中間頁去請求服務器頁面，生成 token 并放在 session 中，這個 token 只對中間頁 sessionid 標識有效，因為這個請求是中間頁發(fā)起的，而不是用戶 cookie 中的 sessionid，所以服務器在驗證 token 的時候會發(fā)現(xiàn)不一致，用戶 sessionid 對應的 token 的值，跟中間頁 GET 請求頁面生成的 token 值不一致。
TA貢獻1876條經驗 獲得超6個贊
CSRF的理解應該是沒問題的
我說一下我的疑問點：
1.第一次通過 GET 方式請求這個表單頁面從而獲取 token
關注你的token獲取，token本身是什么，就是服務器端對你這個訪問者的一個標識。
表單提交頁面，如果本身不需要你登錄，那么本身就可以隨便攻擊，因為服務器端根本無法識別的你的身份。
那么如果你登錄了，你通過使用這個token進行攻擊，已經暴露你是誰。也就不存在偽裝的意義。
所以就我理解，這個不能稱為所謂的攻擊，這能說模仿請求。。
我認為的攻擊應該是這樣的，敵人無法判斷你是誰，然而你卻能獲取到資源。
TA貢獻1853條經驗 獲得超6個贊
在中間網站我請求兩次，第一次通過 GET 方式請求這個表單頁面從而獲取 token，第二次帶上這個 token 發(fā)起 POST 請求，這樣不就成功偽裝了嗎？我這個想法應該有問題，但好像又可以，錯在哪？
中間網站是什么？
如果是指中間人攻擊，那么，你應該關注的是 HTTPS。CSRF 不處理中間人攻擊。
如果是指第三方網站，那么，除非你的網站通過 Access-Control-Allow-Origin 頭允許，否則第三方網站無法讀取請求返回的內容（跟其它一些跨域請求的處理一樣，能請求，但是未經允許不得訪問），也就拿不到 token。
PS: 這么基礎的問題，那么多回答，竟然只有一個稍微靠譜點的…………
TA貢獻1875條經驗 獲得超5個贊
首先，token 是在表單隱藏域中，第三方通過 get 方式如何獲?。?br/>其次，提供 token 的網站要避免通過 get 方式傳遞 token。
token 的方式不是絕對安全的，但是可以通過以下方式提升其安全性：
Referer 和 token 結合使用，服務端判斷 token 之前，先判斷 Referer 是否為本站；token，限制 token 的時效性；沒有絕對安全的方法，但是可以盡量遵循安全的編程規(guī)范。
參考：CSRF 攻擊的應對之道
TA貢獻1712條經驗 獲得超3個贊
你把token這個鍵名也隨機生成，然后位置也隨機，反正不要讓他抓取到，抓取到也要每次都改規(guī)則?。?br/>其實你的多余的，他只是防止太簡單的請求而已?。。。「緹o法100%防止采集
舉報
