CSRF的防御可以從服務端和客戶端兩方面着手,防御效果是從服務端着手效果比較好,現在一般的CSRF防御也都在服務端進行。
1.服務端進行CSRF防御
服務端的CSRF方式方法很多樣,但總的思想都是一致的,就是在客戶端頁面增加偽隨機數。
(1).Cookie Hashing(所有表單都包含同一個偽隨機值):
這可能是最簡單的解決方案了,因為攻擊者不能獲得第三方的Cookie(理論上),所以表單中的數據也就構造失敗了:>
$value =“DefenseSCRF”;setcookie(”cookie”, $value, time()+3600);?>
在表單里增加Hash值,以認證這確實是用戶發送的請求。
hash=md5(_COOKIE['cookie']);?>
”>
然后在服務器端進行Hash值驗證:
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保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。
以下我的實現:
1).先是令牌生成函數(gen_token()):
$token = md5(uniqid(rand(), true));return $token;
}
2).然后是Session令牌生成函數(gen_stoken()):
$_SESSION[STOKEN_NAME] =gen_token();
}else{//繼續使用舊的值
}
}?>
3).WEB表單生成隱藏輸入域的函數:
gen_stoken();echo “
value=\”" . $_SESSION[STOKEN_NAME] . “\”>“;
}?>
4).WEB表單結構:
gen_input(); ?>
5).服務端核對令牌:
這個很簡單,這里就不再啰嗦了。