找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

4631

积分

0

好友

635

主题
发表于 5 天前 | 查看: 25| 回复: 0

偶遇一个站点,前前后后花了大约三个月的时间才基本完成测试,期间发现了不少漏洞,其中不乏高危风险。现在对其中部分高危漏洞进行总结和分析,分享这段实战经验。

nday进后台:权限绕过的突破口

开局只有一个登录界面,信息有限。

平台登录界面截图,显示用户名密码错误

起初,我尝试通过插件提取接口并结合JS分析,但扫描提取到的路径均无果。弱口令登录也因为缺乏用户名提示而失败。最终,根据页面标题关键字进行搜索,找到了该平台的一个历史权限绕过漏洞(nday),成功进入后台。

搜索语句通常是:xxx系统历史漏洞xxx平台历史漏洞

浏览器地址栏截图,显示权限绕过payload路径

如上图所示,拼接特定的路径穿越Payload(如/../..;)即可实现权限绕过。

HTTP响应头截图,显示302跳转与Cookie设置

通过302跳转成功进入后台,界面显示为管理员权限。

系统管理后台主界面截图

经验之谈:进入一个系统后,切忌急于开始测试。首先要做的是全面了解系统的功能模块、基本结构和布局,然后将这些功能点转化为具体的数据包、接口和参数进行针对性测试。

在梳理了系统功能后,我点击了“个人信息”处,尝试寻找文件上传漏洞以获取Shell。

后台个人信息页面截图,含头像上传功能

点击“选择”按钮后,页面发生了一个奇怪的跳转:新开了一个页面。

新打开的CKFinder文件管理器页面截图

我首先尝试直接上传文件,但发现仅限图片格式。我观察到URL中存在type=images参数,尝试手动修改,但这个页面居然无法直接修改URL。复制URL到浏览器地址栏访问并修改,也未成功。

页面提供了修改文件后缀的功能,但同样被严格限制。

文件上传错误提示截图:“无效的扩展名”

此时,我识别出站点使用了 CKFinder 编辑器。于是,按照“CKFinder历史漏洞”的思路继续搜索。

CSDN博客文章列表截图,内容关于CKFinder漏洞

翻阅大量文章后,并未找到能直接成功复现的漏洞,但我发现了CKFinder的一个关键路径:将URL中?后面的参数全部删除,进入了以下界面。

CKFinder根目录管理界面截图

这时才明白,刚才只是处于images文件夹下,所以限制非常严格。切换到files文件夹后,我再次尝试上传可执行文件。但jspphp等后缀均被拦截,jspfjspx也无法绕过,于是转向尝试XSS类型的文件上传。

HTTP请求与响应截图,显示上传被安全策略拦截

上传测试发现,恶意内容被黑名单过滤。于是,我调整策略:先上传一个空的txt文档,上传成功后再利用编辑功能修改其内容和后缀名。

文件右键菜单截图,显示“编辑”选项

将文件编辑修改如下,将后缀名改为.pdf,内容插入XSS代码。

文件管理器界面截图,显示test.pdf文件

双击访问该文件:

浏览器弹窗截图,显示XSS代码成功执行

成功执行了恶意JS代码,造成弹窗。这类漏洞在管理员访问时极易导致Cookie被盗取,危害较大。

同时要记住,像这类较深入的功能点,极有可能存在未授权访问漏洞。尝试删除认证字段(如Cookie)后直接访问上传的文件:

HTTP响应截图,显示未授权访问成功并返回XSS代码

访问成功!由此,我们获得了“未授权访问”叠加“存储型XSS文件上传”的组合漏洞。这类漏洞可用于挂马、制作钓鱼页面等高危害操作,是安全/渗透/逆向领域中需要重点防范的风险。

多处SQL注入漏洞的发现与利用

该站点功能点非常多,这也是测试周期长达三个月的主要原因之一。

后台系统设置菜单管理页面截图

注入点1:直接SQL执行功能

在功能翻找中,发现了以下页面,提供了一个可以直接执行SQL语句的接口。

应用SQL管理功能界面截图

输入测试语句(如select sleep(5))并抓包查看:

开发者工具截图,显示SQL执行请求与成功响应

延时成功,证明SQL语句被执行。从设计初衷看,这或许不算“漏洞”,因为功能本就是如此。但在安全评估中,这类功能如果权限控制不当,攻击者完全可以利用它执行任意SQL,获取敏感信息、写入Webshell甚至修改账户密码。

注入点2:查询功能处的堆叠注入

站点存在大量查询功能点,并非每个都有漏洞,黑盒测试需要耐心逐个验证。

单位档案查询功能界面截图

对某个查询功能进行抓包测试,输入单引号导致报错,输入两个单引号‘’页面恢复正常,存在SQL注入迹象。尝试手工构造堆叠注入Payload:

开发者工具截图,显示注入Payload触发服务器500错误

利用SLEEP(5)函数配合堆叠注入,成功触发服务器延时,证实此处存在可被利用的SQL注入漏洞。

敏感信息遍历:从一点到一片的危害扩大

继续探索后台,发现了数据库连接管理功能。

数据库连接管理列表页面截图

正如前文强调的,黑盒测试一定要将功能点转化为数据包、接口和参数。否则,我可能只会看到页面上展示的一条数据库信息。在查看该功能点的网络请求时,我直接发现了展示该页面的请求与返回数据。

HTTP请求响应截图,泄露数据库连接信息

如上图,响应中直接泄露了数据库地址、用户名和密码(前端可能被部分隐藏)。但关键点在于请求参数:id=1。这明显是一个可遍历的参数。于是,我尝试遍历id值:

另一个数据库连接信息的请求响应截图

在前端页面,通常只能看到一条(如id=1时)数据库信息。而通过分析数据包并遍历id参数,我直接实现了对所有数据库连接配置的遍历,一举拿下五台不同数据库(包括MySQL、Oracle等)的敏感连接信息,使得漏洞危害呈指数级扩大。这再次凸显了在运维 & 测试中,对系统配置管理和访问控制进行严格审核的重要性。

这次漫长的测试经历表明,深入、耐心的测试往往能挖掘出表面之下串联的高危风险链。希望这次的实战剖析能为大家在云栈社区进行安全技术交流时提供一些有价值的思路。




上一篇:从核空间维度增长判断Jordan块大小:一个5x5矩阵的完整求解
下一篇:Hermes Agent技能系统(Skills)详解:核心机制、管理与内置技能大全
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-4-7 19:47 , Processed in 1.188478 second(s), 42 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表