Flask 跨站請(qǐng)求偽造（CSRF）

另一個(gè)大問題是 CSRF 。這是一個(gè)非常復(fù)雜的話題，我不會(huì)在此詳細(xì)介紹，而只會(huì) 提及 CSRF 是什么和理論上如何避免它。

如果你的驗(yàn)證信息存儲(chǔ)在 cookie 中，你有隱式的狀態(tài)管理?！耙训侨搿睜顟B(tài)由一個(gè) cookie 控制，并且這個(gè) cookie 在每個(gè)頁面的請(qǐng)求中都會(huì)發(fā)送。不幸的是，在第三 方站點(diǎn)觸發(fā)的請(qǐng)求中也會(huì)發(fā)送這個(gè) cookie 。如果你不注意這點(diǎn)，一些人可能會(huì)通過 社會(huì)工程學(xué)來誘導(dǎo)你應(yīng)用的用戶在他們不知道的情況下做一些蠢事。

比如你有一個(gè)指定的 URL ，當(dāng)你發(fā)送 POST 請(qǐng)求時(shí)會(huì)刪除一個(gè)用戶的資料（比如 http://example.com/user/delete 。如果一個(gè)攻擊者現(xiàn)在創(chuàng)造一個(gè)頁面來用 JavaScript 發(fā)送這個(gè) post 請(qǐng)求，他們只是誘騙一些用戶加載那個(gè)頁面，而他們 的資料最終會(huì)被刪除。

想象你在運(yùn)行 Facebook ，有數(shù)以百萬計(jì)的并發(fā)用戶，并且某人放出一些小貓圖片 的鏈接。當(dāng)用戶訪問那個(gè)頁面欣賞毛茸茸的貓的圖片時(shí)，他們的資料就被刪除。

你怎樣才能阻止這呢？基本上，對(duì)于每個(gè)修改服務(wù)器上內(nèi)容的請(qǐng)求，你應(yīng)該使用 一次性令牌，并存儲(chǔ)在 cookie 里， 并且 在發(fā)送表單數(shù)據(jù)的同時(shí)附上它。 在服務(wù)器再次接收數(shù)據(jù)之后，你要比較兩個(gè)令牌，并確保它們相等。

為什么 Flask 沒有為你這么做？理想情況下，這應(yīng)該是表單驗(yàn)證框架做的事，而 Flask 中并不存在表單驗(yàn)證。