一篇文章学会csrf

1. 这个网站上有值得你去攻击的功能。比如上面提到的修改邮箱、密码、转账、手机号 等，再不济也得有个增删改的功能吧，如果这个网站只是一个查看数据的地方，那你发起 CSRF 也没什么用，因为你拿不到对方查看的数据。

2. 基于 cookie 的会话处理。这个网站对于客户端发起请求只通过 cookie 进行用户验证，没有其他的会话跟踪和用户验证机制。

3. 没有不可预测的参数。比如 在修改密码的时候需要输入验证码或者原密码，这两个参数攻击者既不知道，也猜不到，那这个功能就不会被 CSRF 成功攻击

1. 打开burp

2. 找到你要测试的那个请求

3. 右键 -> engagement tools -> Generate CSRF PoC

4.视情况改改 POC

5.点击 Test in browser -> copy

6.打开浏览器，粘贴刚才复制的 URL 到浏览器导航栏

7.回车之后如果执行成功那就是有 CSRF 漏洞

8.失败的话就看看报错是什么引起的来判断是POC的问题还是不存在 CSRF 漏洞，这个就需要具体情况具体分析了

1. 攻击者把恶意代码放在其自己控制的网站上，诱导受害者访问这个网站

2. 通过邮件、短信、社交软件进行传播

3. 放在存在该漏洞的网站上，等待有缘人，比如评论区

CSRF 和 XSS 的区别

1. XSS 允许攻击者在受害者的浏览器上执行 js 代码；而 CSRF 不行

2. XSS 通过窃取受害者的 cookie 来实现账号接管，如果目标站点使用了 httponly 这就行不通了；CSRF 通过浏览器发起请求，自动携带受害者的cookie信息，即使有 httponly 也不影响 CSRF 攻击的实现

3. XSS 的危害更大。攻击者如果成功实现了 XSS 攻击，那通常意味着他可以使用受害者在这个网站的所有功能，而 CSRF 只限于特定的存在漏洞的功能

4. CSRF 无法让攻击者获取到服务器返回的数据，由于请求是由受害者的浏览器发起的，那么服务器的响应最后还是给到了受害者那里，攻击者是拿不到这部分数据的，所以对于一些查询类功能，即便没有做任何防御 CSRF 的措施，它也几乎是没有利用价值的；而 XSS 由于可以执行js代码，这也就使得攻击者可以将它想要的数据发送到自己的服务器上，比如前面 XSS 章中提到的回传 cookie。

防御方法

1.【最保险】CSRF Token：通过服务器生成一个唯一的、不可预测的值，然后发送给客户端。当用户要执行敏感操作，比如提交表单的时候，要求客户端在请求包中携带上这个 CSRF Token，这样攻击者就很难去构造一个属于这个用户的有效请求，从而防止 CSRF 的发生。

2.SameSite cookie：该属性可以用于指定是否允许 Cookie 被跨站点请求使用。SameSite 属性有三个可选值：

(1) Strict（严格模式）：Cookie 在任何跨站点请求中都不会被发送，这样可以防止 CSRF 攻击。但这可能会导致某些功能受限，特别是当网站需要在跨站点请求中使用 Cookie 时。

(2) Lax（宽松模式）：Cookie 只在顶级导航（例如从外部网站链接进入的页面）以及 GET 方法的跨站点请求中发送。POST、PUT、DELETE 等请求不会发送 Cookie。这样可以在一定程度上保护用户的隐私和防范 CSRF 攻击。

(3) None（无限制模式）：Cookie 在任何情况下都会被发送，即使是跨站点请求。需要注意的是，使用 None 模式时，必须同时设置 Secure 属性（仅通过 HTTPS 传输）才能生效，并且该模式存在一定的安全风险和隐私问题，应谨慎使用。

3.【可能会有坑】校验 Referer 头：有的网站可能通过验证请求的 referer 是否来自网站自己的域名来防止 CSRF 攻击，但是在一些情况下，这种验证可能无法起到防止 CSRF 的作用

1.使用提供的账号密码登录实验室 wiener:peter

2.可以看到此时默认邮箱是 [email protected] ，我们先随便修改一个抓个包，修改后的 [email protected]

