跨站请求伪造漏洞属于下列哪种漏洞类型？

CSRF，全称Cross-Site Request Forgery，请求中文叫跨站请求伪造。伪造它属于**客户端请求伪造类漏洞**，漏洞更具体地说，属于是下列型**服务端未对请求来源做充分校验导致的一种逻辑缺陷**。很多人第一次接触时容易把它和XSS搞混，种漏因为两者都带“跨站”二字，洞类但攻击路径完全不同。跨站XSS是请求攻击者往页面里注入脚本，CSRF是伪造攻击者借用你的浏览器身份去发请求。一个偷数据，漏洞一个骗操作。属于

我最早遇到CSRF是下列型在一个后台管理系统里。当时有个“删除用户”的种漏接口，只校验了Cookie里的session，没做任何token或Referer检查。攻击者只需要在论坛帖子中放一张图片，src指向那个删除接口，再诱导管理员访问，管理员一打开帖子，浏览器就会带着他的登录Cookie去请求删除接口，用户就被删了。整个过程管理员看不到任何异常，页面也没跳转。这就是典型的CSRF——利用浏览器自动携带凭证的机制，伪造一次合法操作。

它到底归到哪一类？

如果按OWASP Top 10来分，CSRF以前长期被归在“失效的访问控制”或“跨站请求伪造”独立类别里。2021版之后，它被合并进“失效的访问控制”（A01:2021）下面。但严格从漏洞原理出发，CSRF属于**会话完整性攻击**，攻击的是“服务器无法区分请求是用户自愿发出还是被第三方诱导发出”。它不是注入漏洞，也不是信息泄露漏洞，而是一种**逻辑漏洞**——利用的是HTTP协议无状态、Cookie自动携带、以及服务端缺乏二次验证这三个条件。

有个细节值得注意：很多人以为加了验证码就防住了CSRF。验证码确实能防，但体验太差。更常见的做法是加CSRF Token，或者检查Origin/Referer头。但Referer检查有时会失效，比如从HTTPS跳转到HTTP时浏览器不发送Referer，或者用户隐私设置屏蔽了Referer。所以Token才是主流方案。

为什么它不算XSS，也不算点击劫持？

XSS是攻击者把恶意脚本注入到受害者的页面里执行，脚本能读Cookie、改DOM。CSRF不需要注入脚本，它只需要一个能发起请求的标签——img、form、iframe都行。点击劫持是诱导用户点击透明层上的按钮，本质是视觉欺骗。CSRF是直接伪造请求，用户可能完全不知情，连点击都不需要。三者攻击面不同，防御手段也各不一样。

我见过一个真实案例：某电商网站的“添加收货地址”接口没有CSRF防护。攻击者构造一个自动提交的表单，把收货地址改成自己的，然后通过邮件或社交消息发给受害者。受害者一打开页面，表单自动提交，地址就被改了。之后受害者下单，商品就寄到攻击者那里。整个过程受害者只是“打开了一个网页”，没有任何点击操作。这种漏洞的危害不亚于XSS，但常常被开发者忽略，因为它的利用门槛看起来更高——攻击者需要知道接口参数格式。

防御的核心思路

别指望前端校验，前端任何校验都能绕过。服务端必须对每一个改变状态的请求（POST、PUT、DELETE，甚至某些GET）做来源验证。最可靠的是同步令牌模式：服务端生成随机token，嵌入表单或请求头，每次请求校验一次。token不能放在Cookie里，否则又变成自动携带了。另外，SameSite Cookie属性也能缓解大部分CSRF，把Cookie设为Lax或Strict，跨站请求就不会带上它。但SameSite不是万能的，老浏览器不支持，子域名场景也有坑。

最后说一句主观判断：CSRF属于那种“不致命但很烦人”的漏洞。它很少直接导致数据泄露，但能悄悄改变系统状态——转账、改密码、删数据。很多SRC平台把CSRF评为中危，我觉得合理。但它特别适合组合攻击，比如配合XSS或者社会工程，危害会放大。所以别因为它“只是伪造请求”就轻视它。