用claude修复php csrf，先找出依赖cookie身份的状态修改接口，再把服务端令牌验证放到业务写入之前。下面给出会话表单示例、完整校验函数及正常和拒绝请求的回归方法。
优先排查修改资料、删除和绑定操作
CSRF排查不能只看登录页面。修改邮箱、地址、偏好设置和删除记录等接口，只要依赖浏览器自动携带的Cookie认证，就应确认是否具备请求来源和令牌方面的防护。
先把所有会修改数据状态的路由全部捋一遍，逐个登记清楚每个路由的请求方法、目前在用的认证方案、有没有接入CSRF中间件，还有真正执行数据写入的代码所在位置。
至今还在靠GET请求修改数据的老旧接口，要单独拎出来优先整改，别觉得把操作按钮藏深点、或者接口要求登录就不会出安全问题。
浏览器存了登录身份，不代表请求符合用户真实意愿
浏览器会按Cookie规则向站点发送身份信息，服务器若只检查登录状态，可能无法区分用户主动提交与外部页面诱导的请求。同步令牌方案把不可预测的值保存在服务端会话，并要求表单带回匹配值；
校验必须发生在状态修改之前。SameSite和来源检查可作为额外防线，但不能忽视合法跨站流程、客户端XSS以及框架本身的保护机制。
让Claude排查完整请求链路，别只补个隐藏字段就草草收尾
新建Claude会话，提供脱敏后的路由、登录会话设置、表单和处理函数。明确令牌由谁生成、页面是否缓存、前端是否采用异步请求，避免只上传一个控制器片段。
要求先指出哪些接口会写入数据，以及中间件是否在写入之前执行。已有框架保护时优先修复配置或接入方式，不另外堆一套相互冲突的令牌系统。
要求给出令牌生成、页面传递、后端校验和错误响应的完整差异。重点核对空令牌不能通过、数组输入不会触发异常放行、令牌没有被写进URL或公开日志。
运行测试后，再用测试账号打开表单提交一次，并分别删除、篡改令牌。确认拒绝请求不产生数据变化，而不只是页面显示错误文字。
审查这些PHP会话认证接口的CSRF防护。 先列出所有写入点与现有中间件，再给最小补丁。 同步令牌由random_bytes生成并存入服务端会话，POST前验证用户和令牌。 缺失、错误类型、空值、不匹配令牌均应拒绝；任何验证失败都不能先写入数据。 保留框架已有保护，不把SameSite或隐藏字段单独描述成完整方案。 给正常请求及四类拒绝测试，另列浏览器Cookie和跨站业务待验收项。
完整参考示例：先走校验流程，再保存会话偏好设置
下面文件在命令行运行校验测试，在Web环境提供一个主题设置表单。Web分支依赖项目已有登录会话，只保存当前会话偏好；它不是账号登录实现，也不连接生产数据库。
<?php declare(strict_types=1);
function requireChange(string $method, array $session, mixed $provided): void {
$known = $session['csrf'] ?? null;
if ($method !== 'POST' || !is_int($session['user_id'] ?? null) || $session['user_id'] < 1 ||
!is_string($known) || !preg_match('/^[a-f0-9]{64}$/D', $known) ||
!is_string($provided) || strlen($provided) !== 64 || !hash_equals($known, $provided)) {
throw new InvalidArgumentException('Forbidden');
}
}
if (!in_array(PHP_SAPI, ['cli','phpdbg','wasm'], true)) {
// 示例按HTTPS部署；user_id必须由已有登录流程设置。
session_start(['use_strict_mode'=>1,'cookie_httponly'=>true,
'cookie_secure'=>true,'cookie_samesite'=>'Lax']);
if (!is_int($_SESSION['user_id'] ?? null) || $_SESSION['user_id'] <input type="hidden" name="csrf" value="'.$token.'">';
echo '<select name="theme"><option value="light">Light</option>
<option value="dark">Dark</option></select>';
echo '<button type="submit">Save</button>';
exit;
}
try {
requireChange($_SERVER['REQUEST_METHOD'], $_SESSION, $_POST['csrf'] ?? null);
$theme = $_POST['theme'] ?? null;
if (!is_string($theme) || !in_array($theme, ['light','dark'], true)) {
http_response_code(400); exit('Invalid theme');
}
$_SESSION['preferred_theme'] = $theme; // 校验全部通过后才修改状态。
echo 'Saved';
} catch (InvalidArgumentException $e) { http_response_code(403); echo 'Forbidden'; }
exit;
}
$token = bin2hex(random_bytes(32));
$session = ['user_id'=>7,'csrf'=>$token];
requireChange('POST', $session, $token);
echo 'valid_post: PASS', PHP_EOL;
foreach ([['get_write','GET',$session,$token], ['missing_token','POST',$session,null],
['wrong_token','POST',$session,str_repeat('0',64)], ['anonymous','POST',['csrf'=>$token],$token]]
as [$name,$method,$state,$submitted]) {
try { requireChange($method,$state,$submitted); }
catch (InvalidArgumentException $e) { echo $name, ': PASS rejected', PHP_EOL; continue; }
throw new RuntimeException('FAIL: '.$name);
}
echo 'Runtime: PHP ', PHP_VERSION, ' / ', PHP_SAPI, PHP_EOL;
php audit.php
本次已在macOS上的PHP 8.5.10 WebAssembly执行五项函数测试。HTTPS、Cookie实际携带行为与真实浏览器表单还未联调，运行图不能替代这些环境验收；代码也不是Claude每次必然生成的内容。
普通表单和异步请求，令牌的传递位置不一样
| 请求方式 | 令牌传递 | 验证重点 |
|---|---|---|
| 服务端渲染表单 | 隐藏表单字段 | 页面未串用其他用户令牌 |
| 同源异步请求 | 框架约定的请求头或字段 | 全局请求封装及服务端中间件一致 |
登录成功后应按项目策略更新会话身份，并在退出时正确失效会话。令牌轮换也要考虑多标签页和重复提交，不能为了阻止旧请求而让用户已打开的正常表单全部无提示失效。
公共缓存不能复用包含个人令牌的页面，排查日志也不要记录令牌原文。若网站存在XSS，攻击脚本可能读取页面中的令牌，因此CSRF整改不能替代输出编码和脚本安全检查。
遇到这四类报错，一定要查清根因
- 正常POST被拒绝：检查会话Cookie、HTTPS配置与表单令牌是否属于同一个会话。
- 只有前端检查令牌：把验证放到服务端，不能依赖按钮是否可点击。
- 报错后数据却已改变：检查校验与数据库写入顺序，并补上“拒绝时无副作用”的测试。
- 开启SameSite后跨站流程失败：区分第三方回调与普通表单，按具体协议设计，不直接关闭全部防护。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
