CSRF 生成 token 的方式這樣可以攻擊嗎？

在中間網(wǎng)站我請求兩次，第一次通過 GET 方式請求這個表單頁面從而獲取 token，第二次帶上這個 token 發(fā)起 POST 請求，這樣不就成功偽裝了嗎？我這個想法應(yīng)該有問題，但好像又可以，錯在哪？

中間網(wǎng)站是什么？

如果是指中間人攻擊，那么，你應(yīng)該關(guān)注的是 HTTPS。CSRF 不處理中間人攻擊。

如果是指第三方網(wǎng)站，那么，除非你的網(wǎng)站通過 Access-Control-Allow-Origin 頭允許，否則第三方網(wǎng)站無法讀取請求返回的內(nèi)容（跟其它一些跨域請求的處理一樣，能請求，但是未經(jīng)允許不得訪問），也就拿不到 token。

PS: 這么基礎(chǔ)的問題，那么多回答，竟然只有一個稍微靠譜點的…………

CSRF的理解應(yīng)該是沒問題的

我說一下我的疑問點：
1.第一次通過 GET 方式請求這個表單頁面從而獲取 token
關(guān)注你的token獲取，token本身是什么，就是服務(wù)器端對你這個訪問者的一個標(biāo)識。
表單提交頁面，如果本身不需要你登錄，那么本身就可以隨便攻擊，因為服務(wù)器端根本無法識別的你的身份。
那么如果你登錄了，你通過使用這個token進行攻擊，已經(jīng)暴露你是誰。也就不存在偽裝的意義。

所以就我理解，這個不能稱為所謂的攻擊，這能說模仿請求。。

我認(rèn)為的攻擊應(yīng)該是這樣的，敵人無法判斷你是誰，然而你卻能獲取到資源。

你把token這個鍵名也隨機生成，然后位置也隨機，反正不要讓他抓取到，抓取到也要每次都改規(guī)則??！
其實你的多余的，他只是防止太簡單的請求而已！?。。「緹o法100%防止采集

回答在我的評論里，看看slim的插件slim-csrf

我自己回答一下：

首先，我說的第一步通過中間頁用 GET 方法請求表單頁面，獲取到 token，這個沒問題，第二步，把獲取到的 token 用于動態(tài)構(gòu)造的表單中發(fā)送 POST 請求，這個也可以實現(xiàn)，但是第二步請求 token 驗證不會成功。

關(guān)鍵在于 session 機制，通過中間頁去請求服務(wù)器頁面，生成 token 并放在 session 中，這個 token 只對中間頁 sessionid 標(biāo)識有效，因為這個請求是中間頁發(fā)起的，而不是用戶 cookie 中的 sessionid，所以服務(wù)器在驗證 token 的時候會發(fā)現(xiàn)不一致，用戶 sessionid 對應(yīng)的 token 的值，跟中間頁 GET 請求頁面生成的 token 值不一致。

第一次你是獲取不到token的，你會被直接導(dǎo)向到登錄頁面。

首先，token 是在表單隱藏域中，第三方通過 get 方式如何獲取？
其次，提供 token 的網(wǎng)站要避免通過 get 方式傳遞 token。

token 的方式不是絕對安全的，但是可以通過以下方式提升其安全性：

1. Referer 和 token 結(jié)合使用，服務(wù)端判斷 token 之前，先判斷 Referer 是否為本站；
2. 使用動態(tài) token，限制 token 的時效性；

沒有絕對安全的方法，但是可以盡量遵循安全的編程規(guī)范。

參考：CSRF 攻擊的應(yīng)對之道