//挖洞时间长了就习惯没人辣乌了，别愁兄弟！

挖洞，前期积累技术，后期主要靠思路了，主要思路来源是看看别人的挖洞经验。这篇文章想要告诉大家的就是在挖洞的时候有时可以换一种思路入手，那么就会手到洞来。这里提供一种方向就是业务逻辑层面安全问题的挖掘，这种漏洞对于各种企业来说也是很尴尬的方面，一是无法用安全防护设备和措施直接防护，二是不能保证程序员的思路是否绝对安全。所以说业务逻辑漏洞可以逃逸各种安全防护。相信最近挖洞的很多小伙伴能感受到众多SRC中SQL 注入漏洞、XSS漏洞、上传、命令执行等传统应用安全方面的漏洞越来越不好挖，如果有也被各种大佬第一时间捞走了，这样对有些小白挖洞势必会不太友好。

一、案例1

在目标网站漏洞测试中发现了一种简单的人机身份验证（Captcha）绕过方法，利用Chrome开发者工具对目标网站登录页面进行了简单的元素编辑就实现了Captcha绕过。

其次想要挖到逻辑漏洞首先我认为有两点事必备的：

1.一定要将自己牢牢摆在用户方

2.一定要理清业务逻辑链

人机身份验证（Captcha）通常会出现在网站的注册、登录和密码重置页面，以下是目标网站在登录页面中布置的Captcha机制。

新手vs老手挖洞技巧,初学者挖洞教程

从上图中可以看到，用户只有在勾选了Captcha验证机制的"I'm not a robot"之后，登录按钮（Sign-

IN）才会启用显示以供用户点击。因此，基于这点，我右键点击了Sign-In按钮，然后用Chrome开发者工具的"元素检查"（Inspect Element ）功能来查看Sign-In按钮的底层元素，这一看，竟然发现其在"提交"（Submit）动作之后，定义了"禁用"（Disable）属性，好吧，那我就把它改变成"启用"（Enable）试试看。

新手vs老手挖洞技巧,初学者挖洞教程

这一改，登录按钮（Sign-IN）显示且可点击了，好吧，我确实不是一个机器人，人机身份验证

（Captcha）在这里成了摆设。

新手vs老手挖洞技巧,初学者挖洞教程

我好奇服务端的验证方式，于是就用BurpSuite对上述过程进行了抓包，发现服务端一开始都不对用户提交的Captcha操作做验证，因此，即使我把提交的Captcha会话内容删除了，一样可以跳转到登录页面，根本不需要触发其中的"启用"（Enable）属性就行。

新手vs老手挖洞技巧,初学者挖洞教程

我简单做了一个PoC发给了厂商，他们马上就做了反馈和整改。绕过人机身份验证（Captcha）的方法还有很多，这只是一个小技巧而已。

二、案例2

接下来开始讲一个未授权实名认证漏洞：

1.顺便提一下此处另外一个逻辑漏洞就是短信轰炸，在获取验证码的时候能够绕过前端时间限制重复获取验证码，这个问题就不详细描述了相信很多人看了就懂，说这个就是为了讲一下测试逻辑漏洞时需要关注每个细节。注册成功后页面如下所示：

新手vs老手挖洞技巧,初学者挖洞教程

2.直接选择进入空间，可以发现以下页面：

新手vs老手挖洞技巧,初学者挖洞教程

3.点击去实名认证后，通过抓包能够抓到一串链接： http://***.***.cn/**/**/index**?

m0SRP4aSM4K/zfv6tLa7+32jUdEC0ca79BZ8izFvmPSg+5HLkcgg/ltb+bhcySn14uVuXzEmbWIEvLFG 70TOVqHPsqvlp/W28sSqG1t+yH/F1Lr/W4sovX3BFWtW14sH+ofndzOMxfeYaRafYypJT/CKvWhZ8Q3 x+deWfgGJ300=

4.尝试将此链接通过另外一个未登录任何账号的浏览器访问，成功访问到了并显示了实名认证的账号也就是用户名，并且能直接帮助该账号进行实名认证：

新手vs老手挖洞技巧,初学者挖洞教程

5.做完这一切我首先就是再创建了一个用户去梳理了一遍刚做过的测试，明确了该业务的逻辑链：

新手vs老手挖洞技巧,初学者挖洞教程

