1. 如何避免CSRF攻擊
CSRF是一種讓人難以防範的漏洞，據歪歪了解，目前沒有很好的監測CSRF的方法。歪歪想到的一些比較可行的防範方法：
不使用網銀。所謂的無招勝有招，我既然不用網銀，黑客也就自然巧媳婦難為無米之炊了。（just a joke:)）
定期修改密碼。定期修改密碼永遠是安全學中最提倡的一個方法。
訪問敏感網站（比如信用卡、網銀等）後，主動清理歷史記錄、cookie記錄、表單記錄、密碼記錄，並重啟瀏覽器才訪問其他網站。
保持瀏覽器更新補丁，尤其是安全補丁。同時也要留意操作系統、殺毒、防火牆等軟體的更新。
不要上來歷不明的網站，推薦使用ms ie7的站點認證功能或者google toolbar之類辨識非法的網站。
使用某些帶有「隱私瀏覽」功能的瀏覽器，比如Safari。「隱私瀏覽」功能可以讓用戶在上網沖浪時不會留下任何痕跡, 瀏覽器不會存儲cookie和其它任何資料。從而CSRF也拿不到有用的信息。
ie8把它叫做「InPrivate瀏覽」。Chrome稱作「Incognito模式」。
如果瀏覽器提示「鏈接和證書域名不匹配」的警告信息時，請不要繼續瀏覽，立即關閉瀏覽器或者返回上一頁（如果您是網頁開發者或者黑客，當我沒有說）。
管理好瀏覽器的cookie。比如在IE6.0中，打開「工具->Intern
2. CSRF 攻擊是什麼
說明: 本文大部分借鑒 wiki-跨站請求偽造 , 另一部分來自文章 wiki-Cross-Site Request Forgery
csrf 全稱 Cross-site request forgery, 通常縮寫為CSRF 或者 XSRF, 中文名跨站請求偽造. 是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。 . CSRF 攻擊手段是通過發起改變狀態的請求, 而不是竊取用戶的數據, 因為攻擊者無法得到伺服器返回的響應
攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站並執行一些操作（如發郵件，發消息，甚至財產操作如轉賬和購買商品）。由於瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶操作而去執行。這利用了web中用戶身份驗證的一個漏洞： 簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自願發出的。 補充: 還可能更改賬號所綁定的郵箱地址或者密碼等.
假如 Alice 在 bank.com 向 Bob 匯款 10000, 那麼攻擊將會由以下兩步驟組成:
如果 bank.com 把查詢參數放到 URL 中, 那麼 Alice 向 Bob 轉賬的操作可以簡化為如下:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Maria 根據 bank.com 網站請求的結構, 將 Bob 名字替換為她自己的, 還把金額變大:
http://bank.com/transfer.do?acct=MARIA&amount=100000
那麼這個充滿惡意的 URL ,被 Maria 放到 a 標簽中, 並且利用欺騙語言吸引 Alice 點擊:
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
或者放到一個 長度和寬度都為0 的圖片的src 中(圖片不用用戶點擊, 自己就發起請求):
<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">
如果這張圖片放到郵件中, Alice 根本就不會發現什麼. 然而瀏覽器還是會將請求提交到 bank.com 的後台中.
一個真實的事件是發生在2008 年的 uTorrent exploit
假設 bank.com 現在使用 post 請求來傳遞參數的, 那麼這個請求可以簡化為:
這種情況下, a 標簽和 img 標簽都無法發送 post 請求, 但是可以使用 FORM 來完成:
我們還可以利用 JavaScript 來讓文檔載入的時候就發送這個請求:
假設現在銀行使用的是 PUT 將數據放到一個JSON 中發送到後台中:
那麼我們可以利用內嵌的 JavaScript :
幸運的是這段 PUT 請求並不會發送, 因為 同源策略 的限制. 除非你的後台設置了
不論是 GET 請求還是 POST 請求, 如果有賬戶名為Alice的用戶訪問了惡意站點，而她之前剛訪問過銀行不久，登錄信息尚未過期，那麼她就會損失10000資金。
這種惡意的網址可以有很多種形式，藏身於網頁中的許多地方。此外，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味著 如果伺服器端沒有合適的防禦措施的話，用戶即使訪問熟悉的可信網站也有受攻擊的危險。
3. csrf的具體含義
Cross-site request forgery:跨站請求偽造，也被稱成為「one click attack」或者session riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，並且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認為比XSS更具危險性。
示例和特性
« ‹ › »
CSRF攻擊通過在授權用戶訪問的頁面中包含鏈接或者腳本的方式工作。例如：一個網站用戶Bob可能正在瀏覽聊天論壇，而同時另一個用戶Alice 也在此論壇中，並且後剛剛發布了一個具有Bob銀行鏈接的圖片消息。設想一下，Alice編寫了一個在Bob的銀行站點上進行取款的form提交的鏈接，並將此鏈接作為圖片tag。如果Bob的銀行在cookie中保存他的授權信息，並且此cookie沒有過期，那麼當Bob的瀏覽器嘗試裝載圖片時將提交這個取款form和他的cookie，這樣在沒經Bob同意的情況下便授權了這次事務。
CSRF是一種依賴web瀏覽器的、被混淆過的代理人攻擊（deputy attack）。在上面銀行示例中的代理人是Bob的web瀏覽器，它被混淆後誤將Bob的授權直接交給了Alice使用。
下面是CSRF的常見特性：
依靠用戶標識危害網站
利用網站對用戶標識的信任
欺騙用戶的瀏覽器發送HTTP請求給目標站點
風險在於那些通過基於受信任的輸入form和對特定行為無需授權的已認證的用戶來執行某些行為的web應用。已經通過被保存在用戶瀏覽器中的cookie進行認證的用戶將在完全無知的情況下發送HTTP請求到那個信任他的站點，進而進行用戶不願做的行為。
使用圖片的CSRF攻擊常常出現在網路論壇中，因為那裡允許用戶發布圖片而不能使用JavaScript。
防範措施
« ‹ › »
對於web站點，將持久化的授權方法（例如cookie或者HTTP授權）切換為瞬時的授權方法（在每個form中提供隱藏field），這將幫助網站防止這些攻擊。一種類似的方式是在form中包含秘密信息、用戶指定的代號作為cookie之外的驗證。
另一個可選的方法是「雙提交」cookie。此方法只工作於Ajax請求，但它能夠作為無需改變大量form的全局修正方法。如果某個授權的 cookie在form post之前正被JavaScript代碼讀取，那麼限制跨域規則將被應用。如果伺服器需要在Post請求體或者URL中包含授權cookie的請求，那麼這個請求必須來自於受信任的域，因為其它域是不能從信任域讀取cookie的。
與通常的信任想法相反，使用Post代替Get方法並不能提供卓有成效的保護。因為JavaScript能使用偽造的POST請求。盡管如此，那些導致對安全產生「副作用」的請求應該總使用Post方式發送。Post方式不會在web伺服器和代理伺服器日誌中留下數據尾巴，然而Get方式卻會留下數據尾巴。
盡管CSRF是web應用的基本問題，而不是用戶的問題，但用戶能夠在缺乏安全設計的網站上保護他們的帳戶：通過在瀏覽其它站點前登出站點或者在瀏覽器會話結束後清理瀏覽器的cookie。
影響CSRF的因素
«‹ › »
CSRF攻擊依賴下面的假定：
攻擊者了解受害者所在的站點
攻擊者的目標站點具有持久化授權cookie或者受害者具有當前會話cookie
目標站點沒有對用戶在網站行為的第二授權
外部鏈接
4. 360瀏覽器在填寫回復帖子時候出現錯誤提示框：csrf token error。該怎麼解決
你好，我覺的出現你這樣的情況應該是你訪問的網站與你使用的瀏覽器在某些方面存在沖突，你可以換一種兼容性較強的瀏覽器 比如有QQ瀏覽器，他的內核在IE瀏覽器的基礎上做了升級優化。使他的兼容性很強能很好的訪問大多數的網站。另外QQ瀏覽器的安裝包也很小方便下載使用。也不會佔用過多的內存。還望採納