【渗透测试】以实战学习渗透测试流程及报告

0x01 前言

有许多师傅在做渗透的时候，可能忙活了一天也没有出洞，有些师傅在漏洞范围迷茫了很久，还有师傅在定级时不知道怎么定，也有师傅在用漏扫后接下来不知道怎么做了，今天我们以自身经验来说一下，在日常服务于甲方的时候，怎么根据当时情况，根据单位要求来实现：定级、漏洞范围划分、规避风险项、漏洞测试模板、实现漏洞挖掘等

首先我们先场景模拟一下，视频讲解会在其后，我们慢慢介入

场景背景: 设X公司有小明，小李，老马三位刚来不久的渗透测试工程师   某天部门经理找到三人，告知因为重要活动，需要三人前往不同的地方进行渗透测试任务(1): 小明背景：练习时长两年半的应届生，刚毕业在此实习小明心理想法：what's up，我只会漏扫啊，刚装的awvs还没用过呢，goby还得开会员，天崩(2): 小李背景：从其它行业转过来的，爱吃烤辣椒，参与了xx培训机构，有底子，基本的owasp还是会点小李心理想法：嗯？虽然我倒是会点，但是毕竟还没怎么实战过，以前做的都是比较基础的工作对于哪些漏洞该写，哪些不该写，我也有些郁闷啊，怎么定级，怎么做模板呢，小李还是挺忐忑的(3): 老马背景：一个确实具有两年半经验的安全人员，对于安全的一些基础，运维，培训，等保，应急，渗透都会些，再加上经常看州弟的公众号文章，都还是没啥大问题的老马心理想法：于是，老马熟悉的询问了部门经理，关于甲方对于漏洞定级和严格度的标准，以及渗透测试模板

这时候，有些师傅会想说，渗透测试不就是打进系统，然后在内网翻东西吗，继续横向渗透，等等等等

还有师傅可能会说，假如部门经理没有给他模板或者定级要求，严格程度，这怎么做呢

不要着急，我们慢慢细说，在渗透测试之前，我们需要先掌握什么呢，owasp top 10的基础，API漏洞、逻辑漏洞、不限于代码审计、逆向、汇编等技能和本次测试的资产，关于后面的测试方法，可以参考下图以及之前发布的文章

我们接着看视频讲一下大概，公司渗透测试与src挖洞和红队打法的不同(以测试单位要求为准)

* 文中资料仅供参考，单位要求不统一，只进行提供思路，不作为所有依据

* 如您认为文章质量对您有所帮助，麻烦点个关注并转发让更多人看到

0x02 场景复现

首先，需要掌握基本的漏洞挖掘和思路是必须的，在出洞后渗透测试报告必写的，而且定级也好定，且看下面分析的几个案例，案例以SRC代替模拟渗透测试流程以及排查风险项

案例一

某场景下的SRC漏洞挖掘过程，在某次SRC中，小程序开通会员处，根据获取到相关支付数据包后，修改数据包内金额，达到0元购的目的

查看到当前身份非会员，限制了很多功能，前往开通会员处，选择套餐并开通会员，抓取到数据包，base64编码

解码后看到对应价格为3999，此价格与对应的订单号绑定，没有进行二次校验，用户可以抓取流量包后自定义价格改包后即可完成自定义价格支付，如0元购

支付成功后即可获取到会员，这里截不到会员的图了，因为后面风控，自动给我封了，自动退款了

这个当时也写文章了，五月份的事了，现在漏洞已经修复了文章如下

此时我们可以思考一下漏洞成因，因为可以成功利用，就不叫风险项，首先观察前后流量包，他没有多次去校验金额或参数等，只有一个包，其次就是未对商品金额进行固定，这里我们需要写在报告中的成因和修复建议

案例一渗透测试报告模板----------------------------------漏洞名称：xxx支付漏洞----------------------------------危险等级：高危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于在开通会员处选择套餐后，用户可修改包内金额且系统未进行二次判断金额，造成直接调用支付接口支付成功----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 建议对数据包传输过程进行非对称加密，而不是可轻易解码的编码  2. 建议对商品套餐进行固定金额并以商品 'subject'字段进行二次校验  3. 对支付金额进行原定的不可小于xx元或拒绝小数支付等方式(以套餐为主)

