csrf的防禦可以從服務端和客戶端兩方面著手，防禦效果是從服務端著手效果比較好，現在一般的csrf防禦也都在服務端進行。
1.服務端進行csrf防禦
服務端的csrf方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機數。
(1).cookie hashing(所有表單都包含同乙個偽隨機值)：
這可能是最簡單的解決方案了，因為攻擊者不能獲得第三方的cookie(理論上)，所以表單中的資料也就構造失敗了:>12
345<?php
//構造加密的cookie資訊
$value = 「defensescrf」;
setcookie(」cookie」, $value, time()+3600);
?>
在表單裡增加hash值，以認證這確實是使用者傳送的請求。12
3456
789<?php
$hash = md5($_cookie['cookie']);
?>
然後在伺服器端進行hash值驗證12
3456
78910
1112
<?php
if(isset($_post['check'])) 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())：12
3456
7<?php
function gen_token()
2).然後是session令牌生成函式(gen_stoken())：12
3456
78910
1112
<?php
function gen_stoken()
else
}?>
3).web表單生成隱藏輸入域的函式： 12
3456
7<?php
function gen_input()
?>
4).web表單結構：12
3456
78910
<?php
session_start();
include(」functions.php」);
?>
5).服務端核對令牌：
這個很簡單，這裡就不再囉嗦了。
上面這個其實不完全符合「並行會話的相容」的規則，大家可以在此基礎上修改。
原文：
CSRF的防禦例項（PHP）
原文連線 csrf的防禦可以從服務端和客戶端兩方面著手，防禦效果是從服務端著手效果比較好，現在一般的csrf防禦也都在服務端進行。1 服務端進 csrf的防禦可以從服務端和客戶端兩方面著手，防禦效果是從服務端著手效果比較好，現在一般的csrf防禦也都在服務端進行。1.服務端進行csrf防禦 服務端的...
samesite cookie防禦CSRF漏洞
samesite cookie機制本意是為了減少網路請求包，設想下，b.com 展示a.com下的，b站每向a請求一張，都會攜帶上a域下的cookie，而這些cookie對於請求來說毫無意義，無意中增加請求包大小 samesite有三個屬性lax,strict,none lax b站上通過超連結訪問...
CSRF的防禦之HttpOnly
csrf攻擊的全稱是跨站請求偽造 cross site request forgery 是一種對 的惡意利用，儘管聽起來跟xss跨站指令碼攻擊有點相似，但事實上csrf與xss差別很大，xss利用的是站點內的信任使用者，而csrf則是通過偽裝來自受信任使用者的請求來利用受信任的 你可以這麼理解csr...