css漏洞

2017年，安全研究者Sebastian Lekies在Twitter上发了一条推文，配图是一段CSS代码。这段代码只有三行，却能让攻击者读取用户浏览器里的密码。不是JavaScript，不是XSS，就是CSS。很多人当时的第一反应是"这不可能"——CSS不是只管颜色和排版吗？

问题出在CSS选择器上。属性选择器 input[value^="a"] 可以匹配value以"a"开头的输入框。配合 background: url(...)，浏览器会向外部服务器发起请求。攻击者把这两个东西拼在一起，就得到了一个逐字符提取敏感信息的侧信道。密码框里的值虽然不会渲染到页面上，但属性选择器依然能匹配到DOM属性——而很多框架会把值同步到属性里。一次匹配一个字符，几十次请求之后，密码就到手了。整个过程没有一行JavaScript执行。

CSS注入的入口比想象中多

2019年，GitHub上爆出一个CSS注入漏洞。攻击者可以在Markdown文件里嵌入 <style> 标签，而GitHub的渲染管道没有过滤掉它。这意味着任何人在issue或README里写一段CSS，就能影响页面上其他元素的样式。听起来危害有限？配合属性选择器，攻击者可以在页面里放一个隐藏的输入框，诱导用户输入，然后逐字符窃取。GitHub后来修复了这个漏洞，但同类问题在其他平台反复出现。

Mastodon在2022年也修过一个类似的。用户可以在个人资料里注入CSS，影响其他用户查看自己主页时的页面渲染。攻击者用 position: fixed 覆盖整个视口，再画一个假的登录框，用户根本分不清这是Mastodon的界面还是攻击者伪造的。这就是CSS注入最直接的危害——界面伪装。不需要跨站脚本，不需要绕过CSP，只要浏览器愿意解析你的CSS，你就能重新布局整个页面。

为什么CSS漏洞总是被低估

大部分开发者的安全心智模型里，CSS是"表现层"，不具备执行能力，所以天然安全。这个假设在大多数场景下成立，但它忽略了一个事实：CSS可以发起网络请求，可以读取DOM状态，可以控制布局。这三件事组合起来，攻击面比想象中大得多。

更麻烦的是防御。CSP（内容安全策略）主要针对JavaScript，对CSS的约束有限。style-src 指令能限制外部样式表加载，但内联样式和 <style> 标签的处理在各浏览器里并不一致。很多应用需要允许用户自定义主题或样式，这就打开了口子。你很难在"让用户自定义颜色"和"防止CSS注入"之间画一条清晰的线。

我的判断是，CSS漏洞不会消失，只会转移。随着前端框架越来越复杂，服务端渲染和客户端水合的边界越来越模糊，CSS注入的入口反而在增加。React的 dangerouslySetInnerHTML、Vue的 v-html，这些API的本意是渲染富文本，但如果内容里混入了 <style>，CSS注入就发生了。开发者通常只盯着XSS，觉得过滤了 <script> 就万事大吉，却忘了 <style> 同样危险。

要防住这类问题，最实际的做法是在服务端对用户输入做白名单过滤——只允许特定的HTML标签和属性通过，<style> 和 style 属性一律干掉。如果业务确实需要自定义样式，用CSS变量传值，别传整段CSS。浏览器厂商这边，Chrome已经在实验限制属性选择器对敏感属性的匹配，但标准层面的讨论还在早期。短期内，这事还得靠开发者自己上心。