-这不是我上一篇的系列文章。这只是一部分。 -
这篇简单的文章将涵盖在一个目标上编写的一些基本漏洞，例如：
•通过Google Dork进行信息披露
•简单的注册激活旁路
•简单的IDOR；和
•将CSRF升级到中等严重性（从POST到GET方法）作为一项信息，可以肯定的是，这个简单的文章并没有谈论很多新事物。它只是使用了一些基本的技术，对于大多数的bug搜寻者/研究人员而言，这些技术都是可能会忘记的
I摘要
在讨论技术细节之前，我想读者应该知道为什么我在一个私人漏洞赏金计划中选择这个目标的主要原因（并希望它可能对另一个有用）
2017年底，我受邀参加了一个私人漏洞赏金计划之一。当我看到“ 报告的问题” 总数已达到近1000个，范围有限时- 主域和子域很少，而博客则很少 -那么我真的失去了参与的兴趣。（是的，这与我在另一篇文章中的说法类似）。
但是，在2018年初的一天，我尝试重新参加该计划。我试图仔细检查范围，并仔细考虑可能易受攻击的目标。简而言之，我选择其中一个子域（当然不是博客），然后尝试从Google Dork中获取一些信息。几分钟后，我得到了与目标有关的URL模式，并尝试将其与另一个对象一起使用。最后，我可以枚举约50笔交易，而无需有效的用户名和密码
我向程序报告了该问题，并获得了100美元。是的，这是正常现象，因为可以枚举的交易次数只有50左右
然后，在2019年，我再次参加该计划（请不要问为什么）。然后，我看到“已报告的问题” 的数量并没有显着增加，也许是大约20或30个报告。然后，我说：“为什么我们不尝试一下，而是更加专注于特定目标”
因此，我去了同一个目标，试图找到一种绕过注册激活的方法。最终，我发现了4个目标，使我获得了数千美元。然后，越来越多的东西（我和我的一个朋友Tomi进行了合作），最后，Alhamdulillah-在阿拉的允许下，在1.5个月内从一个目标获得了大约20,000美元（他得到了超过10,000美元）。
II 简短的摘要
2.1 关于这篇文章的几句话
作为一项信息，可以肯定的是，这个简单的文章并没有谈论很多新事物。它只是使用了一些基本的技术，对于大多数的bug搜寻者/研究人员而言，这些技术都是可能会忘记的。
从注册激活旁路开始，进行一些“ 正式注册 ”以获取正式访问权，然后最终产生大量IDOR问题，这些问题导致诸如阻止帐户，访问交易报告，生成交易报告等许多事情。 （包括存储的XSS，将CSRF从POST升级到GET方法等问题）。
2.2 简单总结
2.2.1
在2018年前，我在Google上查看目标信息时使用的关键字是：github.com subdomain.targetname.com。从结果来看，终于在第一页找到了一个模式，如下所示：
subdomain.targetname.com/Detail?trNum=${TRANSACTION_NUMBER}&e=${EMAIL}.我接下来要做的是使用一个简单的Google Dork，希望可以列举一些东西，例如：
site:subdomain.targetname.com AND inurl:trNum=然后我将trnum=改为trnum、e=和e。它可以给出各种各样的结果，并且足以枚举大约50个事务。
报告了问题，并进行了分类并悬赏100美元。
注意，trNum包含大约10个唯一数字。如果trNum与电子邮件没有任何关系，则无法打开交易报告。
2.2.2
在2019年，我尝试使用普通的免费电子邮件注册自己的帐户。然后，该应用程序显示是否需要等待批准的信息，此后，我将获得密码。它仍然显示出我在2018年前面对的同一件事。
在这种情况下，我的心转为使用重设密码功能，而且令人惊讶的是，我得到了一个唯一的URL来重设自己的密码（该帐户仍没有密码并且尚未激活）。我单击了URL，然后重定向到了可用于输入密码的提示。接下来，我输入了密码，无需任何批准即可使用该帐户登录
已对该问题进行了另一篇报告的分类并对此进行了奖励。原因是我无法在这种级别的责任感下执行许多事情。好吧，有趣。从这个答复中，我最终知道该应用程序是否正在被许多人积极使用，因此我应该进行更深入的研究。
2.2.3
由于我可以登录并且可以访问自己的个人资料，因此我尝试更新自己的帐户并尝试查看应用程序发送的参数（作为简单描述，其中两个是“唯一ID”和“电子邮件” ID”）。从这里，然后将我的电子邮件地址更改为我也注册的另一个电子邮件地址，希望可以发现帐户接收问题。（是的，也可以尝试参数污染）。
很遗憾，我没有找到帐户接管人。但是好消息是，通过这种方式，我发现了可能永久阻止另一个帐户的问题。由于一个具有两个电子邮件ID的唯一ID发生冲突，因此如果不直接在管理员仪表板或数据库中更改电子邮件，则无法再使用这两个电子邮件进行登录。我报告了该问题，然后对其进行了分类并再次得到了奖励
2.2.4
我回到2018年的报告中，发现问题是否已解决。在这种情况下，我尝试使用相同的技术重现相同的问题。然后，我发现使用此技术是否无法再次查看交易报告，也就是说，用户需要有效的会话才能访问报告
但好消息是，我仍然可以在email参数中看到该值。因此，再次，我通过使用同一问题找到了50个不同的电子邮件地址（类似于上一个，但目前只是一个电子邮件地址）。
试图再次报道，并得到了分类和奖励
2.2.5
考虑到我已经在有限的帐户访问权限中完成了我所知道的大部分操作，然后尝试再次注册该帐户。所不同的是，我尝试放入自己的公司电子邮件（我工作的公司）。
老实说，在一个领域中，有一个像唯一编号这样的东西，很可能与有效客户已收到的交易代码有关。
因此，基本上，我尝试找出唯一编号的模型，而且我不知道，因为没有人将其公开（搜索引擎没有给出好的结果，或者至少，我不知道如何优化关键字） 。
好吧，希望我的帐户获得批准，然后，我用一个随机数继续注册。
为什么我真的想内部访问该站点？因为我敢肯定还没有Bug猎人接触过此站点。请亲切看看我为什么要在此程序中进行“重试”（我的原因）（该报告在一年左右的时间里仅增加了20到30份报告-完全不同，其结果是几年前可以达到150到250份）报告）。另一个原因是因为我在此门户网站上找到了有效的“注册激活旁路”和“阻止帐户”问题。
令人惊讶的是，在提交注册后3天，我收到一封电子邮件，显示我的帐户是否已被批准并可以登录。我从发送的唯一URL设置密码，然后直接登录门户。当我在应用程序内部看到如此多的菜单时，我感到非常高兴
那时，我对一个菜单进行了简单的测试，该菜单可用于访问自己的事务（这是我从未做过的事情）。简而言之，通常情况下，当我们请求此类数据时，应用程序会向服务器发送事务ID参数（标头和POST数据中没有任何令牌）。
希望有一个IDOR，然后我将那些交易ID号更改为随机的。终于，我得到了想要的东西。通过使用此技巧，我无需用户名和密码即可访问许多客户数据。
我报告了这个问题，然后对其进行了分类和奖励
接下来，我与朋友合作，在此门户网站上发现了很多问题，这些问题总价值超过20,000美元。
所以，这是总结的结尾。在下一节中，我将尝试通过其他一些问题来解释技术细节，例如将CSRF从低严重性升级到中等严重性（注意，已存储的XSS内容已在Tomi的Medium中发布）。
III 技术说明
3.1通过Google Dork进行简单信息披露
由于访问的限制（例如，我们只能面对登录表单），并且如果我们在应用程序中没有发现任何缺陷，那么我们可以做的是：
- 尝试对目录进行爬网（我们可以使用很多工具，但是我个人使用dirsearch来帮助我）
- 通过搜索引擎（很多资源，其中之一是GitHub）寻找与应用程序相关的信息（例如找到在URL中执行的流程）。
- 也许还有更多。
3.1.1关于使用搜索引擎查找可能的“泄漏”的几句话
从我们的其他文章中引用（在PayPal进行简单的信息披露大约需要1,000美元）：
我们不能否认，对于网站上拥有如此众多内容的每个人来说，最大的梦想之一就是被世界顶级搜索引擎收录。实际上，我们应该意识到，即使搜索引擎可以帮助我们向公众“推广”我们的内容，如果这些站点所有者没有正确设置阻止规则，搜索引擎本身也可以“背叛”该站点所有者以泄漏信息。
阿泰克·汗（Ateeq Khan）进行的研究充分证明了这种想法。在2013年11月，他通过使用搜索引擎的主要功能，展示了Microsoft Yammer产品中存在的有趣漏洞（关键信息泄露）。由于搜索引擎已“意外”索引了令牌的“泄漏”，当时的攻击者可以使用这些信息登录相关帐户。
3.1.2
从这些心态出发，我们开始研究搜索引擎。我们在Google使用的关键字之一是：“ github.com subdomain.targetname.com ”。通过此活动，我们在第一页上找到了一个github页面，其中包含以下模式：
subdomain.targetname.com/Detail?trNum=${TRANSACTION_NUMBER}&e=${EMAIL}.
如前所述，我们接下来要做的是使用一个简单的Google Dork，希望可以枚举某些内容，因为他们尚未设置僵尸防护功能，例如：
- site:subdomain.targetname.com AND inurl:trNum=
- site:subdomain.targetname.com AND inurl:e=
- site:subdomain.targetname.com AND inurl:trNum
- site:subdomain.targetname.com AND inurl:e如我们所见，其中两个使用“ =”，而两个不使用。我们不知道为什么，但是以某种方式可以得出不同的结果。
此时，我们可以看到URL，可以看到交易（在2018年），仍然可以看到电子邮件的值（在2019年）。
3.1.3
好吧，我们无法从技术上进行解释。但是从我们从其他程序所有者那里学到的信息来看，通常是因为应用程序未设置noindex元标记而发生的。
因此，为了防止搜索引擎将这种类型的请求编入索引，开发人员应在页面中使用noindex元标记。谷歌在其文档中已经告诉另一种防止搜索引擎索引这种方法的方法
在他们的一篇文章中，HubSpot还讲述了两种有效的方法来防止搜索引擎对我们的敏感内容或无用内容进行索引
3.2通过使用重置密码功能进行简单的注册激活绕过
对于我们来说，与此应用程序相关的幸运之处在于，即使我们仍需要批准，我们也可以注册自己。
请注意，因为这也是一种简单的方法，所以我们将不描述此活动发送的参数。
基本上，我们只是在注册表中填写内容。我们填写姓名，公司名称，电子邮件地址和所有需要的数据。提交请求后，如果需要等待批准，我们就会获得信息。
在等待批准的过程中，我们确定我的帐户是否会获得批准（因为我们使用了来自免费电子邮件地址服务的帐户），因此我们尝试了重置密码功能。
令人惊讶的是，该应用程序向我们发送了可用于设置密码的URL。
您可以单击下面的链接来设置密码：
http://subdomain.target.com/account/password?id=hash_here&another_unique_id=hash_here
如果您有任何疑问或问题，请不要回复此电子邮件。第一次，即使我们使用这些URL并输入密码，也不确定该帐户是否处于活动状态。但是，当我们尝试登录时，我们终于可以访问门户了。
3.3具有永久阻止其他帐户能力的IDOR
进入门户网站后，我们唯一可以访问的菜单就是我们自己的个人资料。在这种情况下，我们只需更新我们的常用信息（例如名字和姓氏，公司名称，职位等等）。可以看出，电子邮件是我们无法更改的参数。
通过查看这种情况，然后我们尝试进行帐户接管方案。简而言之，当我们将更新提交给服务器时，应用程序将发送带有多个参数的请求，例如：
POST /account/user/update
Host: subdomain.target.com
.
.
.
lang=en&id=hash_here&email=email_here&____and more____即使他们在POST参数中添加了唯一的哈希，但我们仍然尝试将电子邮件地址更改为另一个。
详细信息是，我们将“电子邮件”参数值从第一个帐户更改为我们也以相同方式创建的第二个帐户。
Original: lang=en&id=hash_here&email=1stemail&____and more____
Modify: lang=en&id=hash_here&email=2ndemail&____and more____但是，正如预期的那样，没有发生帐户接管，因为我们无法使用为第一个帐户设置的密码登录。
然后，我们尝试使用有效密码登录第二个帐户。结果是，我们无法登录。第一次，我们认为我们忘记了第二个帐户的密码。但是，在重置密码并输入新密码后，我们仍然无法登录。
根据此分析，我们假设先前的活动是否阻止了该第二个帐户的访问。为了使我们的假设正确无误，然后我们用第三和第四帐户再次重现该问题。结果就是成功。我们可以阻止其他帐户（此执行也阻止了我们的帐户）。
3.3.1为什么会发生-第一个障碍？
好吧，我们简单地认为，因为他们数据库中的必需参数是那些包含唯一哈希的ID参数。因此，当一个唯一ID具有两个相同的电子邮件值时，应用程序将无法确定哪个是正确的。然后，应用程序“决定”同时阻止这两个帐户。
3.4.1 尝试注册有效的公司帐户
虽然我们对使用该级别的帐户（受限的访问权限）可以完成的事情一窍不通，但我们开始使用公司电子邮件注册新帐户。
如前所述，在注册过程中需要填写一种交易编号。如果该用户可以通过在另一个门户网站上进行有效交易来获取此号码，则可能性很大。这是我们从此应用程序中学到的示例流程：
由于我们不知道这些唯一数字的外观，因此我们开始插入随机数字，希望我们的请求获得批准。
提交请求3天后，突然我们收到一封非常不错的电子邮件：
您的帐号已经建立。
单击以下超链接激活并登录到您的帐户：
http : //subdomain.target.com/account/password?id=hash_here&another_unique_id=hash_here
登录后，请尽快设置密码。
单击这些URL并输入密码后，我们尝试登录，最后我们可以看到很多可以测试的菜单。
3.4.2 IDOR执行—查看其他交易数据
登录该站点后，然后我们开始测试一个菜单，该菜单正在查找交易数据。
当我们在此菜单上访问该功能时，应用程序将发送如下请求：
POST /transaction/report/list
Host: subdomain.target.com
.
.
.
transactionid=31337&page=1&sort=asc&size=15是的，您的假设是正确的。我们只需要将transactionid参数更改为另一个值，就可以访问其他客户交易。没有包含令牌的自定义标头，在POST数据中没有令牌，因此，它可以完美运行。
从这里开始，然后我们尝试找出另一个类似的问题，并且在此门户网站上发现了大约15个IDOR问题（赏金范围从600到1,250美元）。
3.5 CSRF问题从低严重升级为中等
可以肯定的是，对于主动寻找漏洞的许多bug猎人/研究人员来说，这也不是一个新事物。但是，为了完成对导致第四个漏洞的前四个漏洞的解释，我们认为值得分享。
3.5.1 关于CSRF的一些话
通常，CSRF是一种攻击，它通过利用被授权（登录）的受害者的情况，“迫使”用户执行基于Web的应用程序中基本上“不需要的”操作。通常，可以使用这种攻击，因为在进行更改时缺少身份验证过程，或者缺少允许处理相关事件的唯一令牌（通常会给出令牌的唯一性，因此用户不会麻烦输入密码以进行不太重要的更改）。
3.5.2
因此，就像普通的应用程序一样，此目标也具有删除，共享和其他功能（是的，我们还在此功能上测试了IDOR）。
例如，当我们想要删除或共享某些内容时，应用程序将发送如下请求：
POST /transaction/report/delete
Host: subdomain.target.com
.
.
.
numberID=31337它也与共享功能相似。区别在于，POST数据处有一个电子邮件地址，端点处的“删除”路径已更改为“共享”。
可以看出，这不是一件好事（至少对我们而言），因为此功能是在POST方法中执行的。原因是因为我们还不知道如何通过POST方法执行多次操作来执行CSRF（寻找一些资源，并且它不起作用）。
在这种情况下，我们尝试将HTTP方法从POST更改为GET。（使用Burpsuite的“ 更改请求方法 ”功能可以更轻松地进行更改）。
因此，对于“删除”功能应该是这样的：
http://subdomain.target.com/transaction/report/delete?numberId=31337令人惊讶的是，它有效（而其他功能不适用于此功能）。然后，我们直接创建一个简单的PoC，以一次执行多个删除操作。
例如，我们希望将numberID从31337删除为31348，然后只需将URL嵌入到无边框图像标签中即可（没有高度和宽度）。这是我们使用的示例HTML脚本：
<html>
<body>
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31337" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31338" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31339" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31340" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31341" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31342" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31343" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31344" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31345" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31346" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31347" width=”0" height=”0" border=”0">
<img src=”https://subdomain.target.com/transaction/report/delete?numberId=31348" width=”0" height=”0" border=”0">
</body>
</html>
受害者在其浏览器上打开脚本后（尽管他们仍通过身份验证），然后所有这些信息将被删除。
报告此问题时，程序所有者已将严重性从低更改为中。
IV 收盘
好吧，正如读者看到的那样，也许这不是一个很好的文章。同样，没有太多新的技术细节可以学习。但是我们仍会发布此文章，因为我们确定是否可以从这个故事中学到很多东西。好东西很少是
- 注册完成后，即使没有访问权限，也请务必尝试重置自己的密码；
- 始终尝试使用您的公司电子邮件帐户。应用程序的所有者以某种方式认为这些注册是有效的注册，并且可以提供有利可图的东西（从业务角度而言）；
- 始终尝试记住在某个计划中获得了多少报告（查看他们在公共程序中获得的HoF也很有用）。对于我们来说，了解漏洞搜寻者/研究人员对那些程序的兴趣以及我们如何在这些目标上利用新技术可能会很有用。我记得当Andy Gill发布在Oracle EBS平台上执行Illegal Rendered的文章时（CVE-2017–3528）。他刚刚在2018年发布了该问题，我们开始使用HoF很少的公共漏洞赏金计划，并使用简单的Google Dork（网站：*。target.com和inurl：/ OA_HTML /）查找目标。在几个小时内，我们从2个程序中获得了450美元。
仅供参考，就我个人而言，我不同意这些CVE-2017–3528是否被称为开放重定向。从PortSwigger的解释中，很可能是“带外资源负载”
- 始终返回到您的旧报告，并尝试在所有者说解决该问题时重现相同的内容。在另一种情况下，我曾经在一个私有程序中的二手Jira上的Reflected XSS上报道过。对问题进行了分类，并在几个月后解决。在获得有关该问题是否已解决的信息后，我再次转到相同的目标，并使用Jira将我重定向到另一个子域。不同之处在于，当他们将数据从旧吉拉迁移到新吉拉时，他们忘记了使用身份验证来访问每张票证。结果是，我可以看到很多机密票据（包括工作凭证），这使我得到了另一个分类报告。
- 也许还有更多我们尚不了解的事情。