3.我们可以看到，这里只提交了一个修改后的邮箱，这里我们可以使用 burp 自带的功能来生成 POC

4.现在我们要做的就是把邮箱修改成我们自己的 [email protected]，所以我们只需要修改 value 中的值就可以了

5.对于我们平时的测试来说，下一步点击 Test in browser -> copy 然后在同一个浏览器打开，来模拟受害者点击我们传播的 url 即可

6.此时我们会发现邮箱已经被改变了，对于日常的测试来说到这里就可以了，但是想要通过这个实验室，还需要后面的几步，这里让我们回到第4步，同时把邮箱改回 [email protected]，以便下面的演示

7.将我们刚才修改后的POC复制到，实验室对应的利用服务器上

8.将 HTML 复制到 body 中，同时点击 store 保存

9.现在我们就要模拟受害者在登录了 web-security-academy.net 这个网站的时候，受到攻击者诱导，在攻击者的网站 exploit-server.net 上点击了一个功能 (View exploit) 然后浏览器自动发起修改 web-security-academy.net 上用户绑定邮箱的场景。点击 View exploit

10.可以看到，网站自动跳转到 web-security-academy.net 并将邮箱从 [email protected] 修改为了 [email protected]，那么点击 deliver exploit to victim 将你的 POC 传播给受害者们就可以通过这个实验室了

1. 前面的过程我们就直接略过，我们看看它的修改邮箱的功能是如何实现的

2.这里我们可以看到是存在一个 CSRF token 的，我们删了它看看会怎么样，万一这玩意儿就是用来吓唬人的呢

3. 很遗憾，看来他还是有用的，但是不要放弃，我们都知道由于一些奇奇怪怪的原因，研发在写代码的时候可能会出现一些奇怪的 bug，可能他们没有想到有些用户他不喜欢老老实实的使用他们开发的系统，这里我们用的就是这个思路

4. 当你在使用 get 方法提交一些数据的时候，我们也可以使用 POST 来提交，那这里我们能不能用 get 来修改邮箱呢，那我们就试试

5. surprise，它居然可以，那我们删了 CSRF 这个参数看看它的处理逻辑有没有变化

6. 哈 get 方法居然没有校验 CSRF 了，那我们就继续老样子，右键生成 POC，保存到 利用服务器 就完事了

7. 收工下班

1. 老样子，我们看看他是怎么修改邮箱的

2. 和上面的案例没什么区别，那我们还是看看删除 CSRF 这个参数的结果怎么样

3. 哈 这个更简单了，直接干，右键生成 POC，上传 利用服务器，就完事了，这里就不赘述了

1. 这个演示需要两个账号 wiener:peter 和 carlos:montoya

2. 我们先登录 wiener，看看它的修改邮箱是怎么实现的

3. 请求包还是一样的，我们看下上面的两种方式还能不能绕过 （当然不行，这里就不演示了）

4.这里我们先记录一下wiener的token值 roVAju4ZU5DLlKwBO9n0GzqvERfXumk8，然后登出当前账号，再次重新登录 carlos 看看刚才的 token 还能不能使用

5. 这里我们使用 Intercept 拦截修改 CSRF 的值之后发现是无效的，现在就有几种可能，一是 token 和 session 绑定，不能使用别人的 token 来绕过校验；二是 token 是一次性的，用后即焚；三的话就是我们的主题 是公共token池，但是用后即焚

6. 第一种可能上面已经验证过了，那么我们来验证第二种，其实也很简单，再修改一下邮箱，看看服务器有没有下发新的 CSRF token 就行了，或者看看两次传递的 token 是不是一样的

7. 不太妙啊，居然是一次性的，那我们只能试试第三中情况了，让我们保存下现在的 token 不要用它 0wSAAuvFa8JFRSpD1BgSQifWo75xeJyt 然后登出 carlos 登录 wiener 在修改邮箱的时候替换 CSRF 的值，看看结果如何

8. 哈哈 成功了，那么它的逻辑就很清楚了，用户每次修改邮箱的时候需要一个服务器下发的一次性 CSRF token，但这个 token 并没有与session绑定，而是从 公共token池 中提取的，那么我们就可以通过自己的账号来获取一个有效的 CSRF token 来绕过这个校验机制，只不过每次有用户上钩之后我们需要刷新这个 token 值

