php会话本身不防csrf，必须配合显式令牌机制才能有效防御；仅靠session_start()或$_session存储用户状态无法阻止伪造请求，因浏览器自动携带cookie发起请求，服务器仅凭session id存在即执行操作，构成漏洞根源。
PHP会话本身不防CSRF，必须配合显式令牌机制才能有效防御。仅靠session_start()或$_SESSION存储用户状态，完全无法阻止攻击者伪造请求。
为什么不能只依赖会话存在性校验
CSRF攻击的关键在于：浏览器自动携带当前域的Cookie（含Session ID）发起请求，服务器仅凭Session ID存在就执行操作——这正是漏洞根源。攻击者根本不需要知道Session ID内容，只要用户已登录，就能诱使其浏览器“代为提交”。
- 会话ID可能通过Referer、日志、中间代理等途径泄露，但即使没泄露，CSRF仍可发生
-
$_SESSION是服务端存储，但攻击者不读取它，而是利用浏览器自动发送Cookie的特性 - 所有POST/PUT/DELETE等状态变更请求，只要没额外校验，都可能被伪造
必须生成并验证CSRF Token
Token不是可选增强项，而是CSRF防护的强制前提。它要满足三个条件：随机性强、绑定会话、一次性使用。
- 用
random_bytes(32)生成，再经bin2hex()转为字符串，避免弱熵（别用mt_rand()或uniqid()） - 存入
$_SESSION['csrf_token']，且**不在URL或日志中输出**；表单里用htmlspecialchars()转义后输出到value属性 - 验证时必须用
hash_equals()比较，防止时序攻击；验证通过后立即unset($_SESSION['csrf_token'])，防止重放 - GET请求一般不需Token，但涉及状态变更的GET（如删除链接）也应改用POST+Token，或至少加
SameSite=Lax
SameSite Cookie属性是辅助，不是替代
SameSite=Lax能拦截大部分跨站POST请求，但它在旧版浏览器（如IE、早期Android WebView）中不生效，且对“同站子域名”请求无约束（例如a.example.com向b.example.com发请求仍会带Cookie）。
- 设置方式：在
session_set_cookie_params()中传入['samesite' => 'Lax']，或用setcookie()单独配置 - 不要设
SameSite=None却不配Secure，否则现代浏览器直接拒绝该Cookie - 若应用支持API调用或iframe嵌入，
Lax可能误杀合法请求，此时必须坚持Token校验
容易被忽略的边界场景
很多项目只在主表单加Token，却漏掉几个关键点：
- AJAX请求同样需要携带
csrf_token字段（不能只靠X-Requested-With头，它可被伪造） - 多标签页并发时，若Token被
unset后另一个标签页提交失败，应允许Token刷新（比如页面加载时重新生成并更新隐藏字段） - 登出操作本身也要防CSRF——否则攻击者可诱导用户登出，再配合其他手段提升权限
- 如果用了自定义会话处理器，确保
read()方法不返回空会话数据，否则$_SESSION['csrf_token']可能未初始化就跳过校验
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
