CSRF的防禦可以從服務端和客戶端兩方面著手,防禦效果是從服務端著手效果比較好,現在一般的CSRF防禦也都在服務端進行。
1.服務端進行CSRF防禦
服務端的CSRF方式方法很多樣,但總的思想都是一致的,就是在客戶端頁增加偽隨機數。
(1).Cookie Hashing(所有表單都包含同一個偽隨機值):
這可能是最簡單的解決方案了,因為攻擊者不能獲得第三方的Cookie(理論上),所以表單中的資料也就建構失敗了:>
<?php //构造加密的Cookie信息 $value = “DefenseSCRF”; setcookie(”cookie”, $value, time()+3600); ?>
在表單裡增加Hash值,以認證這確實是使用者發送的請求。
<?php $hash = md5($_COOKIE['cookie']); ?> <form method=”POST” action=”transfer.php”> <input type=”text” name=”toBankId”> <input type=”text” name=”money”> <input type=”hidden” name=”hash” value=”<?=$hash;?>”> <input type=”submit” name=”submit” value=”Submit”> </form>
然後在伺服器端進行Hash值驗證
<?php if(isset($_POST['check'])) { $hash = md5($_COOKIE['cookie']); if($_POST['check'] == $hash) { doJob(); } else { //... } } else { //... } ?>
這個方法個人覺得已經可以杜絕99%的CSRF攻擊了,那還有1%呢....由於用戶的Cookie很容易由於網站的XSS漏洞而被盜取,這就另外的1%。一般的攻擊者看到有需要算Hash值,基本上都會放棄了,某些例外,所以如果需要100%的杜絕,這個不是最好的方法。
(2).驗證碼
這個方案的思路是:每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串,厄....這個方案可以完全解決CSRF,但個人覺得在易用性方面似乎不是太好,還有聽聞是驗證碼圖片的使用涉及了一個被稱為MHTML的Bug,可能在某些版本的微軟IE中受影響。
(3).One-Time Tokens(不同的表單包含一個不同的偽隨機值)
在實作One-Time Tokens時,需要注意一點:就是「平行會話的相容」。如果使用者在一個網站上同時開啟了兩個不同的表單,CSRF保護措施不應該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時站點產生一個偽隨機值來覆蓋以前的偽隨機值將會發生什麼情況:用戶只能成功地提交他最後打開的表單,因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或利用多個瀏覽器視窗瀏覽一個網站。
]產生隱藏輸入域的函數:<?php function gen_token() { //这里我是贪方便,实际上单使用Rand()得出的随机数作为令牌,也是不安全的。 //这个可以参考我写的Findbugs笔记中的《Random object created and used only once》 $token = md5(uniqid(rand(), true)); return $token; }
<?php function gen_stoken() { $pToken = ""; if($_SESSION[STOKEN_NAME] == $pToken){ //没有值,赋新值 $_SESSION[STOKEN_NAME] = gen_token(); } else{ //继续使用旧的值 } } ?>