1.什麼是csrf？
CSRF 的全稱是“跨站請求僞造”，而 XSS 的全稱是“跨站腳本”。看起來有點相似，它們都是屬於跨站***——不***服務器端而***正常訪問網站的用戶，但前面說了，它們的***類型是不同維度上的分 類。CSRF 顧名思義，是僞造請求，冒充用戶在站內的正常操作。我們知道，絕大多數網站是通過 cookie 等方式辨識用戶身份（包括使用服務器端 Session 的網站，因爲 Session ID 也是大多保存在 cookie 裏面的），再予以授權的。所以要僞造用戶的正常操作，最好的方法是通過 XSS 或鏈接欺騙等途徑，讓用戶在本機（即擁有身份 cookie 的瀏覽器端）發起用戶所不知道的請求。
嚴格意義上來說，CSRF 不能分類爲注入***，因爲 CSRF 的實現途徑遠遠不止 XSS 注入這一條。通過 XSS 來實現 CSRF 易如反掌，但對於設計不佳的網站，一條正常的鏈接都能造成 CSRF。
例如，一論壇網站的發貼是通過 GET 請求訪問，點擊發貼之後 JS 把發貼內容拼接成目標 URL 並訪問：
http://example.com/bbs/create_post.php?title=標題&content=內容
那麼，我只需要在論壇中發一帖，包含一鏈接：
http://example.com/bbs/create_post.php?title=我是&content=哈哈
只要有用戶點擊了這個鏈接，那麼他們的帳戶就會在不知情的情況下發布了這一帖子。可能這只是個惡作劇，但是既然發貼的請求可以僞造，那麼刪帖、轉帳、改密碼、發郵件全都可以僞造。
2.csrf漏洞的原理
CSRF***事件的跟蹤圖
3.CSRF可以做什麼？
你這可以這麼理解CSRF***：***者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬......造成的問題包括：個人隱私泄露以及財產安全
4.csrf的常見觸發點
5.csrf漏洞的危害
6.csrf漏洞配合xss漏洞進行密碼修改
通過dvwa中csrf的密碼修改進行抓包獲取修改的主要信息，然後丟棄數據包
![捕獲4.JPG]( "1539687466206899.jpg")
在dvwa的存儲型xss中輸入<a href="http://xxx.xxx.xxx.xxx/dvwa-master/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change">aaa</a>
![捕獲5.JPG]( "1539687724949895.jpg")
點擊aaa標籤，然後發現修改密碼成功
![捕獲6.JPG]( "1539687786859236.jpg")
7.csrf漏洞防禦
. 
服務端進行CSRF防禦
服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加僞隨機數。
(1).Cookie Hashing(所有表單都包含同一個僞隨機值)：
這可能是最簡單的解決方案了，因爲***者不能獲得第三方的Cookie(理論上)，所以表單中的數據也就構造失敗了:>
(2).驗證碼 這個方案的思路是
每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串，厄....這個方案可以完全解決CSRF，但個人覺得在易用性方面似乎不是太好，還有聽聞是驗證碼圖片的使用涉及了一個被稱爲MHTML的Bug，可能在某些版本的微軟IE中受影響。
(3).One-Time Tokens(不同的表單包含一個不同的僞隨機值)
在實現One-Time Tokens時，需要注意一點：就是“並行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護措施不應該影響到他對任何表單的提 交。考慮一下如果每次表單被裝入時站點生成一個僞隨機值來覆蓋以前的僞隨機值將會發生什麼情況：用戶只能成功地提交他最後打開的表單，因爲所有其他的表單 都含有非法的僞隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。
通過 驗證 HTTP Referer 字段、在請求地址中添加 token 並驗證 或者在 HTTP 頭中自定義屬性並驗證。
儘量不要在頁面的鏈接中暴露用戶隱私信息。
對於用戶修改刪除等操作最好都使用post 操作 。
避免全站通用的cookie，嚴格設置cookie的域。