CSRF的防禦執行個體（PHP）

　CSRF的防禦可以從服務端和用戶端兩方面著手，防禦效果是從服務端著手效果比較好，現在一般的CSRF防禦也都在服務端進行。

　　1.服務端進行CSRF防禦

　　服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在用戶端頁面增加偽隨機數。

　　(1).Cookie Hashing(所有表單都包含同一個偽隨機值)：

　　這可能是最簡單的解決方案了，因為攻擊者不能獲得第三方的Cookie(理論上)，所以表單中的資料也就構造失敗了:>

　在表單裡增加Hash值，以認證這確實是使用者發送的請求。

然後在伺服器端進行Hash值驗證

　　這個方法個人覺得已經可以杜絕99%的CSRF攻擊了，那還有1%呢....由於使用者的Cookie很容易由於網站的XSS漏洞而被盜取，這就另外的1%。一般的攻擊者看到有需要算Hash值，基本都會放棄了，某些除外，所以如果需要100%的杜絕，這個不是最好的方法。

　　(2).驗證碼

　　這個方案的思路是：每次的使用者提交都需要使用者在表單中填寫一個圖片上的隨機字串，厄....這個方案可以完全解決CSRF，但個人覺得在易用性方面似乎不是太好，還有聽聞是驗證碼圖片的使用涉及了一個被稱為MHTML的Bug，可能在某些版本的微軟IE中受影響。

　　(3).One-Time Tokens(不同的表單包含一個不同的偽隨機值)

　　在實現One-Time Tokens時，需要注意一點：就是“並行會話的相容”。如果使用者在一個網站上同時開啟了兩個不同的表單，CSRF保護措施不應該影響到他對任何錶單的提交。考慮一下如果每次表單被裝入時網站產生一個偽隨機值來覆蓋以前的偽隨機值將會發生什麼情況：使用者只能成功地提交他最後開啟的表單，因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器視窗瀏覽一個網站。

　　以下我的實現:

　　1).先是令牌產生函數(gen_token())：

 
　2).然後是Session令牌產生函數(gen_stoken())：
     
　3).WEB表單產生隱藏輸入欄位的函數：
      “;     　　}     ?>
　　4).WEB表單結構：
          
　5).服務端核對令牌：
　　這個很簡單，這裡就不再囉嗦了。
　　上面這個其實不完全符合“並行會話的相容”的規則，大家可以在此基礎上修改。