案例二

如某次互联网渗透测试，已知主域名资产，对其进行子域名信息收集，找到旁站，打开后icon为think PHP框架，经过报错后已知版本，然后经过寻找历史漏洞反序列化进行注入文件，远程连接后传入C2-添加用户-远程控制

此处输入不存在的路径达到报错后可获取到当前TP框架版本，这种情况我们可以做个路由，匹配策略然后跳转到某页面，当然了，有时候输入不存在或某些字符会报错，为了规避这种问题，开发可以在使用TP框架时，关闭dubug，以免被攻击时，猜解出一些路径，函数或者敏感语句等，其次就是做路由，不存在的路径跳转到某页面等加以限制

通过其命令执行漏洞获取到当前用户并确定系统为Windows，而后利用命令注入写入一句话木马，并远程连接

后续进行了注入冰蝎，上传C2并创建用户远程连接成功，此处不在演示，各位可以看以下文章，四月底发的

这种情况下肯定也是漏洞而并非风险项，总结原因，由于使用了历史版本且存在漏洞的TP框架，导致攻击者可以执行代码注入，命令注入，反序列化等，而后成功达到渗透进入系统的目的，危害高危，基本不用说，进入系统后会被用来干嘛，做跳板机，做肉鸡都有可能

案例二渗透测试报告模板----------------------------------漏洞名称：xxx站点ThinkPHP命令执行漏洞----------------------------------危险等级：高危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于xx站点使用的ThinkPHP框架版本存在历史漏洞导致攻击者可以执行任意命令和调用代码函数，可成功进入系统----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 升级相关ThinkPHP框架版本并进行复测相关漏洞  2. 在路由上进行定义不存在的页面跳转到某页面或隐藏版本等  3. 如有debug可关闭debug模式  4. 定期进行渗透测试和漏洞扫描以及关注相关组件框架漏洞库，防止被攻击

在文中提起debug模式，在之前呢，我找到一例有关杀猪盘的站点，同样是通过debug模式在登录页面经过报错看到了此登录页面的SQL语句，并成功利用SQL注入漏洞进行分析其数据，详情可查看以下文章

案例三

某次渗透测试项目中，在请求某接口处，会自动调用系统获取当前时间，参数为startTime，然后和结束时间为endTime，在当前时间加七天，接着会将时间返回至前端，然后联合其它参数进入数据库中查询其数据，我根据当时参数使用单引号测试，发现报错，并成功看到SQL语句，并且是Oracle数据库

我们可以模拟一下当时大概程序，逻辑应该是先通过程序获取到时间以及结束时间，传递给数据库进行查询，但是中间没有过滤传入的单引号，导致的报错以及可以传入payload

<%@ page import="java.util.Date" %><%@ page import="java.text.SimpleDateFormat" %><%Date now = new Date();SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");String startTime = sdf.format(now);long oneDay = 24 * 60 * 60 * 1000; // 一天的毫秒数long oneWeek = oneDay * 7; // 一周的毫秒数Date endTime = new Date(now.getTime() + oneWeek);String endTimeStr = sdf.format(endTime);int status = 1;request.setAttribute("startTime", startTime);request.setAttribute("endTime", endTimeStr);request.setAttribute("status", status);out.println("Start Time: " + startTime);out.println("End Time: " + endTimeStr);out.println("Status: " + status);// 后续执行用户自定义、SQL查询等操作%>

在程序中查询时间没有问题，有问题的是前端参数的可控性，攻击者可通过返回语句构造payload来测试并达到攻击成功的目的

后经过验证存在时间盲注和报错注入，使用sqlmap也可以注入成功

案例三渗透测试报告模板----------------------------------漏洞名称：xxx站点SQL注入漏洞----------------------------------危险等级：高危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于xx站点xx功能xx参数用户可控，经过测试此处存在SQL注入攻击者可通过恶意请求构造payload对数据库内信息进行获取----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 对SQL语句进行重写，PDO等方式，防止前端传入的特殊字符被SQL语句执行  2. 前端可对传入的特殊字符进行实例化防止构成恶意请求  3. 前端可对恶意字符以及特殊语句、词组等进行过滤，防止恶意攻击

