一次通用漏洞挖掘分析+对线审核技巧

“对于未授权的测试应保持耐心，已经多次在实战中遇到不同接口不同功能处，鉴权参数有些能起到作用，但有些就是摆设，只要保持耐心和思考，就可以找到防护的最薄弱之处发现漏洞。”

漏洞影响范围以及赏金

fofa

icon_hash搜索

27,103 条匹配结果 ( 25,332 条独立IP ) 

鹰图

独立IP数38,325

资产总数25,243

漏洞类型
中危漏洞，存储xss，需要管理员权限

高危漏洞，未授权删除，无利用难度，无感删除核心软件

有点少了有一说一

展开思路

开局登录框，开始我们的常规思路分析

1. 弱口令尝试

  永远的0day，大多数的漏洞都是进入系统才能被挖掘到，测试功能点和思路才会开阔，才会对我们的渗透目标有更深的了解

2.js未授权

  结合上次文章的经验，系统对某步骤的操作判断成功或者失败都要在代码中给予体现，这就给了我们在数据包和js代码判断逻辑中寻找漏洞的机会

3.SQL注入

  即使在万能密码几乎已经绝迹的今天，我们仍旧可以对其进行测试，记得我的人生第一洞就是用万能密码成功进入了某系统，由此才开始了我的网路安全学习之旅。

这次的测试突破口也正是上面的思路之一，弱口令

弱口令的测试也是有一定技巧的，不能盲目直接上字典开始跑，一是现在网站大多都有验证码或ip封禁措施，二是不能确定自己测试的弱口令是否在其他的同类型站中也适用。（也许在A站爆破了很久结果换了B站直接admin/admin进去了）我们的目的是挖掘通用漏洞，而不是为了寻找特定站点的事件型漏洞。

利用搜索引擎搜寻（使用手册、使用教程、默认密码、初始密码）等关键字，成功在一个贴吧老哥的帖子底下发现了初始密码

接下来大概尝试了十几个站之后成功进入

接下来我们就点开这些功能点思考此系统的功能。

经过对用户手册的研读和上手操作，这样的一个功能引起了我的注意

根据上手操作，总结为这样的一个流程

管理员添加应用至系统--将应用程序发布在一个平台--授权给普通用户使用

这个逻辑中就有很多可以测试的点

是否能越权看到没有被授权的应用程序？

是否能未授权删除or增添某用户的应用程序？

等等.....

漏洞一xss

进入控制台后发现，这就是管理员创建应用并且授权给用户使用的功能

尝试把应用的配置信息写为xsspayload

发现有前端限制，故在数据包中修改

添加成功

先别急着开心，说不定是selfxss呢

授权给其他用户

我们登录其他用户的账号，可以看到被管理员授权查看的app

成功！可以实现xss所有普通用户

漫长未授权寻找之旅

这里是测试了很多接口和功能点都没有发现未授权，以前的我肯定会想，鉴权的措施肯定是应用于所有的敏感操作的功能和接口呀，所以只要一个点没有未授权，那么其他功能肯定也没有。

但是事实却不是如此

有的一些敏感操作的cookie或者seesion等鉴权措施还真是“一枝独秀”，在众多严防死守的城墙中，偏偏有一个角落“城门大开”没有任何防守，最终导致城池沦陷。

u64cdu4f5cu6210u529fuff01操作成功

