打开DVWA的洞检XSS模块，输入<script>alert(1)</script>，测工页面弹窗了。洞检这说明后端根本没做过滤，测工用户输入原样输出到了HTML里。洞检就这么简单，测工一个反射型XSS确认了。洞检很多人把XSS检测想得太复杂，测工其实核心就一句话：找到所有用户可控的洞检输入点，逐个测试特殊字符是测工否被原样输出。

但真正干活的洞检时候，麻烦在于输入点太多了。测工URL参数、洞检表单字段、测工HTTP头、洞检Cookie、甚至上传的文件名，每一个都可能是入口。我习惯先用Burp Suite的Proxy把整个站点的请求抓一遍，然后丢进Scanner跑一轮。Burp能自动标记出疑似反射点，但它有个毛病——误报率高。它说存在XSS的地方，你手动验证一下，十次里有三次是假的。原因是Burp的payload太规则了，有些WAF专门针对它的特征库做了拦截，返回的页面看起来像反射但实际被转义了。

所以手动测试还是绕不开。我的做法是给每个参数喂一组探测字符串，比如zzx<>"'&这种。然后在响应里搜zzx，看它周围是什么情况。如果尖括号被转成了<>，说明做了HTML实体编码，基本没戏。如果引号没被处理，那就要看它落在HTML的什么位置——在属性值里还是在标签之间，利用方式完全不同。

说到工具，开源方案里XSStrike算是比较能打的。它不光做反射检测，还会分析上下文，自动生成绕过WAF的payload。我拿它测过一个装了ModSecurity的站点，Burp的payload全被拦了，XSStrike换了大小写混合加注释符的写法，居然绕过去了。不过这工具有个坑，它的爬虫模块对SPA站点基本没用，前端路由一多就爬不到有效链接。这时候得配合手动喂URL，或者用--seeds参数指定入口。

DOM型XSS更隐蔽。服务端返回的HTML里干干净净，没有任何用户输入的回显。但前端JS里有一句document.getElementById('x').innerHTML = location.hash.slice(1)，漏洞就出在这。检测这种得看JS源码，找innerHTML、document.write、eval这些危险函数。浏览器插件像DOM Invader能帮上忙，它会在你操作页面时实时监控数据流，看有没有不可信数据进入危险汇聚点。

有个真实案例我印象很深。某电商站的搜索框，输入<img src=x onerror=alert(1)>没反应，输入<script>alert(1)</script>也没反应。但输入" onmouseover="alert(1)，页面结构变了。原来搜索词被拼进了<input value="搜索词">里，尖括号被过滤了，但双引号没处理。构造闭合就能注入事件属性。这种场景Burp的Scanner大概率漏报，因为它默认payload里尖括号居多，对属性闭合的检测不够敏感。

自动化工具能覆盖六成左右的常见场景，剩下的四成得靠人。我的习惯是先用工具扫一遍拿个底，然后对着每个参数手动过一遍上下文。时间花得多，但漏报少。XSS这东西，一个弹窗背后可能是Cookie窃取、会话劫持、甚至键盘记录。检测的时候多花十分钟，比事后擦屁股强。