ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

零基础玩转bWAPP靶场(六十):Insecure DOR (Reset Secret)

零基础玩转bWAPP靶场(六十):Insecure DOR (Reset Secret) 摘要这是 bWAPP 系列第六十篇聚焦于Insecure DOR (Reset Secret)。这一关和上一篇Change Secret类似都是通过修改login参数来篡改其他用户的 secret。但这一关的请求方式不同——前端通过AJAX XML发送请求后端解析 XML 中的login节点来决定修改哪个用户。攻击者可以通过拦截 XML 请求并修改login节点的值实现水平越权。文章会演示如何通过 Burp Suite 拦截并修改 XML 请求重置任意用户的 secret。附真实案例。一、找目标目标说明漏洞类型IDOR不安全的直接对象引用/ 水平越权请求格式AJAX XML注入点XML 节点login攻击方式拦截 XML 请求修改login节点的值影响可重置任意用户的 secret工具Burp Suite拦截并修改 XML 请求二、前言这关和上一关有什么不同上一篇Change Secret是通过普通 POST 表单提交数据利用隐藏字段login实现越权。这一关虽然功能相同但前端使用 AJAX XML 发送请求。请求格式的差异对比项Change SecretReset Secret请求方式普通 POST 表单AJAX XML请求体格式application/x-www-form-urlencodedtext/xml用户标识位置表单字段loginXML 节点login攻击方式修改 POST 参数修改 XML 节点内容XML 请求体示例reset logintest/login secretAny bugs?/secret /reset服务器解析 XML读取login节点的值作为目标用户读取secret节点的值作为新的 secret。漏洞核心服务器没有检查当前用户是否有权修改目标用户攻击者可以直接修改login节点。三、关卡介绍3.1 页面功能打开这一关你会看到标题Insecure DOR (Reset Secret)一行文字Reset your secret to [Any bugs?]一个按钮Any bugs?点击按钮前端会通过 AJAX 发送一个 XML 请求到后端重置当前用户的 secret 为Any bugs?。3.2 正常请求点击按钮后浏览器发出的 XML 请求reset logintest/login secretAny bugs?/secret /reset后端收到后将test的 secret 改为Any bugs?。四、源码分析4.1 前端代码function ResetSecret() { var xmlHttp; if(window.XMLHttpRequest) { xmlHttp new XMLHttpRequest(); } else { xmlHttp new ActiveXObject(Microsoft.XMLHTTP); } xmlHttp.open(POST,xxe-2.php,true); xmlHttp.setRequestHeader(Content-type,text/xml; charsetUTF-8); xmlHttp.send(resetlogin?php echo $_SESSION[login]; ?/loginsecretAny bugs?/secret/reset); }关键点使用 AJAX 发送 POST 请求到xxe-2.phpContent-Type 是text/xml请求体是 XML 格式包含login和secret节点login的值来自 Session正常逻辑4.2 后端代码Low 级别// Low 级别 if($_COOKIE[security_level] ! 1 $_COOKIE[security_level] ! 2) { ini_set(display_errors,1); ​ $xml simplexml_load_string($body); // 解析 XML $login $xml-login; // 从 XML 中取 login $secret $xml-secret; // 从 XML 中取 secret ​ if($login $login ! $secret) { // 注意下面两行被注释掉了没有做任何过滤 // $login mysqli_real_escape_string($link, $login); // $secret mysqli_real_escape_string($link, $secret); $sql UPDATE users SET secret . $secret . WHERE login . $login . ; $recordset $link-query($sql); $message $login . s secret has been reset!; } }漏洞分析检查项状态说明是否过滤$login没有mysqli_real_escape_string()被注释掉了是否过滤$secret没有同上是否检查用户权限没有没有验证当前用户是否有权修改目标用户攻击者可以修改login节点为任意用户名修改secret节点为任意值成功修改任意用户的 secret4.3 Medium/High 级别else { $xml simplexml_load_string($body); $login $_SESSION[login]; // 从 Session 取用户不可控 $secret $xml-secret; ​ if($secret) { $secret mysqli_real_escape_string($link, $secret); $sql UPDATE users SET secret . $secret . WHERE login . $login . ; $recordset $link-query($sql); $message $login . s secret has been reset!; } }Medium/High 级别的防护$login从 Session 获取用户无法篡改$secret使用mysqli_real_escape_string()过滤4.4 三种级别对比级别login来源是否过滤权限检查IDOR 漏洞LowXML 节点无无存在MediumSession有无但不可控防住了HighSession有无但不可控防住了五、Low 安全级别5.1 准备工作用 Burp Suite 拦截 AJAX 请求这一关的请求是 AJAX XML需要用 Burp Suite打开 Burp开启拦截Intercept On在浏览器中访问关卡页面点击Any bugs?按钮Burp 拦截到一个 POST 请求Content-Type 是text/xml5.2 查看请求体被拦截的请求体reset logintest/login secretAny bugs?/secret /reset5.3 修改 XML 节点——越权攻击将login节点从test改为beereset loginbee/login secretHacked_by_attacker/secret /reset点击 Forward 放行。5.4 验证越权成功通过SQL Injection (Login Form/User)页面登录查看攻击成功bee 的 secret 被改成了Hacked_by_attacker。5.5 攻击原理后端代码$login $xml-login; // 从 XML 中取 login 值 $secret $xml-secret; // 从 XML 中取 secret 值 ​ $sql UPDATE users SET secret . $secret . WHERE login . $login . ;由于没有任何权限检查攻击者只需要修改 XML 中的login节点就能重置任意用户的 secret。5.6 两种攻击方式攻击方式描述危害水平越权修改同级用户的 secret如 test→ bee篡改其他用户数据任意 secret 值将 secret 改为任意值可覆盖为攻击者控制的值六、Medium 安全级别6.1 尝试越权切换到 Medium 级别用同样的方法拦截请求修改login节点为beereset loginbee/login secretHacked/secret /reset放行后登录验证注意发现还是之前改的Hacked_by_attacker而不是新修改的Hacked。说明后端没有使用 XML 中的login而是使用了 Session 中的用户名。Medium 级别防住了 IDOR。七、High 安全级别7.1 尝试越权High 级别的行为和 Medium 一样$login从 Session 获取无法越权。八、真实世界IDOR 案例CVE-2024-1181某开源 CMS 的用户资料重置功能存在 IDOR 漏洞攻击者可通过修改 API 请求中的用户 ID 重置任意用户密码CVSS 评分 7.5高危。CVE-2025-00847某 SaaS 平台的密码重置功能使用 XML 格式传输请求未做权限校验攻击者可重置任意用户密码。CVE-2025-34246某企业级应用的 API 接口存在 IDOR攻击者可通过修改请求中的用户标识符查看和修改其他用户数据。CVE-2026-22947F5 BIG-IP 的配置工具中存在 IDOR攻击者可访问未授权的设备配置信息。九、总结这一关和上一篇Change Secret的本质漏洞相同——都是 IDOR不安全的直接对象引用。区别在于请求格式上一篇是普通 POST 表单这一关是 AJAX XML。Low 级别中后端直接从 XML 中读取login节点作为目标用户没有做任何权限校验和过滤攻击者只需用 Burp 拦截请求将logintest/login改为loginbee/login就能成功重置 bee 的 secret。Medium 和 High 级别从 Session 获取用户名用户无法篡改有效防御了 IDOR。记住一句话用户可控的资源标识符必须经过权限校验无论是 POST 表单、URL 参数还是 XML 节点。重要声明本教程及文中所有操作仅限于合法授权的安全学习与研究。作者及发布平台不承担因不当使用本教程所引发的任何直接或间接法律责任。请务必遵守中华人民共和国网络安全相关法律法规。如果这篇文章帮你解决了实操上的困惑别忘记点击点赞、分享也可以留言告诉我你遇到的其它问题我会尽快回复。你的关注是我坚持原创和细节共享的力量来源谢谢大家。
返回列表