检测XSS漏洞代码

XSS检测不是检测扫一遍正则就完事。我见过太多团队拿着工具跑一圈，洞代输出“未发现漏洞”，检测然后上线当天就被黑。洞代问题出在哪儿？检测他们把“检测”当成了“验证”，把“代码审计”简化成了“字符串匹配”。洞代

真正的检测XSS检测得从输入点开始。你写了个搜索框，洞代用户输入``，检测后端把它原样塞进HTML返回——这就是洞代反射型XSS。但更隐蔽的检测是存储型：用户把恶意脚本存进数据库，其他用户打开页面时触发。洞代比如论坛签名档，检测你存个``，洞代每次有人看你的检测帖子，cookie就被偷一次。检测代码时，先画数据流图：用户输入从哪进来？经过哪些函数？最后拼接进哪个HTML上下文？

我习惯写个最小验证脚本。不是用现成扫描器，而是自己构造payload。比如对参数`?name=test`，先试`?name=test" onmouseover="alert(1)`，再试`?name=test'>

有个坑很多人踩：只测GET参数，忽略POST请求。登录表单、评论提交、文件上传接口，全是POST。你拿Burp Suite改包，把`Content-Type`改成`application/json`，在JSON字段里塞payload。我上次测一个API，`{ "content":""}`，后端直接把它反射到管理后台的列表页——存储型XSS，影响所有管理员账号。检测代码时，别只盯前端页面，API接口的响应体也要看。

再说说DOM型XSS。这种不经过后端，纯前端JS操作。比如`location.hash`的值被直接赋给`innerHTML`。检测代码得追JS源码，看`document.write`、`eval`、`setTimeout`这类危险函数。我遇到过一个案例：前端用`URLSearchParams`解析query参数，然后拼进`chart`库的配置里。攻击者构造`?callback=alert(1)//`，库内部用`new Function(callback)`执行——直接RCE。这种漏洞，静态扫描器很难发现，得靠人工审代码流。

写检测脚本时，我常用两个技巧。第一，用`headless`浏览器模拟点击，触发所有事件处理器。普通HTTP响应看不出问题，但浏览器解析后DOM会变。比如``，服务端返回的HTML里没有脚本标签，但浏览器加载时会执行onerror。第二，对输出点做上下文感知。同样是``、`">`、`