问：get方式和post方式有什么不同？GET和POST是HTTP协议中两种最常见的请求方法，它们在客户端与服务器之间的数据交互方式、安全性、用途以及浏览器处理机制上有着显著的区别：数据传输方式：GET：请求参数附加在URL之后，以问号（?）分隔，多个参数间用&连接。由于URL长度有限制，因此GET请求通常不适合传送大量数据。POST：请求参数放在HTTP消息正文中，内容不显示在URL上，理论上可以传输比GET更大的数据量。可见性与安全：GET：所有请求参数都包含在URL中，对任何人都是可见的，包括历史记录、服务器日志等，可能导致敏感信息泄露。POST：请求参数在消息体中传递，用户无法直接查看，相对更安全。但是仍要注意，虽然请求体本身不可见，但通过网络抓包工具仍然可以截取到。缓存GET：请求一般可被浏览器缓存，适合获取静态资源，且对于同样的URL，浏览器可能会从缓存中加载响应结果，而不向服务器发起新的请求。POST：默认情况下不会被浏览器缓存，因为其常用于提交数据操作，每次提交的数据可能不同，不应该复用缓存。幂等性GET：具有幂等性，多次执行同一请求应该返回相同的结果，不会改变资源状态。POST：非幂等性操作，执行一次和多次可能有不同的效果，如创建资源或更新资源时，多次提交可能导致资源重复创建。书签/收藏GET：由于URL包含了请求的所有信息，所以可以直接将带有查询参数的URL添加为书签或分享给他人。POST：由于请求参数不在URL中，不能直接保存为书签或者通过URL重访该状态。数据限制早期版本的HTTP规范中提到GET方法有URL长度限制（通常约2048个字符），而POST没有明确的大小限制，但在实际应用中，服务器和中间件可能也有自己的限制。回退/前进按钮行为GET：当用户点击浏览器的后退或前进按钮时，会重新触发相同的GET请求，而不会引起副作用。POST：如果用户后退到一个POST页面并刷新或再次提交，浏览器可能会提示用户是否要重新发送POST请求，因为这可能会导致重复提交数据并更改服务器状态。HTTP协议规范定义GET：用于请求访问已被URI识别的资源，指定的资源经过服务器端解析后返回响应内容。POST：用于向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建或已有资源的修改。

高危，无感删除系统中全部应用程序，无需任何账户信息（）

都把数据包删减成这样了还能成功删除

说明这一串是没有任何作用的

Cookie: PHPSESSID=u23i1ppgn38g2p4llh834o92h5;CookieLanguageName=ZH-CN; think_language=zh-CN; UserAuthtype=0

也就是说

在此系统中 Cookie: 中的PHPSESSID字段作为用户的鉴权信息，但是在此功能点中，PHPSESSID字段并没有起到作用，删除后仍然有用，而且是get方式进行传递

这就导致只要在index.php 后拼接上

?s=/Admin/appdel/list/APPxxxxxx(应用编号)

就可以直接删除，攻击者只需要替换IP

遍历APP00000001APP00000999

就可以把全部的项目未授权删除。

http://xxxxxx/index.php?s=/Admin/appdel/list/APP00000006

最终达到效果

没有任何利用难度，攻击者只需要找到想日的站，然后拼接

就可以将该系统的核心功能----多用户共同使用的应用程序全部删除。

对线审核技巧（整活）

挖完洞之后的我美滋滋的躺在床上睡觉，心里想着这个洞肯定给的多，buff都叠满了：1.建站量巨大 2.核心功能点高危甚至严重 3.毫无利用难度

结果第二天早晨一看

？

300元rmb？？

我直接开始对线

对方一招：历史价就是这个价

打乱了我的对线思路，我竟然一时无法反驳

先冷静一下，转移话题，尝试其他思路

，

有戏，审核做出了让步

俗话说底线都是一点一点突破的（斜眼笑）

他也知道我说的有道理，但还是不愿让步，居然让我交别家

一看要崩，既然晓之以理不行，那就动之以情吧

成功

以前看很多大佬吐槽国内的行业环境有待提高，这次算亲身经历了

得不到该有的奖励无疑是对积极性最残酷的打压

但是后来想想，还是多留给国内的安全行业一点成长的时间吧

相信我们都会越来越好

最后，对线篇仅仅是一次小整活，没有任何对审核大哥不尊重的意思，我也很感谢他最后给我提高了赏金，白帽子和厂商的有效沟通可以让双方化解矛盾，促进合作。

文章将近3000字，详细记录了漏洞挖掘的思考和心路历程，更是包含了如何跟审核沟通的技巧，大佬看可能过于拖沓了，但是该是十分适合新手学习的。点个赞，转发一下再走吧~

原文始发于微信公众号（安心落意）：一次通用漏洞挖掘分析+对线审核技巧