文章总结： 本文记录了一次针对Web应用更改电话号码功能的渗透测试。发现表单缺少CSRF令牌后，利用ParamMiner挖掘出隐藏参数C-token。尽管服务器验证该令牌，但存在允许非连续重复使用固定令牌的逻辑漏洞。作者通过交替使用多个泄露令牌绕过验证，成功修改电话号码实现账户接管。文章强调了服务器端验证的重要性，并建议使用随机令牌和SameSiteCookie进行防御。 综合评分： 88 文章分类： 渗透测试,漏洞分析,WEB安全,漏洞POC

从隐藏参数到账户接管

迪哥讲事

2025年12月25日 09:01 江苏

以下文章来源于红云谈安全 ，作者红云谈安全

红云谈安全 .

把网络安全讲好、把技术搞好，持此之剑，破长空！

免责声明

由于传播、利用本公众号红云谈安全所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号红云谈安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！请在授权的站点测试，遵守网络安全法！仅供学习使用，如若非法他用，与平台和本文作者无关，需自行负责！

故事开始

在分析一个 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 漏洞并实现帐户接管。

如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新，绝非简单搬运，包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款

往期回顾

#

如何利用ai辅助挖漏洞

#

如何在移动端抓包-下

#

如何绕过签名校验

#

一款bp神器

挖掘有回显ssrf的隐藏payload

ssrf绕过新思路

一个辅助测试ssrf的工具

dom-xss精选文章

年度精选文章

Nuclei权威指南-如何躺赚

漏洞赏金猎人系列-如何测试设置功能IV

漏洞赏金猎人系列-如何测试注册功能以及相关Tips‍

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：迪哥讲事 《从隐藏参数到账户接管》