案例四

某报表系统存在的任意文件上传漏洞，这里我记得好像当时是看的小黑说安全师傅公众号的文章，进行复现的，分析的还是很到位的，InputServerlet.java文件中可以看到action参数的处理逻辑

然后在uploadFile.java文件中可以看到文件上传的逻辑，只限制了上传文件的大小，没有上传文件类型限制

然后通过遍历上一级的方式去进行上传文件，在代码中没看到传哪里去了，最后跟着小黑师傅复现，传递到web主目录下，接着访问传入的文件即可成功

文件上传成功且可以成功利用，属于漏洞而不是风险项，我们按照漏洞写，当然属于高危

案例四渗透测试报告模板----------------------------------漏洞名称：xxx站点文件上传漏洞----------------------------------危险等级：高危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于xx站点使用的xx报表系统，此版本存在文件上传漏洞由于程序未进行过滤文件类型以及对路径固定，攻击者可未授权进行任意文件上传----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 对上传的文件类型做过滤，对上传的路径进行固定  2. 更新最新版官方报表系统且或打补丁的方式  3. 如暂时不用可以将此接口暂时屏蔽或删除进行暂缓之计

案例五

说了这么多owasp top10漏洞了，我们看一下之前挖过的一个API漏洞，也属于逻辑漏洞，原因是因为某学校的SSO系统，在js中某接口为更改密码接口，在更改密码前会验证此用户是否存在，验证包内会回显出该用户的密码MD5(如存在)，其实当时官方更新了新版本，学校可能还没来得及更新

在/service/users/sec/index中看到绑定安全配置页面，页面可以未授权访问

在页面内用户名处，输入用户名后，会调用js发送查询请求是否存在此用户，前端html页面没看出来啥，但是看流量包，json返回了一堆存在用户个人信息，其中包括密码(MD5)

于是乎通过此漏洞加上SSO特征找到两所学校存在相应漏洞，并以管理员的身份进入后台可以看到几万人数据以及系统内所有系统：教务系统、报修系统、新生系统等

后来漏洞也提交给edusrc了，一周左右就修复完成了，可以参考下方文章

案例五渗透测试报告模板----------------------------------漏洞名称：xxx站点未授权访问漏洞----------------------------------危险等级：高危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于xx学校使用的sso某接口可以进行未授权接口在实现功能前会校验用户名是否存在，存在回返回该用户的所有信息----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 对当前使用的SSO系统进行打补丁或更新至最新版本  2. 对接口进行限制，校验访问时进行鉴权和是否为当前用户  3. 包内只校验用户名是否存在，其余信息不进行返回

案例六

说了这些漏洞被利用成功了，我们可以说一下关于风险项的东西，所谓风险项，在我认为，即：某接口或页面可能会构成危害，但是由于自己因为各种原因无法实现，别人可能会攻击成功的，称为风险项，这个级别可自行定义，按照当时所在环境等

某登录页面可以看到，用户名被加密了，这不是base64哈，然后密码为MD5加密，此时我们可以通过翻js，查看前端源代码，断点调试的方式去逆向加密方法及密钥

我通过在前端源代码中看到，加密程序被写入了前端JavaScript程序中，密钥就是打码区域，使用了AES加密，我们都知道，AES和RSA就是对称加密与非对称的区别，AES的加解密用的都是同一个密钥，当然了，AES256目前据说挺安全的

我直接在console中调用即可，在上图中，userName我输入的zhangsan，我们此时还是使用zhangsan进行加密

已知AES特性，继续反过来写解密脚本，加密是encrypt，解密就是decrypt

此处即为风险项，加密就是为了增加安全性，但是由于个人通过此方式将密文解密，将明文加密，无需前端控制，自由支配，攻击者可使用程序进行写脚本，爆破等，一般情况下，此处可以写上问题和整改项，因为此处往下没有利用成功漏洞，但是不代表后期别人会不会利用成功

案例六渗透测试报告模板----------------------------------漏洞名称：xxx站点弱加密可逆向----------------------------------危险等级：中危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于加密规则和密钥定义在了前端源代码中攻击者可以轻易进行加解密操作，以完成后续可能的爆破及解密其它数据包----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 对前端页面存在的加密采用js混淆加密  2. 推荐使用AES256或RSA非对称加密等方式增加安全性

