先给你一个明确的结论：恶意CSS本身几乎不可能直接感染你的Web服务器。原因很简单——CSS是纯客户端的样式语言，它只会在用户的浏览器里解析执行，不会直接接触到服务器端的代码、文件系统或者后台服务。

不过也不能掉以轻心，存在一些间接的风险场景需要注意：

• 如果你服务器上有文件上传功能，攻击者可能把恶意脚本（比如PHP、Python代码）伪装成CSS文件上传，再通过服务器的解析漏洞（比如把.css文件当成脚本文件执行）来入侵服务器。但这本质是服务器配置或上传验证的问题，不是CSS本身的锅。
• 恶意CSS可能配合其他服务器端漏洞（比如模板注入、文件包含），诱导管理员或用户触发某些操作，间接导致服务器被攻击，但这种情况需要已有漏洞的存在，单独的CSS做不到。

接下来聊聊需要警惕的恶意CSS特征，帮你快速排查风险：

要重点留意的恶意CSS特征 #

• expression() 或 javascript: 伪协议：虽然现代主流浏览器已经限制了expression()的执行，但一些旧环境或特殊浏览器里，它可以直接运行JS代码，比如 width: expression(alert('XSS'));。另外，javascript:伪协议出现在url()里也要警惕，比如 background: url(javascript:alert('XSS'));。
• 可疑的url() 或 data: URI：如果CSS里的url()指向陌生域名的资源，或者用data: URI嵌入了脚本内容（比如 data:text/javascript,malicious_code），哪怕浏览器现在限制执行，也可能是潜在的攻击载体。
• 滥用@import引入外部资源：如果CSS里用@import加载了未知来源的外部CSS文件，相当于把风险转嫁到了第三方资源上，对方的文件可能包含恶意代码。
• 复杂的attr()函数或CSS变量操作：如果你的应用允许用户自定义CSS变量，或者CSS里大量使用attr()读取用户可控的属性值，攻击者可能注入恶意内容配合客户端漏洞触发执行。
• 隐藏的交互诱导：比如用:hover、:active等伪类配合content属性生成可点击的恶意文本，诱导用户跳转至钓鱼网站或执行危险操作。

额外的安全建议 #

• 从可信渠道获取CSS文件，哪怕是MIT许可的开源项目，也要花几分钟扫一遍代码内容，不要盲目引入。
• 可以用静态代码扫描工具（比如一些CSS lint工具）自动检测可疑的表达式或链接。
• 如果你的应用支持用户自定义CSS上传，一定要做严格的内容过滤：禁止expression()、javascript:这类关键字，限制@import的域名白名单，过滤data: URI中的脚本类型。
• 保持服务器软件（比如Nginx、Apache）和浏览器的更新，修复已知的解析漏洞。

内容的提问来源于stack exchange，提问作者ElsaInSpirit