简介这是一份面向信息安全专业课程设计场景的Java XSS漏洞检测系统完整项目源码适合高校学生、安全方向初学者用于学习跨站脚本攻击的原理与检测防御实现。压缩包共426个文件约3.19MB包含214张png界面截图、118张gif操作演示、JSP/HTML页面、Java类与class文件以及css/js/xml等Web工程配套文件结构上兼顾源码、界面资源与演示素材便于对照理解前端展示和后端检测流程。已有88人学习下载。通过该项目可了解输入过滤、危险字符识别、攻击规则匹配等检测机制掌握从项目搭建、规则配置到检测结果展示的完整设计思路同时也可作为课程设计报告撰写和答辩演示的实战参考。1. XSS漏洞检测系统到底是什么为什么多数扫描器报告不可直接用把一套Java Web应用丢给通用扫描器报告里列出三四十个“反射型XSS”人工复核下来真正能利用的不到一半另外一半要么是响应页面自包含payload字符要么是框架统一做了HTML实体转义但扫描器没识别。这是XSS检测最常见的状态探测请求能发出去payload能触发回显但“回显”和“可利用”之间差了很远。基于Java的XSS漏洞检测系统解决的不是“发一堆payload看响应当中出现什么”而是把注入点识别、payload变体构造、回显上下文判定、可利用性评级串成一条可复现的流水线。它面向三类人需要在发布前做自测的Java开发、需要给漏洞报告附证据链的安全测试工程师、以及想把手动验证XSS的过程固化成自动化用例的运维人员。这套系统的核心价值在于——判漏洞讲证据不靠关键词命中。2. 检测判定链路回显命中、上下文识别与误报边界2.1 XSS检测判定的不是“有没有回显”而是“回显在哪个解析上下文”XSS能否被利用取决于用户可控数据最终落在HTML解析器的哪个位置。同样是字符串scriptalert(1)/script出现在div标签内容里浏览器会当作标签解析这是高危出现在input value...的属性值里需要先闭合引号才能逃逸出现在某个经过HtmlUtils.htmlEscape()处理后的区域尖括号已经被转成lt;浏览器只会把它当作纯文本。因此检测系统必须对每个回显点做上下文分类而不是简单匹配字符串是否存在。我把回显位置按解析上下文分成四类这个分类直接影响后续的判定逻辑上下文类型典型位置逃逸难度检测侧含义RAW_HTMLdiv、p等标签内容低直接注入标签即可payload原样出现在标签内容区判高危ATTR_QUOTEvalue...、src...等属性值中需要闭合引号payload闭合引号后能逃逸判中高危SCRIPTscript代码块、js变量赋值中高需要闭合引号或括号payload能打破js字符串边界判高危EVENT_HANDLERonclick...、onerror...中高需要闭合引号并注入事件payload注入到事件属性判高危检测器拿到响应体后先用正则或HTML解析器定位payload出现的位置然后取该位置前后各一段字符做上下文分析。比如前面是value后面是那当前上下文就是ATTR_QUOTE此时一个scriptalert(1)/script变体就比裸的script标签更有可能被利用。这个“前后各取N个字符”的操作同时也是后面生成证据链的基础我会在最后一章详细展开。2.2 四种检测结果状态不能把所有命中都算漏洞设计检测结果数据结构时我给每条记录定义四个状态这是我从手动验证经验里总结出的最小分类能直接覆盖扫描器产生的绝大多数判定EXPLOITABLEpayload在响应中成功逃逸当前上下文具备实际利用条件需要人工最终确认ECHO_ONLYpayload字符串原样出现在响应中但未逃逸上下文例如被HTML实体转义后显示为lt;scriptgt;浏览器按文本渲染FILTEREDpayload被输入侧过滤回显中内容被删改比如script变成script或空字符串NO_ECHOpayload完全未出现在响应中判定时不能只依赖响应体包含payload字符串这一个条件。常见误报就是把ECHO_ONLY当成EXPLOITABLE。Java框架中Spring Boot默认不会全局转义输出但Thymeleaf模板引擎会自动转义${}表达式这两种情况在响应体里的表现完全不同检测系统需要针对不同框架特征做细化。一个简单但有效的策略是检测器维护一个“编码特征库”识别响应上下文后先做一次逆解码HTML实体解码、URL解码逆解码后如果payload从ECHO_ONLY变成了可执行的HTML标签形态状态升为EXPLOITABLE否则维持原判。2.3 最小判定实现上下文感知的命中分析下面给出一个最小可用的Java判定方法输入是响应体、payload和payload在响应中的位置索引输出是检测状态。这个方法是整个检测系统判定模块的核心它不做复杂的机器学习只利用位置前后的字符特征做规则判断。public DetectionResult analyzeContext(String responseBody, String payload, int hitIndex) { if (hitIndex 0) { return new DetectionResult(DetectionStatus.NO_ECHO, , ); } // 提取payload前后各50个字符作为上下文证据 int start Math.max(0, hitIndex - 50); int end Math.min(responseBody.length(), hitIndex payload.length() 50); String context responseBody.substring(start, end); String prefix context.substring(0, Math.min(20, context.length())); String suffix context.substring(Math.max(0, context.length() - 20)); // 逆解码先做HTML实体解码如果解码后payload出现形态变化则标记 String decoded StringEscapeUtils.unescapeHtml4(responseBody); boolean htmlEncoded !decoded.equals(responseBody) decoded.contains(payload.replace(, lt;).replace(, gt;)); String rawPayloadInContext extractRawPayload(context, payload); boolean attrQuoteBreak prefix.contains(\) || prefix.contains() || suffix.contains(\) || suffix.contains(); boolean scriptContext prefix.contains(script) || suffix.contains(/script); boolean eventContext prefix.matches(.*(on\\w\\s*\\s*[\]?)$); if (rawPayloadInContext.contains(script) !htmlEncoded) { return new DetectionResult(DetectionStatus.EXPLOITABLE, context, RAW_HTML); } if (attrQuoteBreak rawPayloadInContext.contains()) { return new DetectionResult(DetectionStatus.EXPLOITABLE, context, ATTR_QUOTE); } if (scriptContext (rawPayloadInContext.contains(;) || rawPayloadInContext.contains(/scri))) { return new DetectionResult(DetectionStatus.EXPLOITABLE, context, SCRIPT); } if (eventContext rawPayloadInContext.contains(;)) { return new DetectionResult(DetectionStatus.EXPLOITABLE, context, EVENT_HANDLER); } if (rawPayloadInContext.equals(payload) htmlEncoded) { return new DetectionResult(DetectionStatus.ECHO_ONLY, context, HTML_ENCODED); } return new DetectionResult(DetectionStatus.ECHO_ONLY, context, UNKNOWN_CONTEXT); }逻辑说明analyzeContext方法先通过hitIndex确认payload是否回显再分别取前缀和后缀判断解析上下文。attrQuoteBreak检查属性值引号是否闭合scriptContext检查是否处于script块内eventContext通过正则匹配onclick等事件属性。htmlEncoded标志位用于区分“原样执行”和“被转义后显示”这是消除误报的关键。参数说明context截取长度50是经验值太短会丢失上下文特征太长会让证据片段冗长正则.*(on\\w\\s*\\s*[\]?)$只匹配属性名和等号不匹配具体事件内容避免过度匹配。3. 用Maven和HttpClient搭出检测系统底座请求模块与最小运行工程3.1 工程目录怎么组织源码包里的常见分工基于Java的XSS检测系统源码包解压后通常是一个Maven工程。工程拆成四个模块能兼顾测试和后续扩展core放判定逻辑scanner放扫描编排http放请求发送report放结果输出。我一般推荐按包名区分而不是拆成多个Maven module因为XSS检测系统的核心流程不算长拆模块过多反而增加构建成本。xss-detector/ ├── pom.xml ├── src/main/java/com/example/xssdetector/ │ ├── core/ # 判定逻辑上下文分析、编码逆变换 │ ├── scanner/ # 扫描编排爬取入口、注入点提取、payload调度 │ ├── http/ # HTTP客户端封装连接管理、Cookie策略、重试 │ └── report/ # 结果输出控制台、JSON文件、Markdown报告 ├── src/main/resources/ │ └── payloads.txt # payload变体库按上下文类型分组 └── src/test/java/ # 单元测试用本地模拟HTTP服务做回归这种分层的意义在于扫描编排和判定逻辑解耦后后续接新的payload来源从文件、API或代码扫描结果导入都不需要动判定代码。resources目录下的payloads.txt按行维护payload每行格式是上下文类型\tpayload内容例如RAW_HTML\tscriptalert(1)/script这样不同上下文可以加载不同的payload子集减少无效请求。3.2 pom.xml和HttpClient封装正确配置连接和CookieHTTP请求模块是整个检测系统的地基承担发送探测请求、维持会话、处理重定向三个职责。现代XSS检测强烈依赖会话维持因为存储型XSS往往需要登录态Cookie丢失会让大半检测结果失效。dependency groupIdorg.apache.httpcomponents.client5/groupId artifactIdhttpclient5/artifactId version5.3.1/version /dependency dependency groupIdorg.jsoup/groupId artifactIdjsoup/artifactId version1.17.2/version /dependency dependency groupIdcommons-codec/groupId artifactIdcommons-codec/artifactId version1.16.0/version /dependencyHttpClient 5.x的API和4.x差异较大核心区别是CloseableHttpClient换成try-with-resources管理请求构造使用HttpRequest的builder模式。下面是一个封装了会话保持和重试的请求发送器public class RequestSender { private final CloseableHttpClient httpClient; private final BasicCookieStore cookieStore new BasicCookieStore(); public RequestSender(int maxConnections, int connectTimeoutMs, int readTimeoutMs) { // 连接池配置maxConnections控制并发上限每个路由最多分配一半 PoolingHttpClientConnectionManager connManager PoolingHttpClientConnectionManagerBuilder.create() .setMaxConnTotal(maxConnections) .setMaxConnPerRoute(maxConnections / 2) .build(); // 请求配置连接超时、响应超时、重定向策略分开设置 RequestConfig config RequestConfig.custom() .setConnectTimeout(connectTimeoutMs, TimeUnit.MILLISECONDS) .setResponseTimeout(readTimeoutMs, TimeUnit.MILLISECONDS) .setRedirectsEnabled(true) .setMaxRedirects(5) .build(); // 重试策略连接失败才重试不做幂等重试避免重复提交造成脏数据 HttpRequestRetryStrategy retryStrategy new DefaultHttpRequestRetryStrategy( 2, TimeUnit.SECONDS, // 最多重试2次间隔1秒 RetryCondition.UNSAFE); this.httpClient HttpClients.custom() .setConnectionManager(connManager) .setDefaultRequestConfig(config) .setDefaultCookieStore(cookieStore) .setRetryStrategy(retryStrategy) .build(); } public HttpResponse send(String url, MapString, String params, boolean followRedirect) { // 构造GET请求参数拼接到URL后面同时记录带参数的完整URL URIBuilder uriBuilder new URIBuilder(url); for (Map.EntryString, String entry : params.entrySet()) { uriBuilder.addParameter(entry.getKey(), entry.getValue()); } ClassicHttpRequest request ClassicRequestBuilder.get(uriBuilder.build()).build(); try { return httpClient.execute(request, response - { String body new String(response.getEntity().getContent().readAllBytes(), StandardCharsets.UTF_8); return new HttpResponse(response.getCode(), body, response.getHeader(Content-Type)); }); } catch (IOException e) { return new HttpResponse(0, , ); // 返回空响应上层根据状态码判定失败 } } }参数说明maxConnections建议设置在10到30之间过大容易触发目标WAF的访问频率限制过小则扫描速度太慢setMaxConnPerRoute(maxConnections / 2)避免热点URL占满连接池。setRedirectsEnabled(true)对反射型XSS检测不是必需的但对存储型XSS检测很关键因为很多登录接口遵循POST后302跳转的模式。RetryCondition.UNSAFE表示POST请求不自动重试因为重试会让评论、留言这类数据重复提交污染后续逻辑。3.3 最小运行命令与日志观察工程构建用Maven即可打包时指定maven-shade-plugin把依赖打成一个可执行jar方便在服务器上直接运行。命令行参数设计成三要素目标URL、payload文件路径、输出格式。mvn clean package -DskipTests java -jar xss-detector.jar --url http://localhost:8080/search --param keyword --payload-file payloads.txt --format console参数说明--url和--param定位一个注入点--payload-file指定变体库--format console表示控制台输出调试时最快。执行后控制台会按状态 | 上下文类型 | 参数 | payload摘要 | 回显片段打印EXPLOITABLE状态会用高亮色标记。第一次跑通不要急着接大量URL先拿单个注入点验证请求发送、回显匹配、状态判定这条链路是否通。如果返回的响应全是HTTP 0先排查目标站点是否做了TLS证书校验或IP白名单HttpClient默认信任全部证书需要额外的SSL配置才能访问自签名HTTPS站点。4. 三类XSS的Java检测实现反射型、存储型、DOM型各走各的流程4.1 反射型XSS检测单请求单响应遍历注入参数反射型XSS的检测流程最简单把payload放到URL参数或表单字段中发送检查响应是否原样或变体回显再按第二章的上下文判定逻辑分类。它的特点是“一次请求就能完成验证”不需要会话编排因此也最适合做并发压测。实现时要注意两个容易出错的细节。第一payload放入参数后要做URL编码否则script里的和在键值对解析时会被吃掉URIBuilder.addParameter()会自动编码所以走封装好的send()方法就没有这个问题。第二一个页面往往有多个参数每个参数都需要单独测试不能把payload平均塞到所有参数里那样即使触发也不知道是哪个参数起的作用。public ListResult scanReflected(String url, ListString params, ListString payloads) { ListResult results new ArrayList(); for (String param : params) { for (String payload : payloads) { MapString, String query new HashMap(); query.put(param, payload); HttpResponse resp sender.send(url, query, true); if (resp.statusCode() 200 !resp.body().isEmpty()) { int idx findPayloadIndex(resp.body(), payload); if (idx 0) { DetectionResult dr analyzer.analyzeContext(resp.body(), payload, idx); results.add(new Result(url, param, payload, resp.body(), dr)); } } } } return results; }findPayloadIndex不能直接使用responseBody.indexOf(payload)因为响应里的payload可能经过编码转换比如变成lt;。所以要先把payload做几个常见编码形态HTML实体、URL编码、unicode的预变换再逐个执行indexOf找到最大的索引位置作为命中点。这个方法的思路是“先找编码后形态再找原始形态”因为响应中如果两处都出现payload编码后的位置更能说明上下文转义情况。4.2 存储型XSS检测登录态、表单提交、二次请求三步编排存储型XSS检测的复杂度比反射型高一个量级因为它需要完整的业务链路登录获取会话、访问目标功能页、填写表单提交、再触发一次页面渲染来验证payload是否被持久化并带出。这个过程里最常见的坑是会话丢失和提交后跳转导致的验证遗漏。存储型检测的编排流程我用一个带状态的扫描序列来实现public void scanStored(String loginUrl, String username, String password, String targetUrl, MapString, String formData, String payload) { // 第一步登录并维持Cookie MapString, String loginParams new HashMap(); loginParams.put(username, username); loginParams.put(password, password); sender.send(loginUrl, loginParams, true); // CookieStore自动记录会话 // 第二步表单提交payload formData.put(content, payload); HttpResponse submitResp sender.send(targetUrl, formData, true); if (submitResp.statusCode() ! 200 submitResp.statusCode() ! 302) { log.warn(表单提交异常状态码: {}, submitResp.statusCode()); return; } // 第三步二次请求目标页面验证payload是否被带出 HttpResponse verifyResp sender.send(targetUrl, Collections.emptyMap(), true); int idx verifyResp.body().indexOf(payload); if (idx 0) { DetectionResult dr analyzer.analyzeContext(verifyResp.body(), payload, idx); recordStoredResult(targetUrl, payload, dr); } else { // 如果第一次没找到可能被编码或pagination分页尝试再请求一次 HttpResponse retryResp sender.send(targetUrl ?page1, Collections.emptyMap(), true); // 递归调用一次验证逻辑限制重试次数为2 } }逻辑说明loginUrl、targetUrl需要从配置中读取因为不同应用的登录接口形态差异巨大没有统一规则。sender.send()内部维持同一个BasicCookieStore所以登录后的会话在后续请求中天然生效这是把CookieStore放在RequestSender成员变量里的原因。存储型检测对表单类型的依赖很强formData里content字段是payload注入点但实际项目里一个页面可能有标题、正文、标签等多个可输入字段需要为每个可输入字段单独循环执行一次scanStored。4.3 DOM型XSS检测用HtmlUnit执行JS后再验证DOM型XSS和反射型、存储型的根本区别在于payload可能从未出现在服务器响应中而是在浏览器本地通过document.write、innerHTML、location.hash等API被动态写入DOM。服务端请求响应里看不到任何payload痕迹所以必须引入无头浏览器或JS引擎来执行页面脚本。Java方案里最可靠的落地手段是HtmlUnit它内置了Rhino JS引擎可以模拟浏览器执行JavaScript并操作DOM。使用HtmlUnit执行DOM检测的流程是加载目标URL注入payload到URL的fragment或query参数等待JS执行完毕然后遍历DOM树检查payload是否被写入到可执行位置。public void scanDom(String url, String param, String payload) throws IOException { try (WebClient webClient new WebClient(BrowserVersion.CHROME)) { // 禁用CSS加载和外部资源加载只执行JS提升扫描速度 webClient.getOptions().setCssEnabled(false); webClient.getOptions().setThrowExceptionOnScriptError(false); webClient.getOptions().setTimeout(10000); // 构造带payload的URLpayload放在参数或片段中 String targetUrl url ? param URLEncoder.encode(payload, StandardCharsets.UTF_8); HtmlPage page webClient.getPage(targetUrl); webClient.waitForBackgroundJavaScript(2000); // 等待异步JS执行 // 在DOM中搜索payload String pageHtml page.asXml(); if (pageHtml.contains(payload)) { ListHtmlElement elements page.getElementsByTagName(script); for (HtmlElement el : elements) { if (el.getTextContent().contains(payload)) { log.info(DOM XSS 命中: {}位置: script标签内, targetUrl); } } } // 检查alert是否被调用通过注册一个hook来捕获 page.executeJavaScript(window.__xssDetected true;); } }参数说明setCssEnabled(false)关闭CSS加载因为CSS对DOM XSS判定无影响但耗时明显setThrowExceptionOnScriptError(false)让某些报错的页面JS不阻断检测流程waitForBackgroundJavaScript(2000)等待异步脚本执行具体值可以根据目标站点的JS复杂度调整从500ms到5000ms不等。HtmlUnit的局限是它不执行ES6的高级语法对用现代框架Vue、React构建的站点需要改用Selenium或PlayBrowser的方案但这类站点的DOM XSS检测复杂度已经超出“检测系统”范畴通常需要结合浏览器插件手动验证。5. 检测结果的验真与变体覆盖从裸payload到编码形态集合5.1 变体库为什么不能只有一条payload实际业务系统中的XSS检测难点往往不在判定算法而在payload覆盖率。应用层可能有输入长度限制、黑名单过滤、WAF规则拦截一条scriptalert(1)/script根本无法触达回显点。检测系统需要为每个上下文类型准备一组变体变体的核心思路是“语义等价、形态不同”。上下文基础payload变体思路变体示例RAW_HTMLscriptalert(1)/scriptSVG标签替代scriptsvg onloadalert(1)ATTR_QUOTEscriptalert(1)/script事件属性优先于标签 autofocus onfocusalert(1) xSCRIPT;alert(1);//注释吃掉尾部单引号;alert(1)//EVENT_HANDLERimg srcx onerroralert(1)无引号形态? autofocus onfocusalert(1)编码绕过script大小写混合实体编码sCrIpT#97;lert(1)/sCrIpT变体库的构建不宜贪多每个上下文维护5到8个代表性变体就够了。真正有效的做法是“按目标框架定向生成”应用是JSPEL表达式就生成${7*7}这类EL注入payload应用是Spring BootThymeleaf就覆盖th:utext的属性逃逸变体。通用扫描器覆盖不了这些而这种定向变体恰恰是自建检测系统的价值所在。5.2 误报消解用靶场做一轮回归校准检测系统开发完成后要先在靶场上校准判定逻辑再上真实系统。推荐的校准靶场是DVWA和CTFHub的XSS模块原因有两个靶场环境在本地可控payload可以随意测试不担心污染数据靶场的题目覆盖了反射型、存储型、DOM型三类每种题型的回显特征都是标准化的非常适合用来验证判定算法的准确率。校准方法很简单对每个靶场题目用检测系统发起全量payload扫描把检测结果和题目标准答案比对。重点看两类错误漏报靶场确认有漏洞但检测系统判为NO_ECHO和误报检测系统判为EXPLOITABLE但靶场实际没漏洞。漏报通常是payload库覆盖不足误报几乎都来自上下文判定逻辑过于宽松特别是eventContext的正则匹配范围太大把属性名包含on的情况也算进去了。5.3 验证脚本一条命令跑完三个靶场用例把校准过程固化成脚本能保证后续每次修改判定逻辑后都做一次回归。我用一个极简的Javamain方法把这些验证串起来java -jar xss-detector.jar --self-test--self-test参数触发内置测试流程依次向本地靶场URL发送payload然后断言预期状态。下面贴出关键断言逻辑它会在每次构建时执行保证判定改动不会引入新的回归Test public void testReflectedVectorDetection() { // 本地模拟一个反射点: http://localhost:9000/echo?qscriptalert(1)/script // 响应体为 htmlbodydivyour input: scriptalert(1)/script/div/body/html String response htmlbodydivyour input: scriptalert(1)/script/div/body/html; int hitIndex response.indexOf(scriptalert(1)/script); DetectionResult result analyzer.analyzeContext(response, scriptalert(1)/script, hitIndex); assertEquals(DetectionStatus.EXPLOITABLE, result.status()); assertEquals(RAW_HTML, result.contextType()); }断言失败时Maven构建会中断日志里会输出判定状态和上下文类型方便定位是payload形态变了还是上下文识别逻辑错误。这个测试同时验证了analyzeContext和payload索引查找两个关键方法是整套系统里性价比最高的单测。6. 让检测报告能进工单证据片段、上下文标签和回归基线检测系统产出不能只是一堆“存在漏洞”的结论交付给开发修复时需要三个信息payload是什么、payload在响应中出现在哪里、为什么判定为可利用。完善的报告模块输出每条结果的证据片段包括请求URL、注入参数、payload、回显上下文前后各50字符、判定状态。开发拿这个报告直接能在浏览器里复现不需要重新构造请求。实现上我用一个简单的Evidence类管理证据链配合Freemarker模板生成可直接阅读的HTML报告。public record Evidence(String url, String param, String payload, String contextBefore, String contextAfter, String status, String contextType) { public String contextFragment() { // 拼接证据片段前后各保留40字符中间payload用【】包裹 return contextBefore.substring(Math.max(0, contextBefore.length() - 40)) 【 payload 】 contextAfter.substring(0, Math.min(40, contextAfter.length())); } }报告按EXPLOITABLE、ECHO_ONLY分组展示EXPLOITABLE条目附带contextFragment()生成的证据字符串。修复合入基线前CI里跑一次增量扫描状态全为NO_ECHO才算通过。这个“证据驱动修复”的流程比给开发一个痛点难以定位的扫描报告要高效得多。回归基线建议用配置文件维护每次全量扫描后自动对比上一次基线新增的EXPLOITABLE记录会阻断提交并触发通知这样XSS检测系统就从一次性工具变成了可持续跟进的安全门禁真正嵌进交付流程里。本文还有配套的精品资源点击获取