案例七

在之前做过的一些项目中，遇到了不少druid，一般会存在于使用API和某些框架监控使用，比如若依，一般druid遇到之后就是爆破，之前遇到过这么一个情况

在正常情况下，访问druid会正常加载登录页面，但是开发对页面做了鉴权，在登录情况下，系统会在header增加Admin-token的参数，假如携带此参数可成功访问druid，反之则401状态码

此处出现的问题就是，开发对是否存在Admin-Token字段及其内容是否正确做了判定，但是没对是否为管理员用户还是普通用户做判定，造成了权限分配不均，携带Token照样可以爆破，且为弱口令

案例七渗透测试报告模板----------------------------------漏洞名称：xxx站点durid绕过鉴权弱口令----------------------------------危险等级：高危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于未对Token鉴定到个人，而只是鉴定是否存在且正确攻击者可携带普通用户Token进行攻击后续应用----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 对druid管理员密码增加密码强度，以防止轻易爆破  2. 对携带Token进行鉴权到个人，而不是只校验是否存在或正确  3. 如暂时不需要可临时下架删除等以防止危害扩大

案例八

之前在挖掘某APP漏洞时，在文件上传处上传文件，测试上传身份照片功能，限制了一些文件类型，但是可以绕过，当时只用php做了测试，因为语言肯定不是php写的嘛，主要测试用，只不过文件最后上传到OSS去(没有发现泄露OSS信息)

测试到上传文件策略使用的黑名单策略，跑了一些字典，使用php3上传成功

当然了访问是不执行的，因为不会解析，OSS正常解析这个就危险了，这个算是风险项，危险等级自定义，考虑因素如下：

设某功能，传入简历(其中有)，由于未对上传类型严格限制，使用了黑名单策略，可以通过绕过的方式上传一些其它文件，如上传钓鱼文件等，完成一些后续攻击，其次本该作用于只接收图片文件而做白名单策略也没什么不妥，以防止一些可能存在的隐患

案例八渗透测试报告模板----------------------------------漏洞名称：xxx站点任意文件上传(暂不可利用)----------------------------------危险等级：低或中危(自定)----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于未对上传的文件类型进行过滤攻击者可上传图片类型以外的文件，可能会造成未知的危害----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 将上传文件的扩展名设定白名单而不是黑名单      2. 对上传的文件类型进行严格过滤    3. 上传成功后不在响应内容包内返回文件路径

案例九

在遇到某些渗透环境的时候，一些环境在登录入口，可爆破，但是由于自身字典不足或在前端看着开启了图片验证码等方式，我们尝试绕过成功了，这种情况也属于一个风险项，如：登录接口可爆破风险，用户名可枚举风险，此处举例当初做渗透时遇到的情况

通过前端源代码看到有login.html文件，经过对比，前端登录是被加密了的，而login.html是没有加密的，这里就可以利用，也就是漏洞点了

而且前端登录页面后面是存在图片验证码的，验证码和sliderToken绑定的，只能用一次，也是加密后jwt编码，暂时没有办法逆向到，接下来访问到login.html

没有加密，那么直接尝试爆破，毅然决然的实现爆破，当然了，字典不够，只是验证危害性

后来漏洞也是修复了，当IP请求3次且登录失败后则加载滑块验证码，IP不可伪造，请求的是网络层IP

案例一渗透测试报告模板----------------------------------漏洞名称：xxx支付漏洞----------------------------------危险等级：高危----------------------------------测试时间：2024年x月x日----------------------------------测试地址：xx.com----------------------------------漏洞成因：由于在开通会员处选择套餐后，用户可修改包内金额且系统未进行二次判断金额，造成直接调用支付接口支付成功----------------------------------漏洞出现地址：  附POC和图片----------------------------------修复建议：  1. 建议对数据包传输过程进行非对称加密，而不是可轻易解码的编码  2. 建议对商品套餐进行固定金额并以商品 'subject'字段进行二次校验  3. 对支付金额进行原定的不可小于xx元或拒绝小数支付等方式(以套餐为主)0