用 HTML 保护表单：从源头防范 CSRF 攻击

在网页上提交表单时，如果请求带着浏览器已认证的身份信息，攻击者就可以在用户不知情的情况下以用户身份发起操作，比如修改账户信息、删除数据或进行转账。这种在用户端请求上伪造来源的攻击就是跨站请求伪造（CSRF）。

识别风险场景

想象你在一家共享文档网站里编辑资料，退出后又在某个伪装成该网站的页面上提交了“保存”请求——在默认的 HTML 表单提交方式下，这就像你点了自己的保存按钮一样生效。这种场景中，表单提交方式和站点的信任关系，就为 CSRF 攻击提供了温床。

关键防护思路

1) 为表单加入一次性令牌（One-Time Token）

在表单提交时发送一个由服务端生成、不可预测的、一次性使用的令牌，客户端在请求中携带该令牌，服务端仅在验证令牌有效后才执行对应操作。使用 hidden input 或作为请求头传递，关键在于令牌的生成、存储与校验。

• 生成：采用安全的随机数生成算法，避免使用不安全的伪随机
• 传递：建议将令牌放在请求头，比放在查询参数或表单字段更安全
• 校验：服务端严格比对令牌，拒绝任何无效或重复使用的令牌

2) 使用 HTTP 要求方法限制

避免在受保护资源上使用 GET 方法，优先使用 POST、PUT 或 DELETE 等更严格的请求方法。GET 方法在浏览器回退或刷新时也容易重发请求，容易被利用进行 CSRF。

3) 引入双重验证

对关键操作，可以要求用户进行额外的验证，比如二次确认、短信验证码或二次输入安全问题答案。这在关键信息变更场景中尤其有效，能显著降低被欺骗操作的风险。

4) 域名与请求头的双重校验

服务端对请求来源做严格校验，除了检查主机名外，还应检查请求头中的信息（如 Referer、Origin），确保请求来自预期域名，并避免从不可信域名重定向到受保护资源。

5) 限制表单提交的源

对受保护的表单或操作，可以设置只允许从指定域名提交，使用 origin、source 或自定义请求头来标识来源，从而减少从外部来源发起请求的可能性。

实战建议

在实际开发中，优先使用 POST 方法提交敏感操作，并在请求头中附带服务端生成的令牌；对涉及资金或账户安全的关键操作，增加二次验证环节；对请求进行 Origin 与 Referer 的双重核验，减少从伪装页面发起请求的成功概率。

结语

安全不是一蹴而就的，而是在日常开发中持续加固的结果。通过在表单提交环节加入一次性令牌、限制请求方法、必要时加入双重验证等手段，可以在前端就把风险拦截在源头，既保障用户体验，也提升系统的整体安全性。