一个看起来人畜无害的洞危评论区输入框，能把你银行账户里的洞危钱转走。这不是洞危危言耸听。2018年，洞危某知名电商平台的洞危商品评价区被曝出存储型XSS漏洞，攻击者只要在评价里嵌入一段精心构造的洞危JavaScript代码，任何浏览该商品页面的洞危用户——包括卖家自己——都会在毫不知情的情况下，被脚本以他们的洞危身份执行转账、改密码、洞危甚至开通免密支付。洞危整个过程中，洞危受害者只是洞危“看了一眼页面”。
XSS（跨站脚本攻击）的洞危核心逻辑不复杂：攻击者把恶意脚本注入到网页里，让浏览器以为这段代码是洞危网站自己写的，于是洞危放心大胆地执行。浏览器给了脚本和网站同等的信任，这就等于把家门钥匙交给了伪装成家人的陌生人。而后果，远不止弹个窗那么简单。
最直接的危害是会话劫持。你的登录状态靠Cookie里的Session ID维持，脚本一旦能读取Cookie，攻击者拿着这个ID就能直接登录你的账号，不需要密码。很多网站给Cookie加了HttpOnly标记来防这一手，但并非所有站点都做。更麻烦的是，有些XSS甚至不需要偷Cookie——脚本直接在受害者的浏览器里发起请求，浏览器会自动带上Cookie，服务器根本分不清这是用户本人操作还是脚本在捣鬼。这叫CSRF配合XSS，杀伤力翻倍。
账号被登录之后呢？攻击者可以改你的绑定邮箱、换你的手机号、发钓鱼链接给你的好友、用你的身份发布违规内容。2014年Twitter上爆发的“鼠标悬停即转发”蠕虫，就是利用XSS让成千上万用户在浏览推文时自动转发恶意内容，传播速度以秒计算。你什么都没点，但你的账号已经替攻击者干了活。
再往深处走，XSS能直接掏空你的钱包。网上银行、支付平台、电商网站，只要存在XSS，攻击者就能在页面里伪造一个“请重新输入支付密码”的弹窗，你输入的东西直接发到攻击者服务器。页面URL是对的，HTTPS锁是绿的，你根本看不出区别。2017年某国内OTA平台被白帽子报告存在XSS，攻击者可以构造一个链接，用户点开后自动下单购买高价机票并删除订单记录，全程无感知。
企业这边也不好过。一个存储型XSS可能让整个后台管理系统沦陷。管理员登录后台查看用户反馈，反馈内容里藏着脚本，脚本读取管理员权限下的所有用户数据、修改配置、甚至上传WebShell拿到服务器权限。从XSS到RCE（远程代码执行），中间往往只隔着一个没做输出编码的“用户反馈”字段。
还有更隐蔽的玩法：XSS被用来挖矿。脚本在用户浏览器里跑门罗币挖矿代码，你电脑风扇狂转、电量狂掉，但页面看起来一切正常。或者用来做DDoS，脚本控制成千上万个浏览器同时向目标网站发请求，源IP是真实用户的，很难封禁。
移动端也没能幸免。很多App的内嵌WebView对XSS的防护比桌面浏览器更弱，甚至有些App的JS Bridge暴露了原生接口，XSS可以直接调用摄像头、读取通讯录、发送短信。你在App里看个帖子，后台可能已经在发付费短信了。
说到底，XSS的危害等级取决于它出现在哪里。一个个人博客的XSS，最多弹个窗恶心你一下；一个银行页面的XSS，能让你倾家荡产。而现实是，大量开发者仍然觉得“用户输入里能有什么坏心思”，输出的时候直接拼HTML，连最基本转义都不做。浏览器厂商在努力，CSP、Trusted Types这些机制都在推进，但网站自己不修，用户就只能靠运气。
我自己的习惯是：装个NoScript或者uBlock Origin，至少能拦住大部分反射型XSS。但存储型XSS防不住，因为脚本是从网站服务器发出来的，和正常内容混在一起。所以下次你在某个网站看到“请重新登录”的弹窗，先别急着输密码，看一眼地址栏，再想想这个网站上次让你登录是什么时候。多疑一点，没坏处。