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

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

中間網(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ǔ)的問題，那么多回答，竟然只有一個(gè)稍微靠譜點(diǎn)的…………

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

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

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

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

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

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

我自己回答一下：

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

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

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

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

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

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

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

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