然而合理的业务逻辑应该是这样的：

新手vs老手挖洞技巧,初学者挖洞教程

可能有些人会问为什么要这样梳理一遍吗？挖完洞不就应该直接提交了吗？回答是现在有些SRC会让自己对自己提交的漏洞进行评级，评高了人家会给你降低，评低了人家会给你通过。尤其是逻辑漏洞这种不太好界定的漏洞需要挖洞者对自己挖的漏洞有一个清晰的认知，同时也是一种总结思考的行为吧。在分析整个流程的时候发现了其余的潜在隐患也是很有可能滴。

上述漏洞经过一番周折后被定义为高危，所以就想说其实你离高危就是一步之遥，关键看思路怎么走，在思维不是很活跃的时候往往细心和总结能帮很大的忙。

三、案例3

特斯拉的零部件目录网站（Tesla Parts Catalog）

1、编辑Cookie信息访问获取未公开车型Model Y的参数信息

我发现的漏洞是这样的。普通用户可以通过编辑Cookie信息，利用浏览器访问获取到特斯拉的一些非公开网页或数据。拥有特斯拉账户的公众用户，可以登录特斯拉零部件目录网站（epc.tesla.com）访问其中公布的车型部件数据。在访问测试该网站过程中，我发现了其中一个有意思的Cookie，可以通过编辑该Cookie信息，让非授权用户访问到特斯拉内部的非公众用户可浏览数据。如果放到过去，我觉得这没什么敏感的。但是，在Model Y车型发布在即的关头，作为一个超级特斯拉爱好者，我通过媒体了解到了很多该款车型相关的信息，因此，急切想目睹那些还未公开的Model Y相关零部件和原理图的心理驱使着我。

首先，我用我自己的公众账号登录特斯拉零部件目录网站（epc.tesla.com），之后，我在登录数据包中发现了一个名为EPCClaim的Cookie，在浏览器中它是base64编码的，如下：

新手vs老手挖洞技巧,初学者挖洞教程

解码之后的内容如下：

{"employeeId":0,"firstName":"General","lastName":"Public","email":" REDACTED@*****.com","countryCode":"US","languageId":null,"languageCode":null," currencyCode":null,"isInternalUser":false,"isBodyShopUser":false," isGeneralPublic":true,"tabs":false,"locationId":null,"bodyShopId":0," bodyShopName":null,"bodyShopCategory":null,"permissions":[]}

哦，仔细观察上述解码内容，其中竟然出现了permission（权限）的键值，这是用来干什么的？于是，我在另外一个JS脚本文件中发现了一些相关线索：

