故事开始

在分析一个 Web 应用程序的“更改电话号码”功能时，我注意到表单和标头中没有 CSRF 令牌。这表明该应用程序可能容易受到跨站请求伪造 (CSRF)攻击。我的目标是利用此漏洞更改受害者的电话号码，最终实现账户接管。

什么是 CSRF 攻击？

跨站请求伪造 (CSRF)攻击是一种恶意攻击，攻击者诱骗受害者在已经通过身份验证的 Web 应用程序上执行非预期的操作。

例如，如果用户登录其银行会话并访问恶意网站，攻击者可以伪造请求，将资金从用户的帐户转移到攻击者的帐户 - 而无需征得用户的同意。

漏洞

更改电话号码的请求如下所示：

POST /change_phone HTTP/1.1主机：example.com Cookie：session_cookie=YOUR_SESSION_COOKIE number=011.xxxxxx

值得注意的是，请求中没有 CSRF 令牌，因此它成为潜在的攻击目标。

尝试利用漏洞

我编写了一个概念验证 (PoC)来利用这个 CSRF 漏洞。然而，在测试过程中，PoC 未能按预期工作。这引出了一个关键问题：漏洞利用为何失败？

调查失败

我怀疑该应用程序可能正在执行服务器端验证，而不是仅仅依赖于客户端验证。这或许可以解释为什么在没有 CSRF 令牌的情况下漏洞利用仍然失败。我推测服务器可能通过以下方式之一验证请求：

1. 引荐来源标头验证：服务器可以检查Referer标头以确保请求来自受信任的域。

2. 来源标头验证：服务器可以验证Origin标头以确认请求的来源。

3. 隐藏参数验证：请求中可能有一个用于验证的隐藏参数。

排除通过Referer或标头进行验证后，我将注意力集中在隐藏参数Origin的可能性上。

识别隐藏参数

为了证实我的怀疑，我使用Burp Suite中的Param Miner扩展来强制隐藏参数，特别是那些可以用于 CSRF 保护的参数。

发现隐藏参数

一段时间后，我发现了一个名为 的隐藏参数**C-token**。此参数在初始请求中不可见，但似乎是服务器用于验证的泄露令牌。为了获取其值，我搜索了 Burp Suite 的历史记录，找到了 泄露的实例C-token。

制定新的 PoC

使用该C-token参数，我创建了一个新的 PoC，并将此令牌包含在请求中。更新后的请求如下所示：

POST /change_phone HTTP/1.1  主机：example.com   Cookie：session_cookie=YOUR_SESSION_COOKIE   number=011.xxxxxx&C-token=My.token.xxxxxx

测试更新后的 PoC 成功利用了该漏洞，让我能够更改我的电话号码。

将漏洞传递给受害者

不幸的是，当目标用户使用时，该漏洞仍然没有按预期发挥作用。经过进一步调查，我发现服务器的验证机制存在缺陷C-token。

服务器维护着一个固定令牌数组，并检查请求中的令牌是否与这些令牌中的任何一个匹配。然而，服务器允许同一个令牌在多个请求中重复使用，但不能在连续的请求中重复使用。这就造成了一个漏洞。

C-tokens我在 Burp Suite 的历史记录中发现了多个泄露的令牌（例如token1，，，token2）token3。为了绕过服务器的验证，我按照以下顺序交替使用了令牌：

1. 第一个请求：使用token1。

2. 第二个请求：使用token2。

3. 第三个请求：恢复token1。

这种方法使我能够绕过服务器的令牌验证并成功利用该漏洞。

如何防止CSRF攻击

为了保护您的应用程序免受 CSRF 攻击，请实施以下安全措施：

1. 为每个请求使用唯一的随机令牌

2. 验证来源和引用标头

3. 使用 SameSite Cookies

4. 实施双重提交 Cookies

5. 强制用户重新输入密码或对关键操作使用多重身份验证 (MFA)。

结论

此漏洞凸显了强大的服务器端验证的重要性，以及依赖隐藏参数来确保安全性的风险。通过了解应用程序如何验证请求，我能够利用 CSRF 漏洞并实现帐户接管。

原文始发于微信公众号（红云谈安全）：从隐藏参数到账户接管