xss漏洞挖掘

一个标签没闭合，洞挖就能让整个后台管理页面变成攻击者的洞挖提款机。这事发生在去年我参与的洞挖一次授权渗透测试里，目标是洞挖个老旧的电商系统，前端用jQuery，洞挖后端是洞挖PHP，连CSRF token都没做。洞挖我盯上传头像那个接口盯了半小时，洞挖文件名参数直接拼进HTML响应，洞挖没过滤。洞挖试了`">旁边的洞挖同事说“这站能拿shell”。我没理他，洞挖心里清楚，洞挖反射型XSS在这种场景下比RCE更致命——因为攻击目标不是服务器，是运营人员那台装着内部工具的电脑。

挖掘XSS的笨办法，就是往每个输入点塞特殊字符。但聪明点的做法，是先看数据流。参数进没进DOM，经过哪些函数，有没有转义。比如`innerHTML`赋值、`document.write`、`eval`、`location`跳转，这些是重灾区。我习惯用浏览器开发者工具直接改DOM，把输入值替换成`'">`，然后观察解析结果。如果看到``，不查`

存储型XSS是另一个量级。攻击者把payload写进数据库，每次用户访问都触发。挖这种洞要关注“内容展示”和“内容编辑”两个环节。比如评论区、昵称、签名档。我挖过一个论坛，昵称字段限制20字符，但过滤只挡了`<`和`>`，没挡`&`。我提交``被拦，改成`<img src=x onerror=alert(1)>`入库后，页面用`textContent`输出——安全。但管理后台的导出功能用`innerHTML`拼接，漏洞就藏在导出Excel的HTML模板里。这种跨功能点的数据流复用，才是挖掘的深水区。

DOM型XSS最阴险，因为服务端响应完全正常，payload只在客户端执行。挖这类漏洞，得把源码翻个底朝天。看那些用`location.hash`、`document.referrer`、`postMessage`接收数据的地方。去年挖某个单页应用，它的路由用`location.hash.slice(1)`做参数，然后直接拼进`angular.module`的模板缓存。我构造`#/profile/{ { constructor.constructor('alert(1)')()}}`，Angular表达式沙箱被绕，弹窗在Chrome上蹦出来。事后修复方案是改用`decodeURIComponent`加白名单校验，但当时那个开发小哥的表情，我到现在都记得。

工具只能辅助，别全信。Burp Suite的主动扫描对反射型XSS还行，但存储型和DOM型误报率太高。我习惯用自定义脚本配合浏览器插件，比如用Tampermonkey写个脚本，自动往所有输入框填`'">

最后说点实在的。挖XSS不是比谁payload花哨，是比谁更懂浏览器的解析机制。HTML实体、URL编码、Unicode归一化，这些细节都能成为突破口。我最近碰到一个案例，输入`%26lt;script%26gt;`被后端解码成`<script>`，再被前端`textContent`输出——安全。但同一个输入，如果经过两次URL解码，就变成`