原文：
https://n0ur5sec.medium.com/somebody-call-the-plumber-graphql-is-leaking-again-654bf1a38d26
（有删减）
大家好，我今天有一个故事要告诉您。我最近通过BugCrowd平台托管的项目挖到了一个GraphQL漏洞。该项目不允许公开，因此我可能需要在不违反“规则”的情况下进行分享。
为了使每个人都能快速上手…GraphQL是一项允许通过API交互进行数据库查询和操作的技术。它是由Facebook开发的，一直在内部使用直到2015年向公众发布。如今，GraphQL在大型公司中使用的情况是非常普遍的。
如今，我并没有很多时间专门用于漏洞赏金计划，我是一个pentester /威胁猎人。我是爸爸，丈夫，游戏玩家，DIY爱好者……说实话很难在这些里保持平衡。因此，当我尝试花一些时间在赏金上时，会显得很生疏。这意味着我只是在尝试查找Web应用程序中可能没有被广泛研究的部分。或以今天的示例为例，根本不应该让公众访问的部分…
浏览目标的主域”.com”时，我在Burpsuite“目标”选项卡中查看并注意到“ / api”接口及其子接口。其中大多数是在浏览和浏览网站上“正常”功能时被被动发现的。我还发现了其中几个，同时进行了目录暴力破解，以发现尽可能多的API接口。
这些不同的子API接口中的每一个在很大程度上都限制了我们可以通过要求身份验证获得的数据。
其他人则向我们提供了仅用于传播网站界面的数据（例如头像，侧栏徽标等）。 换句话说，对于我来说，作为漏洞搜寻者没有什么用。 至少在漏洞方面。
但是，我确实注意到这些接口中的大多数都利用了GraphQL查询...
如果我了解到GraphQL的一件事，那就是一开始很少正确设置。
许多公司都有不安全的GraphQL接口在周围徘徊，并在Bug Bounty报告中大声疾呼。
考虑到GraphQL旨在桥接的现有技术之上的复杂性，这是可以理解的。 但是，一旦我注意到了这一点，便开始着手进行GraphQL测试。 我已经在其他两个公共程序和私有程序中测试了GraphQL接口，但从没有发现任何东西，但是如前所述，我阅读了足够多的错误报告，知道这只是时间问题！
可以帮助您保持动力的一种方法是，HackerOne向赏金猎人支付了20,000美元，后者发现一堆敏感数据从其GraphQL实例中泄漏。
我了解到GraphQL的一件事，就是一开始有很多错误配置。
许多公司都有不安全的GraphQL配置，在Bug Bounty报告中有很多。
考虑到GraphQL旨在桥接的现有技术之上的复杂性，这是可以理解的。 但是，一旦我注意到了这一点，便开始着手进行GraphQL测试。 我已经在其他两个公开项目和私有项目中测试了GraphQL，但从没有发现任何东西，但是如前所述，我阅读了足够多的错误报告，知道这只是时间问题！HackerOne向赏金猎人支付了20,000美元，后者发现一堆敏感数据从其GraphQL实例中泄漏（https://hackerone.com/reports/489146）。
我的第一步通常是尝试对接口运行内省查询。 如果成功； GraphQL中的内省查询将为您提供有关“模式” /数据配置的大量信息。 诸如什么样的信息存在，所有的信息如何连接，其接受的格式，如何查询数据以及如何处理数据之类的事情。
几乎您将阅读的有关测试GraphQL实例的每篇文章都会告诉您寻找以下接口：
- /graphql
- /graphiql
- /graphql.php
- /graphql/console
并且，如果您在BurpSuite中使用GraphQL“InQL Scanner” BApp插件，您要做的就是要将自省查询发送到的URL。但是，我认为重要的是要认识到，仅仅因为上面列出的那些接口表明GraphQL的存在，并不意味着应该将其视为包含所有接口的清单，以便在您怀疑目标正在运行实例时针对该清单进行自省查询。例如，…您确实可以在上面的屏幕快照中看到一些/ graphql接口…但是，运行Introspecition查询时，我实际上得到的接口详细信息根本没有标记为“ graphql”！
我不想/不能说出真正的接口名称来使机密性与目标保持一致，但是我们将其称为“ / api / vulnerable”……只要知道graphql不是接口的名称。
因此，我将https：// [redacted] .com / api /vulnerable发送到Burpsuite的InQLScanner，并发现此接口支持的查询，可能会出现大量有趣的数据查询。
我迅速将一个名为“ customer.query”的查询发送到“Repeater”选项卡，并在猜测的“ ID”参数中仅猜测为“1”，以查看是否有任何用户数据返回，但基本上我得到一个错误，提示说 ID格式不被接受。
我还看到了SQL语句的一部分，并且正在使用“ Psycopg2”。 这告诉我他们正在使用Python和PostgresSQL。
由返回结果我们知道它使用的uuid，我开始寻找一个UUID…可能太复杂了以至于无法找到。因此，我查看了我运行的初始自省查询中可用的其他可能查询，并且看到了“ customers.query”（请注意，customers.query是复数）。我为什么不从那开始呢！
哈哈...我运行了该查询，它只需要两个参数...每页的结果数...以及要查询的页面...。 那有多容易？ 我不必猜测任何内容，而且希望查询在不进行身份验证的情况下运行…
好吧，我当然没有“黑”任何东西。但是我确实找到了很多我不应该看到的敏感信息！下一步就是探索我能够使用的其他查询。在与平台相关的各种合作伙伴和用户上还有一些其他方式的敏感信息（类似于承包商）。我还找到了一些API密钥以及外部webhook URL，但是这些URL超出范围，因此，除了在BugCrowd的报告中提及它们之外，没其他用。
我整理了数据，试图最大程度地提高影响力，然后发布了报告。在选择类别时，我相信此漏洞将适用于我，我注意到，由于它会导致“敏感机密”泄漏，因此很可能将其视为“ P1”严重性。然后，我查看了P1上的计划支出，并很快意识到，如果一切顺利，我可以得到不错的收入。
译者按：
作者在一个私有项目发现了Graphql接口，并且通过发现一些参数，来进行数据库查询，最终获取了敏感信息泄露。事实上暴漏出来的Graphql有很多，火器上就可以搜到一些。
如果厂商没有限制的话，我们可以使用内省查询，来查询有哪些可用类型。然后进一步获取敏感数据。当然还有其他搜索姿势，比如GraphQL Playground是一款专门为数据查询语言GraphQL设计的免费开源的IDE。有很多项目使用这个组件。有兴趣的小伙伴可以研究一下。
本文迁移自知识星球“火线Zone”
