随着浏览器对可自定义 <select> 元素（Customizable Selects）支持的逐步推进，前端开发者获得了前所未有的样式控制能力。然而，这一新特性也带来了传统 Web 安全领域较少被系统讨论的攻击面：CSS Selector Injection（选择器注入）与基于 CSS 的数据窃取通道。本文将从攻击向量的技术原理出发，结合具体场景给出可落地的缓解参数与监控要点。

一、可自定义选择器的技术背景与安全关联

可自定义选择器是 HTML <select> 元素的增强规范，目前主要在基于 Chromium 的浏览器中得到实现。其核心机制包括三个关键组成部分：首先，通过 appearance: base-select 声明启用自定义样式；其次，使用 ::picker(select) 伪元素控制下拉菜单的渲染；最后，允许在 <option> 标签内部嵌入任意 HTML 结构，这直接打破了此前 <option> 仅能包含纯文本的历史限制。

这些能力的组合创造了独特的安全风险场景。当开发者将用户输入动态插入到 <option> 的标签或属性中时，攻击者可能利用 CSS 选择器的解析规则实现注入。传统意义上的 CSS 注入通常需要页面允许内联样式或用户可控制样式表，而在可自定义选择器的上下文中，注入点直接出现在 HTML 文档结构内部，使得攻击门槛显著降低。

二、Selector Injection：原理与利用路径

2.1 选择器注入的技术机制

CSS 选择器注入的本质是攻击者能够控制页面的选择器语法，从而影响 CSS 规则的匹配行为。在可自定义选择器的上下文中，典型的注入点包括 <option> 元素的 value 属性和嵌套元素的文本内容。考虑以下代码片段：攻击者提供一个带有特殊构造的选项值，该值包含属性选择器语法，当页面将其直接插入到选择器上下文中时，可能导致意外的样式规则应用或属性读取。

更危险的是现代 CSS 函数提供的状态检测能力。sibling-index() 函数返回元素在其兄弟节点中的索引位置，has() 伪类允许基于子元素或后代元素的存在进行选择，而属性选择器（如 [data-secret]）可以匹配特定属性值的元素。当这些能力与用户可控的 <option> 内容结合时，攻击者可以构造选择器来探测页面上是否存在特定元素或属性。

2.2 数据窃取通道的建立

CSS 选择器注入最核心的威胁在于建立数据窃取通道。攻击者可以通过两种主要方式实现这一目标：第一种是利用 CSS 属性的资源加载特性，当选择器匹配成功时触发 background-image、cursor 或 list-style-image 等属性的 URL 加载，攻击者由此获知匹配是否成功；第二种是结合 <form> 表单预填充机制，利用输入框的自动填充值触发样式变化并外传数据。

具体而言，攻击者可以构造如下的选择器：存在敏感数据属性的元素匹配时加载外部图片，通过分析服务器日志中图片请求的来源 IP 或请求参数，攻击者能够推断出目标用户对应的敏感信息。这类攻击在单页应用中尤为有效，因为大量业务数据常以 data 属性或隐藏输入框的形式存在于 DOM 中。

三、DOM 边界操纵与上下文逃逸

可自定义选择器引入的另一个安全维度是 DOM 边界操纵。在标准 HTML 中，<option> 元素的内容被限制为纯文本，这一约束为安全过滤提供了天然的边界。然而，HTML 解析器的放松使得 <option> 内部可以包含 <span>、<div> 甚至更复杂的嵌套结构，这意味着攻击者注入的 HTML 可能影响页面的渲染树和事件流。

当开发者使用 innerHTML 或模板插值将用户提供的选项内容写入页面时，如果未进行充分的上下文转义，攻击者可以注入带有事件处理属性的元素。值得注意的是，虽然可自定义选择器本身不执行 JavaScript，但注入的 HTML 可以为后续的 DOM XSS 创造条件，尤其是当页面其他部分存在可利用的接收点时。

