关于私有程序信息泄露漏洞的阐述。
谷歌黑客语法：
inurl:responsible disclosure使用上面这个语法搜索，让我获得了一个私有程序的列表。
子域名挖掘
为了开始我的安全测试，我首先使用Subfinder来识别与目标域关联的任何子域名。
我使用了各种其他工具，包括 GitHub 扫描和证书扫描，以尽可能多地收集有关目标网络环境的信息。
最后，我使用自己的字典对目标进行静态和动态暴力破解，这让我总共发现了 42 个子域名。
一旦我对目标的网络环境有了更好的了解，我便开始探索该网站的主要功能点。
在浏览该网站时，我发现了一个注册按钮，它指向一个用户面板，用户可以在其中创建一个帐户并输入他们的个人信息，包括他们的姓名、电子邮件、电话号码和个人资料详细信息。
第一种情况
我尝试的第一个场景是在没有验证的字段上尝试XSS payload，例如名称字段。我尝试了几次，但不幸的是，这种情况没有产生任何结果。
这是我试图弹出警报的payload。
第二种情况
接下来，我尝试上传一个 shell而不是个人资料图片。为此，我创建了一个PHP 文件并echo 1在其中写入。然后我尝试用content-type: image/png. 我注意到一件有趣的事——文件上传成功。我很快找到了照片的路径，并在终端中使用 curl 检查我的文件中的代码是否被执行。不幸的是，我发现代码并没有被执行，这让我感到很失望。
我尝试了各种策略来通过更改内容类型来上传我的文件，但唯一支持的内容类型是“图像”。我什至尝试将文件扩展名更改为“phar”或“php5”，但这些尝试也失败了。
第三种情况
启动架构允许用户为他们的账户定义一个或多个公司并输入他们的信息，使他们能够通过启动想法来操作它们。每个用户都分配了一个 ID，表示为u_wdobhREkbf。同样，每个公司也有一个ID，是c_z8zI6a4unp。ID 之间的唯一区别是用户 ID 以“u”开头，而公司 ID 以“c”开头。这种区别在初创公司架构的背景下是有意义的。
我尝试的第三个场景是IDOR（不安全的直接对象引用）。在公司工作期间，我没有注意数据库中对象之间的关系，也忘记了包括检查从对象中检索的引用是否与用户相关的验证。为了测试漏洞，我创建了另一个账户并填写了公司信息以获取公司ID。
接下来，在以我以前的用户身份登录时，我编辑了我的个人资料，并将公司 ID 替换为我之前创建的公司的 ID。令我惊讶的是，我收到了一个包含 SQL 查询错误的响应 API。我注意到在尝试使用重复的电子邮件创建另一个帐户时会触发类似的 API。
虽然我尝试的第三种方案最终失败了，但它给了我很大的动力。API 返回了一个 SQL 查询错误，这让我感到震惊，这在正常情况下是不会发生的。
我最初对尝试SQL 注入方法很感兴趣，但我很快发现这家初创公司已经为其所有领域实施了准备好的语句，使其免受 SQL 注入攻击。
最后一种情况
由于站点上有两个用户，我决定使用一个返回用户信息的端点来测试站点的访问控制，以查看一个用户是否可以访问另一个用户的信息。我获取了另一个用户的 ID 并输入了它，急切地想看看会发生什么。
我的发现令人惊讶。
访问用户信息端点后/main/api/v1/users/<userId>，我震惊地发现用户的照片、电话号码、签名图片、地址等敏感信息被泄露。然而，这一发现被一个重要的错误所掩盖。
每个用户 ID 都有一个前缀，用字母“u”表示，后跟随机生成的 10 个字符的字符串。我意识到这些字符的所有可能组合的数量是惊人的——26 个小写字母、26 个大写字母和 10 个数字，每个位置有 62 种可能的选择。这意味着可能的状态总数达到惊人的 839,299,365,868,340,224——这个数字对于超级计算机来说也太大了。
尽管通过此端点泄露了敏感信息，但可能的用户 ID 的庞大规模使得任何人都很难利用此漏洞。
所以在我到达这个终点之前没有披露。/main/companies/search/findByNameIgnoreCaseContaining?q=<searchParam>&limit=20
该网站的一项功能允许用户根据公司名称搜索公司。搜索后，将返回包含搜索词的最多 20 家公司的列表。然而，仔细检查后，我注意到创建每个公司的人的用户 ID 也包含在搜索结果中。这带来了重大的安全风险，我决定进一步挖掘。
为了利用此漏洞，我设计开发了一种算法，该算法涉及创建一个包含所有可能的单字母、双字母和三字母英语单词组合的列表。
我使用 API 搜索每个组合并检索相应的公司名称和用户 ID。接下来，我调用了提供用户数据的API，传入了上一步获取的用户ID。然后我将数据保存在一个 JSON 文件中。
由于此漏洞利用需要大量的 API 调用，我使用 Python 实现了该算法，并利用多线程来加快执行时间。
