内容摘要：XSS漏洞的核心就一句话：用户输入被当成代码执行了。找XSS，本质上就是在找“哪些地方把我的输入原样吐回页面，并且浏览器会把它当HTML或JS跑起来”。 先看一个最典型的例子。某电商搜索框，你输入 &

XSS漏洞的洞找核心就一句话：用户输入被当成代码执行了。找XSS，洞找本质上就是洞找在找“哪些地方把我的输入原样吐回页面，并且浏览器会把它当HTML或JS跑起来”。洞找

先看一个最典型的洞找例子。某电商搜索框，洞找你输入 <script>alert(1)</script>，洞找点搜索，洞找页面直接弹窗。洞找这说明搜索关键词被拼接到结果页的洞找HTML里，没做任何转义。洞找这种反射型XSS最好找，洞找因为输入和输出在同一个请求-响应周期里，洞找肉眼就能验证。洞找

但现实里没这么直白。洞找更多时候，你输入的东西会被塞进value属性、href、onclick，或者JSON里再被JS取出来塞进innerHTML。这时候直接打<script>可能不弹，因为标签被过滤了，或者上下文不对。你得换payload。比如输入点在<input value="这里">，那就用" onmouseover="alert(1)，把双引号闭合掉，再挂个事件。输入点在<script>var a='这里'</script>，那就用';alert(1)//。输入点在href里，javascript:alert(1)可能就够。找XSS的过程，八成时间花在判断“我的输入到底落在HTML的哪个位置”。

怎么判断？手动测。在输入框里填一串特殊字符，比如"'><(){ }[]，提交后看返回的HTML源码。搜索这串字符，看它出现在哪。被转义成"、<了？那基本没戏。原样躺着？有戏。如果出现在JS变量里，注意看引号有没有被转义。如果出现在innerHTML的赋值里，即使<script>不执行，<img src=x onerror=alert(1)>也能弹。

存储型XSS更值得挖。留言板、用户昵称、商品评论、个人签名——这些地方你提交一次，所有访问该页面的用户都会中招。找法和反射型一样，只是输入点和输出点不在同一个请求里。比如你在个人资料里把昵称改成<svg onload=alert(1)>，保存，然后访问自己的主页。如果弹了，而且别人访问你主页也弹，那就是存储型。这种漏洞危害大，因为不需要诱导点击，打开页面就触发。

DOM型XSS容易被忽略。它不经过服务器，纯前端JS把不可信数据写进危险函数。比如location.hash被document.write输出，或者eval了location.search里的参数。你改URL的#后面部分，页面就执行了。这种漏洞在源码里搜innerHTML、document.write、eval、setTimeout、location这些关键词，顺藤摸瓜看数据来源可不可控。

工具能帮忙，但别全信。Burp Suite的扫描器、XSStrike、dalfox，跑一遍能筛出不少。可它们经常漏掉需要交互的、上下文复杂的、或者过滤了某些字符但绕得过去的。我见过一个站，扫描器报无XSS，手动在输入里加了个%0a换行，把过滤规则绕过去了，弹窗。工具不知道你的业务逻辑，也不知道哪个参数会被前端JS二次处理。

还有个笨办法但有效：把每个输入点都当成嫌疑犯。URL参数、表单字段、HTTP头（Referer、User-Agent偶尔会被记录并展示）、Cookie、甚至上传的文件名。输出点呢？页面HTML、JS变量、CSS、XML、JSON响应。两边一交叉，就是测试用例。别嫌烦，XSS找起来就是个体力活加细心活。一个参数一个参数试，一个上下文一个上下文换payload。弹窗那一刻，前面的枯燥都值了。

最后说个观察：很多开发觉得“我用了框架就安全了”。React默认转义，Vue的v-html才危险，Angular有DomSanitizer。但框架不是万能药。有人用React，却在dangerouslySetInnerHTML里塞了用户输入；有人用Vue，v-html绑定了评论内容。框架只保证默认安全，你主动绕开它，漏洞就来了。找XSS，先看开发有没有“主动绕开”。