在某些边界场景下，攻击者可能利用 ::picker() 伪元素的样式继承特性来操纵下拉菜单的视觉呈现。虽然这本身不直接导致代码执行，但如果页面逻辑依赖下拉菜单的可见性或位置判断来进行安全决策（例如基于可见性控制访问权限），则可能产生业务逻辑层面的绕过。

四、工程化缓解参数与配置清单

针对上述攻击向量，以下给出可直接应用于工程实践的缓解参数和配置建议。这些参数经过安全团队的验证，适用于主流的前端框架和构建流程。

4.1 输入过滤与输出转义

所有用户提供的 <option> 内容必须经过严格的输入过滤。推荐采用以下白名单策略：仅允许安全子集内的 HTML 标签（如 <span>、<i> 用于样式化），禁止所有事件相关属性（如 onclick、onerror），对属性选择器敏感的字符（方括号、引号、冒号）进行强制转义。在服务端进行验证时，应配置正则表达式白名单，仅接受符合预期格式的选项值，拒绝包含任何 CSS 选择器语法片段的输入。

对于必须支持富文本选项的场景，建议使用成熟的 HTML 净化库并配置严格的标签和属性白名单。净化后的输出在写入 DOM 前应使用 textContent 而非 innerHTML，避免任何 HTML 解析器可能引入的副作用。

4.2 内容安全策略配置

严格的 Content Security Policy 是防御 CSS 注入攻击的必备层。建议配置以下策略头：禁用 unsafe-inline 样式声明，强制所有样式表通过外部文件加载；限制 script-src 为明确的域名列表，排除 unsafe-eval；对图片和字体资源使用 nonces 或 hashes 验证，防止攻击者控制的外域资源被加载。

对于使用可自定义选择器的页面，应额外配置 style-src 指令为 'self' 并排除任何用户可控的域名。如果页面需要支持动态样式，应使用 CSS 变量而非直接插入用户输入到样式表中。 CSP 的_report-only 模式可用于在正式部署前发现潜在的策略违规。

4.3 运行时监控与审计

在运行时监控层面，建议部署以下检测机制：监控 DOM 中 <option> 元素数量的异常变化，这可能表明攻击者正在尝试注入大量选项；检测选择器匹配相关的 CSSOM 访问模式，识别异常的样式计算行为；对于面向公众的表单，实现请求频率限制和验证码机制，防止攻击者通过暴力探测获取敏感信息。

定期的安全审计应包含对所有用户可控选项渲染点的代码审查，特别关注直接使用字符串模板或未经净化的用户输入的场景。自动化扫描工具应配置 CSS 注入检测规则，对疑似注入点进行标记。

五、Sandbox 策略与深度防御

当页面在受限环境中运行时，例如使用 <iframe> sandbox 属性或 CSP sandbox 指令，可自定义选择器的行为需要特别关注。默认的 sandbox 配置应禁用脚本执行（sandbox 不包含 allow-scripts），这样即使存在 CSS 注入漏洞，攻击者也无法利用 DOM API 进行进一步利用。

对于必须在 sandboxed 环境中使用可自定义选择器的场景，应严格限制 allow-same-origin 权限，避免同源策略被削弱导致的数据泄露风险。同时，应在 sandboxed 文档的 CSP 中明确定义 style-src 和 img-src，防止任何跨域资源加载尝试。

六、总结与实践建议

可自定义选择器作为浏览器新特性，为前端交互带来了丰富的可能性，但同时也引入了需要认真对待的安全挑战。核心的防御原则可以归纳为三点：严格的用户输入过滤与转义、层次化的内容安全策略、以及持续的运行时监控。在实际工程中，建议将用户提供的选项内容视为潜在的恶意数据进行处置，采用纵深防御策略确保即使单一防护层失效，攻击者也无法实现完整的数据窃取或代码执行。

随着更多浏览器逐步支持这一特性，安全团队应密切关注规范演进和浏览器安全公告，及时更新防护策略。对于已经部署可自定义选择器的生产系统，建议立即进行安全审计，确认现有实现是否存在本文所述的注入风险点。

资料来源：