CSRF

Att@ckxu2025-05-272025-05-29

同源策略

在web浏览器中，允许某个网页脚本访问另一个网页的数据，但前提是这两个网页必须同源。不同源的客户端脚本在没有明确授权的情况下，不能读写对方的资源，比如Cookie等。同源策略是一种安全思想，但并不是统一的规范体系

前端人员都懂的浏览器的同源策略，以及如何进行不同源间的相互访问_浏览器同源策略可怎么深问-CSDN博客

同源：协议、域名、端口都相同

CSRF

介绍

跨站请求伪造，是一种通过挟持当前用户已登录的web应用程序从而实现非用户本意的操作的攻击方法。

攻击者通过一些技术手段，挟持用户去访问用户曾经认证过的网站并进行一些操作（例如发邮件、发信息、转账等）。由于浏览器曾经认证过，所以被访问的网站会认为是真正用户所进行的操作而去执行

与XSS相比来说，XSS可以获取用户凭证（Cookie），而CSRF只是利用用户凭证在用户不知情的情况下执行某些操作，通俗的说XSS可以执行任意JS，而CSRF只是请求伪造而已

成因

没有检查Referer请求头

没有在头部设置token

危害

盗取账号，以用户名义发邮件、发消息、购买商品、转账

（CSRF能做什么，取决于网站能够做什么）

攻击流程

1.用户C打开浏览器，访问受信任网站A,输入用户名和密码请求登录网站A;

2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A;

3.用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B;

4.网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A:

5.浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意请求被执行。

本质：利用cookie在同源请求中携带发送给服务器的特点，来实现冒充用户。

CSRF三要素

操作

想让受害者做什么，转账、修改密码等

认证

基于Cookie的会话处理

没有不可预测的参数

因为要事先构造请求，所以不能有不可预期的参数，比如密码等

示例

一个修改绑定邮箱的请求包

POST /email/change HTTP/1.1 
Host: vulnerable-website.com 
Content-Type: application/x-www-form-urlencoded 
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
Content-Length: 30 

email=wiener@normal-user.com

如果网站里存在CSRF，就可以构造Poc

<html>
<body> 
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" /> 
</form> 
<script> document.forms[0].submit(); </script> 
</body> 
</html>

Poc保存为html文件，诱使受害者访问该文件，受害者在没有退出https://vulnerable-website.com这个网站的情况下，就会携带Cookie向https://vulnerable-website.com/email/change提交一个POST请求，修改邮箱

类型

GET型CSRF

受害者A（admin/password）登录了网站，网站里有修改密码的功能

攻击者B（smithy/password）也登录网站获取网站里修改密码的参数，因为同样的网站同等级的用户里面的功能是一样的

http://127.0.0.1/DVWA/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#

攻击者在网站中修改密码，获取修改密码的参数，（由于是GET型，参数在URL中）将URL发送给受害者A，（如果网站中存在存储型XSS漏洞，还可以将链接插入进去），受害者在没有退出网站的情况下点击了链接，就会执行攻击者所想让他执行的操作，密码被无意修改了

在测试的时候，如果在一台电脑自行测试，模拟攻击者和受害者使用不同浏览器

POST型CSRF

攻击者：

进行攻击操作（修改个人资料等）并抓包

构造恶意请求

copy生成的html，保存到一个文件

将文件发送给受害者，诱使受害者访问这个文件

当受害者登录了相同的网站，同时访问了这个文件，攻击就被执行，受害者的个人信息就被修改了

修复

Referer检查。攻击者虽然是利用用户的请求进行访问，但是Referer的内容显示的是B网站，也就是攻击者自己构造的网站。如果对Referer进行白名单检查，看是否来自合法的网站。如果不是，就极有可能是CSRF攻击。
添加Token验证。CSRF攻击成功的原因就是利用用户已经认证过的cookie信息。cookie中的身份信息在请求时会自动添加，所以我们要在cookie外再加入一种验证身份的信息。具体的做法是在HTTP请求中，以参数的形式加入一个随机产生的Token，并在服务器端建立一个拦截器来验证这个Token，如果请求中没有Token或者Token内容不正确，则认为可能是CSRF攻击而拒绝该请求。

XSS&CSRF组合拳

XSS可能在中低危，组合起来可能变成高危

在XSS，如果网站设置了http-only就不能获取Cookie了，我们换种思路，不再去窃取用户的Cookie，而是直接利用它

例如：在存在XSS漏洞的A网站上注入一条链接，当用户点击之后，进入攻击者提前写好的网站B，触发网站B中，例如这样的恶意代码，这时候由于用户带有A网站的认证信息，B网站利用用户此时的请求，篡改GET或POST表单内的参数，在用户不知情的情况下请求A网站，完成转账，修改密码等恶意操作。

除了img标签之外，还可以使用各种可以使用src属性值的标签，比如：script标签、link标签等。

CSRF利用

黑盒手工利用测试，白盒看代码检验（有无token，来源检验等）

绕过CSRF防御 - 先知社区

无防护情况下

生成：BurpSuite->Engagement tools->Generate CSRF Poc

但是这不是我们想要的，我们想要的效果就是受害者一访问就会自动触发，还需要在修改下POC数据包

利用：将文件放到自己的站点下，诱使受害者访问（或配合XSS触发访问）

绕过Referer

绕过1：去掉Referer（代码逻辑问题）

在Poc中添加如下内容（目的是删除Referer请求头）

<meta name="referrer" content="no-referrer">

绕过2：修改Referer（校验代码不严格）

校验源代码

校验方式可能为：

完全匹配：referer被设定为某个特定值，不完全匹配则不接收数据包

模糊匹配：referer中只要含有某个特定值即可

可以尝试将Poc中的Referer的内容更改为测试网站的url

模糊匹配

绕过3：配合文件上传绕过

绕过4：配合存储XSS绕过

绕过Token

token(令牌,也可以理解为暗号,在数据传输之前，要先进行暗号的核对，暗号不一致则拒绝数据传输)

每次传递数据时，数据包会携带不同的Token，我们如果将含有Token的Poc发送给受害者，当受害者点击时，Poc中的Token失效，导致攻击不成功

CSRF_token 对关键操作增加Token参数，token必须随机，每次都不一样，存储在cookie中，与验证码一样

复用

代码逻辑不严谨，Poc中的Token对于受害者来说仍然可以使用，Token作用没有被体现

操作和没有Token验证一样

删除

将Token的整个值删掉

置空

将Token的参数置空，保留Token=