CSRF學習總結
CSRF攻擊：
Cross-Site Request Forgery。中文解釋爲：跨站請求僞造，具體流程如下圖
也就是說CSRF攻擊具備兩個默認條件：
1.黑客沒有暴力獲取用戶存儲在瀏覽器中的cookie，同源策略仍然能有效保護
2.黑客無法獲取用戶直接訪問A網站獲取的響應，也就是說黑客也不能從響應中解析出任何有關用戶的認證信息
得出的結論是黑客能做的就是做一個惡意網站，當用戶訪問這個惡意網站的時候，點擊了某個鏈接，這個鏈接會向A網站發出請求。其餘的暴力破解session，劫持用戶cookie信息的均不屬於CSRF攻擊
清楚了流程，那麼要做好CSRF保護，可以從兩個方面來實現：
第一：用戶方面，用戶每次訪問網站之後及時退出，基本就能杜絕CSRF的攻擊
第二：網站建立CSRF的保護機制，也就是俗稱的CSRF保護
CSRF保護的手段：
一：驗證HTTP Referer
http協議規定，在瀏覽器發出請求的時候，會在請求頭headers裏附加Referer字段，該字段負責記錄此次請求的來源地址。比如當用戶通過www.baidu.com點擊某鏈接a訪問網站A的時候，瀏覽器發出請求，request headers裏面就會附帶這麼一條信息：Referer:鏈接a的頁面的url
網站A通過對Referer信息的校驗，只要請求來源不是自己站內發出的的請求，統統拒絕，這樣也能防範CSRF攻擊
缺點：過度依賴HTTP協議，如果某瀏覽器沒有嚴格遵循，或者因爲用戶害怕瀏覽記錄被泄漏而關掉Referer，那麼當用戶正常請求網站A的時候，會因爲Referer驗證不通過而被視爲CSRF攻擊，從而請求被拒絕。嚴重影響用戶體驗
二：使用令牌(token)
分析CSRF攻擊的原理可以知道，CSRF之所以能成功，恰恰是因爲黑客利用了瀏覽器的特性：在訪問網站的時候，會攜帶上該網站的所有cookie。那麼，將用戶的有關的權限信息不存儲在cookie裏面，並且，由於同源策略的保護（非同協議，同IP，同端口的不能使用同一個腳本）。其實就不會收到CSRF的攻擊了。
補充：同源策略例子：
在沒有被用戶授權的情況下
當用戶打開網站A頁面的時候如果需要執行腳本文件(例如javascript)，會識別此腳本文件是不是來自於網站A，如果是就執行，不是就不執行。
比較安全的做法在於，當用戶要獲取網站A的用戶權限的時候，網站A通過了校驗，生成一個token令牌，令牌中包含隨機信息，隨着響應一起發送給用戶。同時網站可以將token存儲在本地的sessin中。當用戶再向網站A發出post/put/delete請求的時候，js文件控制在請求中附加上token的信息，網站A收到請求後，首先驗證是否攜帶token，以及攜帶的token值是否正確，如果正確則接收此次請求並處理，如果不正確，拒絕請求。
寫的過程中突然好像又明白了一個問題，之前一直在想，如果token被劫持了之後，豈不是隻要在token有效期內也能任意被使用，後來想了一下，http協議是分層的，傳輸層需要考慮的問題，爲什麼要在應用層煩惱。
記錄兩個網址：
https://www.v2ex.com/t/276207
https://security.stackexchange.com/questions/81756/session-authentication-vs-token-authentication（外文）
裏面的討論很好的區別了基於token的實現和基於session的實現
jwt就是基於token的一種實現，有空研究一下jwt