*本文中涉及到的相关漏洞已报送厂商并得到修复，本文仅限技术研究与讨论，严禁用于非法用途，否则产生的一切后果自行承担。
众所周知，漏洞众测并不是一个容易入行并取得成就的领域，顶尖的白帽黑客不仅有沉浸多年的挖洞经验，而且还精通安全技术。现实中，为了鼓励人们发现漏洞，厂商的众测项目目标一般都具备较强的安全措施。很多时候对于我们大多数新手来说，由于测试目标的安全加固非常到位，所以，在参与众测过程中我们经常会遇到瓶颈，即使再怎么努力也无所发现，陷入窘境，如何来破？
一、经验之谈
自今年年初入门漏洞众测以来，不可否认的是，一路走来有挫折有沮丧，甚至有时候还感觉自己像个“水货”。翻翻Twitter和Hacker101等其它漏洞众测论坛发现，很多新手都容易灰心，感觉漏洞很难发现。虽然这种感觉可以理解，但在这里要说的是，有很多被发现的漏洞，其原理非常简单，我们需要的是正确的心态、坚持不懈的毅力和一点点的运气。
挖洞成功的关键和进步很多取决于你的心态和看待事物的方式。刚开始的时候，总想把发现有效漏洞作为衡量成功的标准，无疑会非常容易气馁和疲惫。如果你都不了解不同漏洞的类别，只把所有关注点放到目标应用上，且寄希望有所发现，这并不是行之有效的最好方法，最后也可能学不到什么。这个时候，要学着往后退一步，去建立一些与目标应用相关的基础知识，尽量去熟悉目标应用。
厂商漏洞鉴定者和漏洞上报者都有各自独特的看法。非常显然的是，有些人甚至不了解漏洞原理或是什么都选择上报，以这种“粗鲁”的方式就想去获得漏洞赏金，而且，可能最后连漏洞为什么会被分类为N/A都无从知晓，这对厂商和自己来说都是一种消极的方式。但如果你后退一步，尝试去熟悉厂商实际面临的安全风险，思量上报漏洞的意义，那么也就能理解，为什么有些漏洞刚开始有效，之后却被拒收了。其次，有时候当你发现了一个漏洞，但也并不意味着它需要被修复，因为对厂商来说，在某些特定环境下，修复可能并不会降低一定程度的安全风险。另外，即使你上报的漏洞属于重复报，这值得骄傲，至少证明你发现了一个有效安全漏洞，这个经验过程才是真正的收获。拥有正确的心态，会让挖洞过程变得更加轻松愉快，最终才会取得成功。
二、我的挖洞经验分享
以下是我在过去几个月中轻松发现的一些漏洞，这些漏洞甚至被很多老道的“漏洞赏金猎人”忽视了。正如一些大牛白帽所说的，There are more bugs out there than people to find them（漏洞就在那里，关键是你找或者不找）。每个挖洞者都有各自的挖洞经验，这种独特的视角往往还能发现一些大牛黑客忽视的漏洞。此外，厂商每天都会在代码层面部署变更，虽然目标是“旧的”，但漏洞却可能会日新月异，不断演变。
2.1.越权漏洞#1 （IDOR，危急，赏金$3,000）
该邀请测试的目标应用允许用户根据其中的用户关系创建联系人名单。目标应用作为一个B2B程序，当前用户本身应该只能通过内部组织或其它方式访问到其他用户。创建联系人名单时，您可以手动输入信息，也可以通过以下URL从现有用户关系中创建联系人：
这个非常简单的越权操作，允许攻击者将user_id参数中的值更改为其他任何用户的ID，就可以访问到他们所有的个人身份信息（PII），包括姓名、电子邮件、电话号码、地理位置、个人简历等。由于目标应用有大约2000万注册用户，也就是说，攻击者可以用这种方式轻易获取到所有这2000万用户的个人信息。这个漏洞非常简单，最终影响也很大。
2.2.越权漏洞#2 （IDOR，危急，赏金$3,000）
也就是在上一个相同的邀请测试项目中，我还发现了另外一个可以获取所有注册用户个人信息的漏洞。在目标应用中，用户可以为自己的组织结构创建不同的事件（event），还能往这些事件中添加进不同的参与用户，所以，在添加用户的时候，可以用上述漏洞#1类似的方法，获取到其他用户的个人信息。
在创建事件（event）的PUT请求中，存在一个contact_ids区域，攻击者可以通过联系人名单来更新事件操作，如果把它更改为结构外联系人名单，就能绕过UI界面限制，添加进任何联系人，以此来获取到这些联系人的个人信息。有意思的是，目标应用最终会返回一个以下的错误响应：
{"success":false,"errors":{"contacts":["must belong to the host or owner of the event"]}}
但尽管这样，刷新页面之后，添加进的联系人都会正常显示。所以，这里的经验就是，别盲目信任HTTP响应。
2.3.通过服务端请求伪造获取AWS元数据服务信息（SSRF，危急，赏金$1,000）
这里的目标应用允许把包括用户简历在内的不同信息导出为PDF格式文档，然而，很多PDF生成器都使用了HTML转换为PDF的方法，所以，在源信息中输入一些HTML代码之后，就能让目标应用在服务端执行相应的HTML代码。
像这样，在用户简历中插入以下代码段：
<iframe src="http://169.254.169.254/latest/meta-data">
当生成PDF文档时，上述代码就会被执行。这里我们在其中请求了一个AWS元数据服务，当目标应用生成PDF文档时，这个iframe框架就会被显示出来，当然，也就泄露了AWS元数据服务中的密码等敏感信息。
2.4.跨站资源共享策略配置不当（CORS Misconfiguration，高危，赏金$1,500）
该漏洞问题在于，针对目标涉及的某API域，存在一个影响整站的跨站资源共享策略配置不当错误（CORS Misconfiguration）。因为目标应用程序没有将访问源列入白名单，并且具备规则Access-Control-Allow-Credentials: true，所以，攻击者可以利用该错误以用户身份向攻击者控制端实现跨站请求。
最终，目标涉及的某API域会返回一堆关于用户、用户组织及其他相关用户的敏感信息。以下是CORS相关漏洞的概念验证代码（可在xhr.open方法中修改受害端URL）：
<html>
<body>
<h2>CORS PoC</h2>
<div id="demo">
<button type="button" onclick="cors()">Exploit</button>
</div>
<script>
function cors() {
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("demo").innerHTML = alert(this.responseText);
}
};
xhr.open("GET",
"https://api.company.com/endpoint", true);
xhr.withCredentials = true;
xhr.send();
}
</script>
</body>
</html>
2.5.强制浏览（Forced Browsing，低危，赏金$500）
该漏洞出在HackerOne平台网站上，攻击者可以利用该漏洞访问某些HackerOne即将举办的挑战赛目标范围。HackerOne的挑战赛通常是一个暂时性的邀请测试项目，其测试目标范围一般要在比赛开始时才会公布，而利用该漏洞却可以在开赛之前就能了解到比赛的测试目标范围。这样来看，该漏洞就能让比赛失去公平可言，因为攻击者在其他黑客知道测试范围之前就能进行大量的侦察测试，最终很容易操纵比赛结果。
此漏洞利用非常简单，攻击者只需通过以下相应比赛名称的URL，访问到原本属于隐藏策略内容的测试范围信息：
该URL中明确了测试范围的具体系统资产。通常，具备高声誉的大牛黑客会被邀请参加比赛，因此这种漏洞可能会被他们发现。
总结
希望从以上漏洞分享能给大家一个认识：很多威胁严重且容易发现的漏洞就在那里！大多测试目标中都会包含类似漏洞，甚至是已经存在好多年，只是被忽视了而已。每个人都有各自的挖洞思路和视角，你可能会发现其他人发现不了的漏洞。另外，如果你心态不端地去挖洞，则很容易陷入灰心气馁的境地。请保持正确的心态，专注于正确的领域，你的学习和毅力最终会让你有所回报。大堆的赏金就在前方，请擦亮双眼请坚持不懈！
*参考来源：medium，clouds编译整理，转载请注明来自FreeBuf.COM
如有侵权请联系:admin#unsafe.sh