CSRF攻击原理
跨站请求伪造（CSRF）是一种利用用户已登录的身份，在用户不知情的情况下执行非预期操作的攻击方式。攻击者诱导用户访问恶意页面，该页面携带伪造的请求发送至目标网站，由于浏览器会自动携带用户的Cookie等凭证，服务器会误认为是合法用户发起的操作。
常见攻击场景
- 修改账户信息（如密码、邮箱）
- 进行资金转账或消费
- 以用户身份发布内容
- 利用管理员权限执行高危操作
CSRF防御措施
验证HTTP Referer字段
检查请求头中的Referer字段，确保请求来自合法域名。但存在被篡改或隐私模式下无Referer的风险。
添加Token验证
在表单或请求中嵌入随机生成的Token，服务器端验证Token的有效性。Token需满足不可预测性、一次性使用、绑定用户会话等特性。
使用自定义HTTP头
通过JavaScript添加自定义头（如X-Requested-With），因跨域请求无法携带自定义头。需配合CORS策略使用。
双重Cookie验证
将Token放在Cookie和请求参数中，服务器比对两者是否一致。可避免单纯依赖Cookie的问题。
SameSite Cookie属性
设置Cookie的SameSite属性为Strict或Lax，限制第三方上下文的Cookie发送：
Set-Cookie: sessionid=xxxx; SameSite=Strict; Secure代码示例
服务端生成Token（PHP）
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));前端嵌入Token
<form action="/update" method="POST"> <input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>"> <!-- 其他表单字段 --> </form>服务端验证Token
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) { die("CSRF token validation failed"); }高级防护建议
- 对敏感操作启用二次认证（如短信验证码）
- 限制关键接口的HTTP方法（如只允许POST）
- 记录异常请求日志用于审计
- 结合CAPTCHA验证复杂操作
测试方法
- 使用Burp Suite生成CSRF PoC
- 手动构造恶意HTML表单测试
- 自动化工具如CSRFTester扫描漏洞
- 检查关键接口是否缺失Token或Referer验证
实际案例
某电商平台曾存在CSRF漏洞，攻击者可构造链接强制用户提交购买请求。修复方案包括：
- 为所有POST请求添加动态Token
- 购物车操作增加二次确认
- 交易接口启用SameSite Cookie
通过系统化实施上述防护策略，可有效降低CSRF攻击风险。安全防护需持续更新以适应新的攻击手法。
免责声明
⚠️ 重要提示：
本文作者为网络安全领域初学者，文章内容仅基于学习与研究目的撰写，旨在分享技术原理与实践经验。
- 合法合规：本文涉及的所有技术方法、工具及代码，仅限在合法授权的靶场、本地虚拟机或实验环境中进行验证。严禁利用文中技术对任何未经授权的网络、系统或设备进行扫描、渗透或攻击。
- 法律底线：请严格遵守《中华人民共和国网络安全法》、《数据安全法》及相关法律法规。作者坚决反对一切非法网络入侵行为，呼吁读者共同维护网络安全，切勿利用技术从事危害他人隐私、数据安全或社会公共利益的活动。
- 责任豁免：本文内容仅供技术交流与学术研究参考。任何因读者不当使用、模仿或滥用文中信息而导致的直接或间接后果（包括但不限于法律追责、数据丢失、系统损坏等），作者概不负责，相关法律责任由使用者自行承担。
请在实际操作前充分评估风险，并确保已获得合法的书面授权。
