脚本注入漏洞

去年冬天，脚本一个做电商的注入朋友半夜给我打电话，说网站首页突然跳出一行红色大字：“你的漏洞数据库已被锁，打钱。脚本”他以为是注入服务器被黑，折腾到凌晨三点才发现，漏洞问题出在一个商品评论框——有人没填评论，脚本填了一段JavaScript。注入

这就是漏洞脚本注入。说白了，脚本你写的注入代码把用户输入当成了“自己人”，结果用户输入里夹带了私货。漏洞浏览器分不清哪句是脚本你写的，哪句是注入别人塞进来的，照单全收，漏洞全当指令执行了。

它怎么进来的

最常见的入口是表单。搜索框、评论区、用户名、URL参数，任何一个能打字的地方都是潜在通道。比如一个搜索页面，地址栏里写着 ?q=手机，页面会把“手机”两个字显示出来。如果我把地址改成 ?q=<script>alert(1)</script>，而页面没做处理，那这段脚本就会在访问者的浏览器里跑起来。

跑起来能干什么？弹个窗只是最无害的演示。真正危险的是偷Cookie。很多网站的登录凭证就存在Cookie里，脚本一旦能读取，攻击者拿到之后可以直接冒充你的身份登录，连密码都不需要。

还有一种更隐蔽的玩法：注入一段脚本，悄悄把页面上的“收款账户”改成攻击者的账号。用户看着页面没任何异常，转账的时候钱就进了别人口袋。这类攻击叫页面篡改，受害者往往是网站的用户，而网站管理员可能几天都察觉不到。

为什么老有人中招

我翻过不少出问题的代码，根源几乎都一样：开发者默认“用户会好好填”。比如后端拿到评论内容，直接拼进HTML模板返回给前端，中间没有任何转义。转义的意思是把 < 变成 <，让浏览器知道“这是文本，不是标签”。但很多人嫌麻烦，或者根本不知道这回事。

另一个原因是前端渲染。现在大量页面靠JavaScript动态生成内容，如果用 innerHTML 往页面里塞用户数据，等于主动给脚本注入开门。innerHTML 会把字符串当HTML解析，里面藏个 <img src=x onerror=alert(1)> 照样执行。

有个细节值得注意：有些开发者做了前端过滤，把 <script> 关键词屏蔽掉，以为万事大吉。但攻击者可以用 <img onerror>、<svg onload>，甚至把字符编码换一换，绕过这种粗糙的过滤。过滤关键词这条路，基本走不通。

怎么防

核心原则就一条：永远不信任用户输入。具体做法分两层。

输出的时候做转义。用户提交的内容要显示在HTML里，就把特殊字符转成实体。不同上下文转义规则不一样，HTML里转 < > &，JavaScript里转引号和反斜杠，URL里做encode。用成熟的模板引擎，它们默认就帮你转义了，别自己手写拼接。

输入的时候做校验。比如用户名只允许字母数字下划线，邮箱按格式匹配，超出范围的直接拒绝。这不是为了防脚本注入本身，而是减少攻击面。

还有一条容易被忽略：给Cookie加 HttpOnly 标记。这样即使脚本注入成功了，JavaScript也读不到Cookie，偷不走登录凭证。再配合 Content-Security-Policy 响应头，限制页面只能加载指定来源的脚本，能挡住大部分注入执行。

我那个朋友后来把评论框的输出全做了转义，又给Cookie加了HttpOnly。他说早知如此，省下那三个小时能睡个好觉。脚本注入不新鲜，但每年还是有一堆网站栽在上面。不是技术太难，是太多人觉得“不会有人这么干”。

很赞哦!（33653）