CodeIgniter防御CSRF方法及安全加固

CodeIgniter的CSRF防护并非简单开启配置即可生效，而是一项需严格闭环的四步协同机制：启用配置、显式注册过滤器（CI4）或设置参数（CI3）、在表单中正确输出CSRF token、并始终通过框架推荐方式（如`$this->request->getPost()`）读取POST数据——任一环节缺失都将导致防护形同虚设；本文深入剖析CI4中Filters.php的精准配置要点与验证技巧，以及CI3中手动嵌入token与输入校验的关键实践，帮你避开“token生成了却未验证”的常见陷阱，真正筑牢Web应用的第一道防 CSRF 防线。

CSRF保护在 CodeIgniter 中不是“开了配置就自动生效”的功能，必须同时满足四个动作：启用机制、挂载过滤器/配置、输出 token 到表单、用正确方式读取 POST 数据——缺一不可。否则你看到的只是 token 生成了，但验证根本没跑。

CI4 必须在 Filters.php 中显式注册 csrf 过滤器

光改 app/Config/Security.php 里的 $csrfProtection = 'cookie' 或 $csrfRegenerate = true，只是准备好了 token 存储方式；不把它挂进请求生命周期，所有 POST 请求都会绕过校验。

• 打开 app/Config/Filters.php，确认顶部有 use CodeIgniter\Filters\CSRF;，否则类名解析失败，过滤器静默失效
• 在 $globals['before'] 数组中加入 'csrf'：$globals = ['before' => ['csrf']]
• 若只想保护部分路由（如登录、支付），改用 $methods['post'] = ['csrf']，再配合 Routes.php 中的 $route['login'] = ['filter' => 'csrf', 'handler' => 'Auth::login']
• 验证方法：向受保护路由发一个无 token 的 POST 请求，应返回 403 Forbidden 状态码，而不是跳过或报 500

CI3 启用后仍需手动配合表单与输入方法

$config['csrf_protection'] = TRUE 写进 application/config/config.php 是起点，不是终点。CI3 不依赖过滤器机制，但要求你“手把手”把 token 塞进表单、再让框架从正确入口读取。

• 表单中必须包含隐藏域：，或直接用 form_open() 自动注入
• 控制器中获取数据时，必须用 $this->input->post(null, TRUE)——第二个参数 TRUE 才触发 CSRF 校验；只写 $this->input->post('field') 就等于没开保护
• 若需对特定 URI（如 /login）条件启用，可在 config.php 中动态判断：if (stripos($_SERVER['REQUEST_URI'], '/login') !== FALSE) { $config['csrf_protection'] = TRUE; }

AJAX 提交时 token 失效的典型原因和修复

CI4 默认 $csrfRegenerate = true，每次请求都刷新 token。前端如果只在页面加载时取一次 csrf_token() 和 csrf_hash()，第二次 AJAX 就必然 403——因为服务端的 token 已变，而你发的还是旧值。

• 别用 $.ajaxSetup({ headers: { 'X-CSRF-TOKEN': 'xxx' } }) 硬编码初始值，那是快照，一用就废
• 正确做法：监听每次响应头或 JSON 返回里的新 token，全局更新 JS 变量，比如 window.csrfToken = data.csrf_token，再在下次请求中带上
• CI3 默认不自动刷新，若想多标签兼容，可设 $config['csrf_regenerate'] = FALSE，但注意这会略微降低防护强度
• 走 API 路线（如 Uppy 文件上传）时，建议后端在 OPTIONS 预检响应里带 Access-Control-Allow-Headers: X-CSRF-TOKEN，前端再用 header 方式传，避免混在 body 里被过滤器忽略

手动生成表单或 JS 提交时漏掉隐藏域

用 DataTable 行点击、Uppy 文件上传、或纯 JS 动态创建