那个说谎的邀请：隐藏在LG墙后的业务逻辑漏洞
这次我不是在追赏金。这次的刺激感不同——我想获得LG的感谢信。
不是漏洞赏金，不是技术文章奖杯。只是一个干净、扎实的发现。让他们记住的东西。
因为当你处理像LG这样的品牌时——精致与生产的结合——你知道表面之下还有更多。
所以，我做了我最擅长的事：打开我的侦察工具包，激发直觉，开始寻找逻辑裂缝。
🕵️ 第一步：大规模侦察
我的侦察游戏从我绝对喜爱的武器开始：ShrewdEye。
它像魔术一样提取子域名——原始、可下载、没有UI花哨。
|
|
文件下载完成，随之而来的是数百个子域名——一些休眠，一些可疑，还有几个…活跃到足以危险。
我过滤了列表，只保留返回200 OK响应的目标。
然后我看到了它。
一个我不会在这里命名的子域名（你懂的），但我们称它为： xyz.redacted.lg.com
它不仅活跃。它还在嗡嗡作响——登录流程、邀请系统、看起来像测试版的仪表板，就像其他正常的Web应用一样。
这是真正漏洞隐藏在真正逻辑中的地方。
🔁 感觉太可预测的功能
我直接前往"通过邮件邀请"流程。
乍一看，它很干净。
你发送邀请 → 用户收到邮件 → 他们注册。
又好又无聊。
所以我开始测试速率限制、竞争条件和所有常见的嫌疑点。我甚至猛击请求，只是为了看它是否会崩溃。
没有发生爆炸性的事情。
没有重复邀请。没有疯狂的邀请泛滥。没有基于竞争的特权升级。
老实说？它变得乏味了。
所以我靠后思考：
“让我们做点愚蠢的事。检查系统是否甚至将邀请邮件与注册账户链接起来。”
基本的东西。几乎无聊。但这就是无聊检查的事情——它们经常揭示最荒谬的漏洞。
而这个？它不仅仅是一个漏洞。
它是现实中的一个故障。
🕵️♂️💻 “我没计划找到一个P1…但我的脚本有其他计划 🧠💣”
👁️🗨️ 本不该重要的检查
我向testvictim@gmail.com发送了一个邀请。
邮件来了。我点击了邀请链接。注册页面打开了。
在这一点上，我没有期待太多。只是想看看是否只有在被邀请但未注册的情况下才会创建账户！
（如果你喜欢漏洞狩猎，并且从未问过这个问题，记下来。真的。）
然后我注意到一些奇怪的事情：
邮箱字段没有被锁定。它是可编辑的。
当然那只是前端的事情，对吧？
所以我键入了attacker@gmail.com。键入了密码。点击提交。
然后它…成功了。
系统愉快地为attacker@gmail.com创建了一个账户。
没有警告。没有验证错误。没有我能看到的日志。
但真正的关键在于：
在管理仪表板中，系统说``已接受邀请。
再读一遍。
真正的被邀请用户？没有账户。从未注册。
攻击者？完全访问，全新的账户。
系统？完全不知道有任何问题。
💥 幽灵账户问题
这不仅仅是一个小的验证错误。
它是一个基本的逻辑缺陷。
后端没有将邀请令牌绑定到原始邮箱。它只是接受了任何有链接的人。
更糟的是——它标记了错误的人为已注册。
这意味着：
分析数据被破坏。 推荐日志是假的。 信任假设完全破碎。
看起来邀请被使用了。看起来正确的人注册了。
但没有人知道真正的用户甚至从未碰过它。
如果你是开发人员或安全分析师阅读本文，记下这个漏洞：
🔴 “邀请的邮箱地址在注册过程中可以被修改。账户在不同的邮箱下创建，但原始邀请被错误地标记为已接受。”
🔚 结论：那个说谎的邀请
这不是一个零日漏洞。没有shell，没有脚本注入，没有绕过链。
但它同样危险。
一个可编辑的输入字段——看似无害——让我冒充用户，歪曲业务数据，并暴露整个邀请逻辑为虚假信任。
如果我没有检查那个无聊的细节…如果我跳过了"健全性测试"…
我会错过我今年发现的最干净的业务逻辑漏洞之一。
所以下次一个系统看起来太无聊而不值得费心时？
无论如何费心一下。你永远不知道幕后有什么在静默地崩溃。
直到下次，— 安全研究员
Lordofheaven !😀
业务逻辑漏洞 | 访问控制破坏 | 漏洞赏金 | Web安全