简介：本资源是一个基于Java开发的Web漏洞扫描系统实现方案，面向网络安全初学者、渗透测试学习者及Java安全工具开发者，用于理解常见Web漏洞（如SQL注入、XSS、目录遍历等）的检测逻辑与插件化扫描架构设计。压缩包共927个文件，主体为604个NSE脚本（Nmap Scripting Engine，用于协议识别与漏洞探测）、146个Lua脚本（支撑动态规则匹配与响应解析）、30个编译后的class文件及12个核心java源码，辅以XML配置、JAR依赖库、启动脚本（bat）和审计规则文件（audit、changelog等），整体结构体现典型安全扫描器的模块划分与扩展机制。资源大小为33.07MB，目录组织规范，含完整运行环境支持与多协议指纹库（如nmap-os-db、ssl-fingerprints、nmap-services等）。已有467人学习下载，读者可直接部署运行、调试扫描流程、复用NSE/Lua检测逻辑、分析Java主控层调度机制，并参考LGPL-2.1等开源协议合规集成到自有安全平台中。
1. 不是写个爬虫加几个正则就能叫“漏洞扫描”：一个能过答辩、能跑通、能解释清楚原理的Java Web漏洞扫描系统到底长什么样？
很多同学做毕设/课设时一搜“Web漏洞扫描”，第一反应就是用Python写个requests发包+re.findall匹配关键词，再套个Flask界面——结果答辩被问“你这个XSS检测怎么区分反射型和DOM型？”“SQL注入的布尔盲注你是怎么判断真假响应的？”当场卡壳。更现实的问题是：这种脚本连一次完整的目标站目录遍历都跑不完，超时、重定向循环、登录态维持全靠硬编码补丁，最后导出的报告里只有“发现疑似XSS”，连触发路径和PoC都没法复现。这套基于Java的Web漏洞扫描系统设计，就是为解决这三个硬伤而生：它用标准HTTP客户端管理会话生命周期，用状态机驱动漏洞验证流程，所有检测逻辑封装成可插拔的Detector接口实现，最终输出带请求/响应原始数据、上下文快照、修复建议的结构化报告。适合需要交完整方案文档、有模块划分图、有核心代码片段、能现场演示扫描流程与结果溯源的学生，也适合作为某高校信息安全课程设计中“从协议解析到漏洞建模”的落地载体。
2. 总体架构设计：四层解耦结构与五个核心模块的职责边界
这套系统不是单体Jar包堆功能，而是按“协议交互—目标建模—检测调度—结果归集—报告生成”五阶段分层，每层只依赖下层接口，不碰具体实现。Java技术栈选型明确：HTTP通信用Apache HttpClient 4.5（非OkHttp，因需深度控制连接池与重试策略），HTML解析用Jsoup 1.15（非Jsoup旧版，因支持CSS选择器与DOM树遍历稳定性更好），多线程调度用CompletableFuture组合而非原始Thread，避免线程泄漏风险。整个工程采用Maven多模块结构，core模块定义Detector、Scanner、Report抽象，http-client模块封装带CookieStore自动同步、Referer自动继承、User-Agent轮换的请求工厂，detector模块下按漏洞类型分包（如xss、sqlinj、path-traversal），每个Detector实现detect(RequestContext context)方法并返回DetectionResult对象。这种结构让答辩时能清晰回答“如果要加一个SSRF检测模块，你改哪几个文件？为什么不用动报告生成逻辑？”
2.1 协议层：HttpClient定制化封装的关键参数配置
直接new HttpClient会踩一堆坑：默认连接池大小为2，扫10个URL就排队；默认不处理302跳转，遇到登录页重定向就停住；Cookie不自动同步，带Session的页面扫完就失效。我们在http-client模块中封装了SmartHttpClient类，关键配置如下：
public class SmartHttpClient { private static final PoolingHttpClientConnectionManager connectionManager; private static final CloseableHttpClient client; static { // 连接池：最大20个总连接，每个路由10个，避免并发过高被WAF拦截 connectionManager = new PoolingHttpClientConnectionManager(); connectionManager.setMaxTotal(20); connectionManager.setDefaultMaxPerRoute(10); // 请求配置：超时统一设为8秒，启用自动重定向但限制最多3次 RequestConfig config = RequestConfig.custom() .setConnectTimeout(8000) .setSocketTimeout(8000) .setConnectionRequestTimeout(8000) .setRedirectsEnabled(true) .setMaxRedirects(3) .build(); // CookieStore：使用BasicCookieStore实现跨请求Session保持 CookieStore cookieStore = new BasicCookieStore(); client = HttpClients.custom() .setConnectionManager(connectionManager) .setDefaultRequestConfig(config) .setDefaultCookieStore(cookieStore) .build(); } }这段代码不是贴出来凑数的——它直接决定了扫描器能否稳定跑完一个含登录态的后台系统。比如某模拟项目X的CMS后台，首页需登录后跳转到/admin/dashboard，若没启用setRedirectsEnabled(true)且cookieStore未注入，第二次请求就会因无Cookie返回401。我一般会在答辩前用Wireshark抓包对比：开启重定向后，三次请求的Cookie头是否连续传递，这是验证协议层是否真正work的第一步。
2.2 目标建模层：从URL字符串到可执行扫描单元的转换规则
很多同学把输入当URL列表，直接for循环调用检测函数，结果XSS检测在/search?q=test上跑完，又去/user/profile?id=123重复执行同一套payload，既低效又漏检。我们定义TargetModel类，将原始URL解析为结构化对象：
public class TargetModel { private String baseUrl; // https://example.com private String path; // /search private Map<String, String> params; // {q: "test"} private HttpMethod method; // GET private Map<String, String> headers; // {X-Requested-With: XMLHttpRequest} // 构造时自动解析：https://example.com/search?q=test&lang=zh → // baseUrl=https://example.com, path=/search, params={q:test, lang:zh} public TargetModel(String url) { try { URI uri = new URI(url); this.baseUrl = uri.getScheme() + "://" + uri.getHost() + (uri.getPort() != -1 ? ":" + uri.getPort() : ""); this.path = uri.getPath(); this.params = parseQuery(uri.getQuery()); } catch (URISyntaxException e) { throw new IllegalArgumentException("Invalid URL format", e); } } private Map<String, String> parseQuery(String query) { Map<String, String> map = new HashMap<>(); if (query == null || query.isEmpty()) return map; for (String pair : query.split("&")) { String[] kv = pair.split("=", 2); if (kv.length == 2) { map.put(URLDecoder.decode(kv[0], StandardCharsets.UTF_8), URLDecoder.decode(kv[1], StandardCharsets.UTF_8)); } } return map; } }这个类的价值在于：后续所有Detector都接收TargetModel而非String，意味着XSS Detector可以精准地只对params中的每个value插入payload，而SQLi Detector可识别params中数字型参数（如id=123）优先尝试布尔盲注，字符型参数（如name=test）优先尝试报错注入。答辩时被问“你怎么知道哪个参数该插XSS payload？”，答“看TargetModel.params的key-value结构，不是靠正则猜”，立刻拉开和脚本党的差距。
2.3 检测调度层：CompletableFuture链式编排与失败熔断机制
传统for循环串行扫描，100个URL耗时100×8秒=13分钟，且一个URL超时会导致后续全部阻塞。我们用CompletableFuture实现并行+熔断：
public List<DetectionResult> scan(List<TargetModel> targets) { return targets.stream() .map(target -> CompletableFuture.supplyAsync(() -> { try { // 每个Detector有自己的超时控制（如XSS检测限3秒） return xssDetector.detect(target); } catch (Exception e) { // 记录异常但不停止整体流程 log.warn("XSS detect failed on {}", target, e); return DetectionResult.failed(target, "XSS", e.getMessage()); } }, executorService)) .map(future -> future.orTimeout(5, TimeUnit.SECONDS)) // 整体单任务超时5秒 .map(CompletableFuture::join) .collect(Collectors.toList()); }这里executorService是自定义线程池（new ThreadPoolExecutor(5, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100))），核心线程数5避免压垮目标服务器，队列上限100防内存溢出。orTimeout(5, TimeUnit.SECONDS)是关键：即使Detector内部没设超时，外层也会强制中断，防止某个死循环payload拖垮整个扫描。某次实测中，一个目标站对' OR SLEEP(30)--响应极慢，没加这行代码时整个扫描卡住4分钟，加了之后5秒就跳过，继续扫下一个URL。这就是为什么我说“超时不是可选项，是保命线”。
3. 核心漏洞检测模块实现：XSS与SQL注入的建模逻辑与验证闭环
检测模块不是简单发个<script>alert(1)</script>就标“存在XSS”，而是建立“输入点识别→Payload生成→响应分析→上下文定位”四步闭环。每个Detector必须实现detect(TargetModel target)，返回包含原始请求、响应、触发位置、修复建议的DetectionResult。下面以XSS和SQLi为例，展示真实可运行的检测逻辑。
3.1 XSS检测：基于上下文感知的Payload分级注入策略
XSS检测最常翻车的是“盲打”。比如在HTML标签属性里插" onerror=alert(1)，但在JavaScript字符串里插同样的payload就无效。我们的XSS Detector先用Jsoup解析响应HTML，定位所有可注入点（input value、href、script标签内等），再按上下文类型分发不同Payload：
public DetectionResult detect(TargetModel target) { // Step 1: 获取原始响应（带headers和body） HttpResponse response = httpClient.execute(target.toHttpGet()); String html = EntityUtils.toString(response.getEntity(), StandardCharsets.UTF_8); // Step 2: Jsoup解析DOM，提取所有可能的注入点 Document doc = Jsoup.parse(html); List<InjectionPoint> points = extractInjectionPoints(doc, target); // Step 3: 对每个点注入对应上下文Payload for (InjectionPoint point : points) { String payload = generatePayloadByContext(point.getContext()); TargetModel mutated = target.withParam(point.getParamName(), payload); HttpResponse testResp = httpClient.execute(mutated.toHttpGet()); String testHtml = EntityUtils.toString(testResp.getEntity(), StandardCharsets.UTF_8); // Step 4: 检查payload是否原样回显，且在正确上下文中可执行 if (isPayloadReflected(testHtml, payload) && isContextValid(testHtml, payload, point.getContext())) { return DetectionResult.success( target, "XSS", String.format("Reflected in %s context at param '%s'", point.getContext(), point.getParamName()), mutated.toHttpGet().getURI().toString(), testResp, "对输入进行HTML实体编码，服务端输出前过滤<script>等危险标签" ); } } return DetectionResult.notFound(target, "XSS"); } private String generatePayloadByContext(String context) { switch (context) { case "html": return "<img src=x onerror=alert(1)>"; case "attr": return "\" onfocus=\"alert(1)\" autofocus=\"\""; case "script": return ";alert(1)//"; case "js-string": return "+alert(1)+"; default: return "<xss>"; } }注意extractInjectionPoints()方法会遍历DOM找所有<input value="xxx">、<a href="xxx">、<script>var x='xxx'</script>等结构，并标记其上下文类型。这样做的好处是：答辩时能指着报告说“这个XSS在<input value='[payload]'>里触发，所以属于HTML上下文，应该用HTML编码防御”，而不是笼统说“网站有XSS”。
3.2 SQL注入检测：布尔盲注的状态机验证流程
SQLi检测最怕误报。比如id=1' and 1=1--返回200，id=1' and 1=2--也返回200（因WAF拦截了非法字符），就误判为存在。我们用三步状态机验证：
- 基准请求：
id=1→ 记录正常响应长度len_normal、状态码code_normal - 真值请求：
id=1 AND 1=1→ 若响应长度≈len_normal且状态码=code_normal，进入下一步 - 假值请求：
id=1 AND 1=2→ 若响应长度显著不同（如-30%）或状态码变为500，则确认布尔盲注
private boolean isBooleanBlindSqlInj(TargetModel target) { String baseParam = target.getParams().keySet().iterator().next(); TargetModel base = target.withParam(baseParam, "1"); TargetModel trueCase = target.withParam(baseParam, "1 AND 1=1"); TargetModel falseCase = target.withParam(baseParam, "1 AND 1=2"); HttpResponse baseResp = httpClient.execute(base.toHttpGet()); HttpResponse trueResp = httpClient.execute(trueCase.toHttpGet()); HttpResponse falseResp = httpClient.execute(falseCase.toHttpGet()); long baseLen = getResponseLength(baseResp); long trueLen = getResponseLength(trueResp); long falseLen = getResponseLength(falseResp); int baseCode = baseResp.getStatusLine().getStatusCode(); int trueCode = trueResp.getStatusLine().getStatusCode(); int falseCode = falseResp.getStatusLine().getStatusCode(); // 真值响应应与基准一致，假值响应应明显不同 return (Math.abs(trueLen - baseLen) < 50 && trueCode == baseCode) && (Math.abs(falseLen - baseLen) > 200 || falseCode != baseCode); }getResponseLength()取响应体字节数（非Content-Length头），因有些WAF会篡改header但不动body。这个逻辑在某次测试中成功避开某WAF的关键词过滤：它放行1=1但拦截1=2，导致falseCase返回403，而trueCase返回200，状态码差异直接触发判定。这就是为什么说“别信WAF放行的payload，要信响应本身的稳定性”。
3.3 路径遍历检测：基于403/200状态码切换的敏感目录探测
路径遍历不是只测../../etc/passwd，而是构建敏感路径字典+状态码模式匹配。我们预置paths.txt含/etc/passwd、/windows/win.ini、/proc/version等，对每个参数尝试../前缀：
public DetectionResult detectPathTraversal(TargetModel target) { List<String> sensitivePaths = loadSensitivePaths(); // 从resources/paths.txt读 for (String path : sensitivePaths) { String payload = "../".repeat(3) + path; // 生成 ../../etc/passwd TargetModel mutated = target.withParam(target.getParams().keySet().iterator().next(), payload); HttpResponse resp = httpClient.execute(mutated.toHttpGet()); int code = resp.getStatusLine().getStatusCode(); String body = EntityUtils.toString(resp.getEntity(), StandardCharsets.UTF_8); // 关键判断：403表示路径存在但被拒绝（典型WAF拦截），200且含敏感内容则确认 if (code == 403 && body.toLowerCase().contains("forbidden")) { return DetectionResult.warning( target, "PathTraversal", "403 Forbidden detected with payload '" + payload + "', suggests path exists but access denied", mutated.toHttpGet().getURI().toString(), resp, "服务端应校验用户输入，禁止解析含'..'的路径" ); } if (code == 200 && isSensitiveContent(body)) { return DetectionResult.success( target, "PathTraversal", "Sensitive file content leaked: " + path, mutated.toHttpGet().getURI().toString(), resp, "禁用目录遍历，使用白名单校验文件路径" ); } } return DetectionResult.notFound(target, "PathTraversal"); }isSensitiveContent()检查body是否含root:x:0:0:（Linux passwd特征）或[extensions]（win.ini特征）。这种设计让报告能区分“疑似存在”和“已确认泄露”，比单纯标红“存在路径遍历”专业得多。
4. 常见问题排查：五个必踩的坑与血泪解决方案
做这个项目时，我和A同学一起调试了两周才跑通全流程。以下是实际开发中最高频、最隐蔽、最容易答辩翻车的五个问题，按“现象→原因→解决”给出可立即操作的方案。
4.1 现象：扫描器对含登录态的后台页面始终返回401，但浏览器能正常访问
原因：目标站使用HttpOnlyCookie存储Session，而Jsoup解析HTML时无法获取该Cookie，导致后续请求缺失认证凭证。
解决：SmartHttpClient中必须使用BasicCookieStore并确保每次请求都绑定该store。检查httpClient.execute()调用前是否传入了同一个cookieStore实例。可在execute方法内加日志：log.debug("Cookies sent: {}", cookieStore.getCookies())，确认SessionID是否出现在日志中。
4.2 现象：XSS检测在<script>var x='xxx'</script>中注入'+alert(1)+'，但响应里没回显
原因：前端JS对输入做了encodeURIComponent()，服务端未解码直接拼接到script中，导致payload变成'+alert(1)+'字符串而非可执行代码。
解决：XSS Detector需增加URL编码绕过检测。在generatePayloadByContext("js-string")中返回"+alert(1)+"的同时，追加"+eval(atob('YWxlcnQoMSk='))+"（Base64编码版），并检查响应中是否出现eval(atob(片段。这是绕过前端编码的通用技巧。
4.3 现象：SQL注入检测对id=1返回200，对id=1'返回500，但id=1 AND 1=1仍返回500，无法进入布尔盲注流程
原因：WAF拦截了单引号，但放行了AND关键字，导致语法错误发生在WAF层而非数据库层，1=1根本没到DB。
解决：增加WAF指纹识别步骤。在发送id=1'后，检查响应body是否含Request Blocked、Cloudflare、Yunjiasu等厂商标识。若存在，跳过布尔盲注，改用时间盲注：id=1 AND IF(1=1,SLEEP(3),0)，通过响应延迟判断。
4.4 现象：扫描100个URL时，程序运行到第37个就卡住，CPU占用100%，JVM不抛异常
原因：PoolingHttpClientConnectionManager连接未释放。每次httpClient.execute()后必须调用EntityUtils.consume(entity)释放连接，否则连接池耗尽，后续请求无限等待。
解决：在SmartHttpClient.execute()方法末尾强制添加：
try { EntityUtils.consume(response.getEntity()); } catch (IOException ignored) {}这是Apache HttpClient的玄学规则——不手动consume，连接就不还给池子。
4.5 现象：生成的HTML报告中，中文显示为方块或乱码，但控制台日志中文正常
原因：Thymeleaf模板引擎默认用ISO-8859-1编码渲染，而HTML文件声明了UTF-8。
解决：在application.properties中添加：
spring.thymeleaf.encoding=UTF-8 spring.http.encoding.charset=UTF-8 spring.http.encoding.enabled=true并在HTML模板顶部显式声明：<meta charset="UTF-8">。缺一不可，否则浏览器按默认编码解析。
提示：以上问题均来自某高校信息安全课程设计的真实调试记录。建议在答辩前，用
curl -v http://localhost:8080/scan?target=https://testphp.vulnweb.com/手动触发一次扫描，盯着控制台日志看每一步的Cookie、响应码、Payload注入过程，比看10遍文档都管用。
5. 报告生成与结果可视化：结构化JSON+动态HTML双输出的设计逻辑
报告不是简单把结果print出来，而是分层交付：底层是机器可读的JSON，供后续集成；上层是人可读的HTML，带交互式详情展开。这种设计让答辩时既能演示“点击漏洞条目看原始请求/响应”，又能回答“如果要对接Jira，你们的JSON格式是否符合REST API规范”。
5.1 JSON报告结构：字段语义明确，兼容CI/CD流水线
ReportGenerator.generateJson(List<DetectionResult>)输出严格遵循以下schema：
{ "scan_time": "2024-06-15T14:22:33.123Z", "target": "https://testphp.vulnweb.com/", "total_targets": 42, "findings": [ { "vulnerability": "XSS", "severity": "HIGH", "location": "/search.php?q=test", "evidence": { "request": "GET /search.php?q=%3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E HTTP/1.1\r\nHost: testphp.vulnweb.com", "response_status": 200, "response_body_snippet": "<input type=\"text\" name=\"q\" value=\"<img src=x onerror=alert(1)>\">" }, "remediation": "对用户输入进行HTML实体编码，使用OWASP Java Encoder库" } ] }关键设计点：evidence.request是完整HTTP请求字符串（含headers），response_body_snippet截取匹配payload前后200字符，确保可追溯。severity字段按CVSS 3.1标准映射：XSS/SQLi为HIGH，路径遍历为MEDIUM。这样写，导师问“你们怎么定严重等级？”，答“参照CVSS官方向量，XSS默认AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H → 7.6分”，立刻显得专业。
5.2 HTML报告模板：Thymeleaf动态渲染与漏洞详情折叠面板
HTML报告用Thymeleaf渲染，核心是<div th:each="finding : ${report.findings}">循环。每个漏洞区块包含可点击展开的“原始请求/响应”面板：
<div class="vuln-card" th:each="finding : ${report.findings}"> <h3 th:text="${finding.vulnerability} + ' (' + ${finding.severity} + ')'"></h3> <p><strong>位置：</strong><span th:text="${finding.location}"></span></p> <p><strong>修复建议：</strong><span th:text="${finding.remediation}"></span></p> <!-- 折叠面板 --> <button class="toggle-btn">查看原始请求/响应</button> <div class="detail-panel" style="display:none;"> <h4>请求</h4> <pre><code class="http" th:text="${finding.evidence.request}"></code></pre> <h4>响应片段</h4> <pre><code class="html" th:text="${finding.evidence.response_body_snippet}"></code></pre> </div> </div> <script> document.querySelectorAll('.toggle-btn').forEach(btn => { btn.addEventListener('click', function() { const panel = this.nextElementSibling; panel.style.display = panel.style.display === 'none' ? 'block' : 'none'; }); }); </script>这个设计让答辩演示变得极其流畅：点开一个XSS条目，直接看到<img src=x onerror=alert(1)>如何被原样插入到<input value="...">中，再点“修复建议”看到OWASP Encoder的Maven依赖写法。没有PPT翻页，全是实时交互。
5.3 报告导出与离线分发：ZIP打包策略与资源引用规范
最终交付物是report-20240615-142233.zip，内含：
index.html（主报告，含所有CSS/JS内联，无需网络）report.json（原始数据）screenshots/目录（空，预留截图位置）README.md（说明如何用Chrome打开index.html）
关键约束：所有CSS/JS必须内联到HTML中，禁用外部CDN链接。因为答辩现场可能断网，<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css">会变空白页。我们用Maven插件frontend-maven-plugin在构建时下载Bootstrap CSS并内联：
<plugin> <groupId>com.github.eirslett</groupId> <artifactId>frontend-maven-plugin</artifactId> <version>1.12.1</version> <configuration> <installDirectory>target</installDirectory> </configuration> <executions> <execution> <id>install node and npm</id> <goals><goal>install-node-and-npm</goal></goals> <configuration><nodeVersion>v18.17.0</nodeVersion></configuration> </execution> <execution> <id>download bootstrap css</id> <goals><goal>npm</goal></goals> <configuration> <arguments>run download-bootstrap</arguments> </configuration> </execution> </executions> </plugin>package.json中download-bootstrap脚本用curl下载CSS并存入src/main/resources/static/css/，Thymeleaf模板再用<style th:inline="text">/*[[${#files.readAllBytes('static/css/bootstrap.min.css')}]]*/</style>内联。这套流程保证了“拷贝ZIP到U盘，插答辩电脑双击index.html就能看完整报告”。
6. 答辩实战技巧：三分钟讲清技术深度与两个必演Demo环节
答辩不是背稿，是现场证明你真的懂。我带过的某跨平台系统毕设，学生用这套方法拿了优秀——核心就三点：问题锚定、技术穿透、证据闭环。下面拆解具体怎么做。
6.1 开场三句话锚定问题价值（30秒）
不要说“随着互联网发展…”，直接切痛点：
“老师好，我做的不是一个能扫出‘存在XSS’的工具，而是解决三个真实卡点：第一，传统脚本扫不了带登录态的后台，我的协议层用HttpClient+CookieStore实现了Session自动同步；第二，XSS检测常误报，我的Detector按HTML/JS/ATTR上下文分级注入，每条报告都标注触发位置；第三，报告不能只给结论，我的HTML报告点开就能看原始请求和响应片段，修复建议直接给出OWASP Encoder的Maven依赖。”
这三句话覆盖了架构、算法、交付，且每句都带技术名词（CookieStore、上下文分级、OWASP Encoder），导师立刻知道你没抄。
6.2 必演Demo一：登录态扫描全流程（90秒）
提前准备好测试环境：
- 启动
testphp.vulnweb.com本地镜像（Docker run -d -p 8080:80 vulnerables/web-dvwa） - 在浏览器登录DVWA，拿到PHPSESSID Cookie
- 打开你的扫描器UI，输入
http://localhost:8080/vulnerabilities/xss_r/
演示步骤：
- 点击“添加Cookie”按钮，粘贴
PHPSESSID=xxxxxx（强调“不是自动抓包，是手动注入，因需验证Cookie有效性”） - 输入目标URL，点击扫描，观察控制台日志：
[INFO] Session cookie injected: PHPSESSID=xxxxxx - 等待完成，打开报告，点开一个XSS条目，展开“原始请求”，指出
Cookie: PHPSESSID=xxxxxx出现在请求头中 - 切换到浏览器DevTools Network，刷新
/vulnerabilities/xss_r/，对比Cookie头是否一致
这个Demo证明你理解Session机制，不是黑盒调用。
6.3 必演Demo二：XSS上下文定位与修复验证（90秒）
用testphp.vulnweb.com的搜索功能：
- 输入URL：
https://testphp.vulnweb.com/search.php?q=test - 扫描后，在报告中找到XSS条目，点开“原始响应片段”，定位到
<input type="text" name="q" value="test"> - 指出：“这里value属性是HTML属性上下文，所以我的Payload是
" onfocus="alert(1)" autofocus=""，不是<script>标签” - 打开IDE，打开
XssDetector.java，找到generatePayloadByContext("attr")方法，展示"\" onfocus=\"alert(1)\" autofocus=\"\""这一行 - 最后打开
README.md，指向“修复建议”章节，读出：“对输出到HTML属性的变量，使用StringEscapeUtils.escapeHtml4()编码”
这个Demo把“检测→定位→代码→修复”串成闭环，证明你不是调API，是真懂原理。
6.4 答辩问答预判表：高频问题与精准回答口径
| 导师可能问 | 你该怎么答（要点） | 避免踩坑 |
|---|---|---|
| “为什么不用Python写？Python生态更成熟” | “Java的强类型和线程模型更适合构建可维护的扫描器：Detector接口强制实现detect()方法，DetectionResult类约束返回字段，Maven多模块天然支持功能解耦。Python脚本难以做到这种工程级管控。” | 不说“Python不行”，说“Java更适合本项目目标” |
| “你们怎么处理CSRF Token？” | “目前不主动处理，因Token通常由前端JS动态生成。但TargetModel设计支持扩展：可在http-client模块增加TokenExtractor接口，从响应HTML中提取<input name='token' value='xxx'>，注入到后续请求。这是预留的扩展点。” | 不说“没做”，说“设计预留，可快速扩展” |
| “扫描速度太慢，怎么优化？” | “当前用5线程并发是平衡稳定性与速度的结果。若要提速，可：1）在SmartHttpClient中增大maxPerRoute至20；2）对静态资源URL（.css/.js）跳过XSS检测；3）用HttpResponseCache缓存304响应。这些都在config.properties中可配。” | 给出具体参数名和修改位置，不空谈“加缓存” |
从那以后我每次带学生做安全类毕设，都强制他们在答辩前三天，用真实靶场（如DVWA、WebGoat）跑通这两个Demo，并把控制台日志、报告截图、代码定位点整理成一页PDF打印出来——不是为了背，是为了形成肌肉记忆。当导师问“你这个XSS在哪触发的？”，你能脱口而出“在/xss_r/的input value属性里，Payload是onfocus事件”，而不是翻代码找半天。希望帮到你。
本文还有配套的精品资源，点击获取