{accountManagement:"ACCOUNT_MANAGEMENT",bodyShopManagement:"

BODY_SHOP_MANAGEMENT",bodyShopAccountManagement:"

BODY_SHOP_ACCOUNT_MANAGEMENT",repairOrder:"REPAIR_ORDER",orderPane:"

ORDER_PANE",admins:"ADMINS",epcUser:"EPC_USER",addToolingData:"

ADD_TOOLING_DATA",model3Catalog:"MODEL3_CATALOG",modelYCatalog:"

READONLY_CATALOG",toolingCatalog:"TOOLING_CATALOG",serviceToolingCatalog:" SERVICE_TOOLING_CATALOG",returns:"RETURNS",statements:"STATEMENTS",creditmemos:"

CREDIT_MEMO",genealogy:"GENEALOGY",generalAccountManagement:"

GENERAL_ACCOUNT_MANAGEMENT",orderModel3:"ORDER_MODEL3",orderModelX:"

ORDER_MODELX",orderRoadster:"ORDER_ROADSTER",orderModelS:"

ORDER_MODELS",orderTooling:"ORDER_TOOLING",orderServiceTooling:" ORDER_SERVICE_TOOLING",orderModelSR:"ORDER_MODELSR"}

可以看到，该JS脚本文件是我买车型Model 3的相关访问参数，但其中一个键值modelYCatalog:

"READONLY_CATALOG"引起了我的注意，看到没，它包含了Model Y！好吧，那我就来编辑一下上述Cookie，看看编辑重发请求之后，我会收到什么响应内容。

大多数权限值都会向UI用户界面添加选项，但是它们对应的API接口只会相应地限制给具有Token令牌的授权用户，并且不允许访问或写入数据。那么Model Y涉及到的参数选项又如何呢？

这是访问我Model 3车型的Cookie：

对比上述Model 3车型Cookie，我把其中的isGeneralPublic参数值更改为false（意思也就是非公众用户），把isInternalUser参数值更改为ture（内部用户），然后根据前述JS脚本中涉及Model Y车型的 modelYCatalog:"READONLY_CATALOG"线索，把permissions参数值更改为READONLY_CATALOG，最后的访问Cookie如下：

{"employeeId":0,"firstName":"General","lastName":"Public","email":" REDACTED@*****.com","countryCode":"US","languageId":null,"languageCode":null," currencyCode":null,"isInternalUser":true,"isBodyShopUser":false," isGeneralPublic":false,"tabs":false,"locationId":null,"bodyShopId":0," bodyShopName":null,"bodyShopCategory":null,"permissions":"READONLY_CATALOG"}

接下来，我把该Cookie内容进行Base64编码形成Cookie值，用它去访问特斯拉零部件目录网站。之后，惊喜的是，我竟然可以在网站响应回来的零部件目录中看到Model Y车型的选项，点击进入，显示在眼前的就是完整的Model Y车型零部件参数数据！

2、构造搜索功能访问获取未公开车型Model Y的参数信息

过了几天，我在访问特斯拉零部件目录网站的过程中，又突发奇想，能不能通过其它方式获取到Model Y车型数据？网站中的搜索功能引起了我的注意，通过它可以查询到给定车型的所有零部件目录信息。在搜索测试中我发现，该功能仅依靠当前用户的浏览目录来过滤数据，就比如，在目录3中搜索时就只能查询到Model 3车型的零部件数据。

之后，我想通过浏览器检查功能的网络请求操作，观察是否可以更改搜索功能的API调用参数，去查询

Model Y车型数据。然后我发现其API搜索建议为，其中提到搜索功能调用的三个主要请求参数：CatalogModel（车型目录）、countryCode（国家代码）

比如说，如果我们用关键词"bumper"（保险杠）在目录3（Model 3车型）下执行搜索，之后发起的搜索请求就是：

用户登录特斯拉零部件目录网站后会生成一个Token令牌并存储在本地名为EPCToken参数中，搜索请求用该Token作为用户身份验证。但是我发现，Model Y 车型数据却不受任何安全限制，任何可以登录特斯拉零部件目录网站的公众用户，只要具备EPCToken参数下有效的Token令牌，在搜索功能中把 CatalogModel指定为ModelY，就能访问Model Y 车型的详细参数数据。也就是这样的：

curl 'https://epcapi.tesla.com/api/searchSuggestions?

catalogModel=ModelY&countryCode=US&term=XYZ_Part_Name' -H 'Connection: keepalive' -H 'Accept: application/json, text/plain, /' -H 'Authorization: Bearer REDACTED' -H 'Accept-Language: en-us' -H 'User-Agent: Mozilla/5.0 (Macintosh;

Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko)

Chrome/79.0.3945.130 Safari/537.36' -H 'Origin: https://epc.tesla.com' -H 'SecFetch-Site: same-site' -H 'Sec-Fetch-Mode: cors' -H 'Referer: https://epc.tesla.com/' -H 'Accept-Encoding: gzip, deflate, br' — compressed

按照其中的term关键词请求之后，特斯拉零部件目录网站服务端会返回Model Y 车型与关键词匹配的详细零部件信息，包括零部件编号、名称、注释等。

另外，我还发现可以通过参数systemGroupId对零部件所属的部件组（the group of parts）进行查询，比如可以通过以下包含systemGroupId的请求，查询相关部件组的使用情况：

https://epcapi.tesla.com/api/catalogs/XXX/categories/0/subcategories/0/systemGroups/XXXXX?vi

利用以上两种未授权方式，可以获取到目录Y下与Model Y 车型相关的所有参数信息。此外，通过 Model 3车型的公开数据，可以变换搜索关键字、标题、注释方式查询Model Y 车型的大部份部件信息，与此对比Model 3车型的异同之处，然后再通过各个零部件识别相应的部件组，完全有可能逐一查询到Model Y 车型的各个零部件参数信息。

看完大佬的案例，你学废了吗？

新手vs老手挖洞技巧 (挖洞技巧和思路)

一、案例1

二、案例2

三、案例3