9. 思路清晰之后我们只有重复上面案例中的过程就可以了，这里就不再赘述了

1. 我们还是来看它的修改邮箱是如何实现的

2. 这里可以看出他们是相同的，那么我们就需要一个地方来想办法注入 set-cookie，巧的是在搜索这里存在一个 CRLF 漏洞 payload %0d%0aSet-Cookie:%20csrf=123456%3b%20SameSite=None

3. 那么我们就可以在自己的服务器上（exploit-server.net）构造一个响应，让它去请求 web-security-academy.net 上的资源，然后发起一个请求来实现 CRLF 注入，之后再发送请求去修改邮箱就好了，思路有个那下面就是payload了

4. 老样子我们先生成一个 CSRF 的POC

5. 下面我们来做一下修改，让它来实现我们的功能，其实只需要修改

•   <html><!-- CSRF PoC - generated by Burp Suite Professional --><body>  <form action="https://0a7c00ee0362ba6884d4dc8700fe006e.web-security-academy.net/my-account/change-email" method="POST">    <input type="hidden" name="email" value="111&#64;normal&#45;user&#46;net" />    <input type="hidden" name="csrf" value="123456" />    <input type="submit" value="Submit request" />  </form>    <img src="https://0a7c00ee0362ba6884d4dc8700fe006e.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=123456%3b%20SameSite=None" onerror="document.forms[0].submit();"/></body></html>

6. 上面的代码我们主要是利用了 img 标签去请求 web-security-academy.net 上的一个不存在的图片，当它发送这个请求的时候， web-security-academy.net 的 cookie 中的 csrf 键将被设置为 csrf=123456，当请求失败的时候，就会提交我们的 CSRF 代码来修改邮箱，那么我们来看看效果

7. 这样我们的攻击就完成了，后边提交通过实验室的过程就不再赘述了

1. 前面的过程我们先跳过，直接看看他是怎么发起修改邮箱的请求的

2. 这里可以看到成功修改的话会自动跳转，同时请求包里有 referer 头，那我们看看把他该一下会是什么响应

3. 这里报错无效的 referer，那我们看看删了它会有什么响应，毕竟对于很多情况下删除某些参数往往会有意外之喜

4. 可以看到同样修改成功了，那么下一步就是如何在 POC 里让它不发送 referer 头了，这里就用上我们上面提到的 meta 标签了，下面我们看看有 meta 和没有的区别

5. 老样子，还是生成一个 POC

6. 可以看到，这样的POC发送的请求是含有 referer 头的，那我们给它稍微加点料 payload

7. 神奇的事情发生了，referer 头没有了，那就意味着这个referer校验被我们绕过了，收工下班

我们在控制台执行 history.pushState("","","/?^_^")，它的url就变成了 https://www.baidu.com/?^_^

1. 老样子，直接看它的修改邮箱的请求包

2. 没什么东西，看看referer是怎么校验的吧（删掉不好使，就不试了）

3. 可以看到，上面的两种方法都能绕过，那就说明是校验 referer 中是否含有域名，那我们还是生成 POC，然后稍微修改一下 payload history.pushState("", "", "/?0afc003404932ab58ac96e4e005700a5.web-security-academy.net")

4.这里可以看到，虽然我们加上了 history.pushState("", "", "/?0afc003404932ab58ac96e4e005700a5.web-security-academy.net") 但是它请求的时候 referer 并没有包含其中自定义的 uri。这是因为现在浏览器出于安全考虑会在请求的时候删除 referer 中的查询字段，但是这个也是可以解决的，不过就需要有点钞能力了，你可以租个服务器，设置响应头 Referrer-Policy: unsafe-url ，这样再次请求的时候就不会删掉你referer中的查询值了

5. 这里我们使用靶场自带的利用服务器来演示

6. 配置完成之后点击 store，然后访问上面的url

7. 可以看到在访问 我们利用服务器上的页面之后，其正常响应了 referrer-policy，之后再次请求目标网站的时候，客户端就没有删除referer 头里的查询参数了，至此绕过也就完成了，收工下班