企业官网建设流程全解析

遇到可以注入 HTML、但 payload 被 Content Security Policy（CSP）拦下的场景时，CSPBypass 是一个面向伦理黑客的开源 CSP 绕过工具：粘贴一条完整的 CSP 头，它就能从 300 多个社区验证过的 XSS 绕过载荷（gadget）库中，筛出"在该策略下确实可以加载"的已知载荷。本文结合 script.js 的检索核心，带你逆析通配符域名、路径前缀、协议校验这三类精确匹配是如何实现的，以及它的边界在哪里。

1分钟认识 CSPBypass 🧩

CSPBypass 由"两个数据文件 + 一个前端检索引擎"组成，结构非常轻量：

用法很简单：把整条 CSP 头粘进输入框，例如：

script-src 'self' https://*.cdn.example.com https://api.example.com /gtag/js

工具会立刻过滤出所有"在这条策略下能加载"的已知绕过载荷，点击结果即可一键复制。仓库还附带 Dockerfile，可完全离线部署（见后文）。

检索引擎全景图：一条 CSP 串的四步处理

粘贴 CSP 头后，触发的是 script.js#L295-L334 中的检索逻辑，整条流水线是：

1. 切分头：parseCSPDirectives把整串内容切成指令 → 值的映射（script-src、default-src等），见 script.js#L278-L289
2. 过滤关键字源：processCSPDirective剔除'self'、'unsafe-inline'、nonce/hash 等非 URL 源，见 script.js#L258-L271
3. 解析单个源：parseCSPSource把每个源拆成协议、主机、通配符、路径前缀四个字段，见 script.js#L166-L197
4. 逐条匹配：matchesCspSource用协议、主机、路径三道关卡检验 data.tsv 里的每条载荷，见 script.js#L213-L256

下面三个小节，专门讲"精确"二字是怎么做到的。

通配符域名匹配：*.example.com为什么不含主域

parseCSPSource负责把单个 CSP 源拆成结构化字段。以https://*.cdn.example.com/gtag/js为例，它的输出是：

• scheme: "https"
• host: "cdn.example.com"（剥掉*.前缀）
• wildcardSubdomain: true
• pathPrefix: "/gtag/js"

匹配的关键在 script.js#L235-L243：

• 通配域名：要求载荷主机"以.+ 域名结尾"，即*.example.com能匹配sub.example.com，但不匹配主域example.com本身——这与 W3C CSP 规范一致
• 精确域名：只有完全相等才算通过

同时主机统一转小写并剥离端口号，避免大小写差异、端口差异造成的误判或漏判。

路径前缀匹配：在"路径段边界"上做匹配

这是最容易做错的一处。按 CSP 规范，源中的路径是前缀匹配，但必须在路径段边界上：

对应实现在 script.js#L245-L251：若载荷路径不等于前缀本身，就必须在前缀末尾补一个/再执行前缀判断。就靠这行"补斜杠"逻辑，避免了/gtag/jsloader因为字符开头相同被误放行。

协议校验：只有 token 带协议时才检查

script.js#L232-L233 有一行低调但关键的代码：

if (scheme && scheme !== urlScheme) continue;

只有当 CSP 源显式携带协议（如https://...）时才做协议比对；源不带协议时不会按协议限制。另外还有一个易被忽略的细节：当 data.tsv 中的载荷片段没有显式src=/href=地址时，工具会用https:// + 域名合成匹配目标（见 script.js#L214-L220），注释里明确说明这是为了防止合成的 https 地址"绕过"协议限定类 CSP 源的校验。

容易忽视的细节：'unsafe-inline'是怎么处理的

processCSPDirective（script.js#L258-L271）会先用一个关键字集合剔除'self'、'unsafe-inline'、'unsafe-eval'、nonce/hash 等源，让它们不参与 URL 匹配——它们本就不指向可加载的地址。

更巧妙的在 script.js#L307-L313 的告警逻辑：按 CSP3 规范，策略里只要出现 nonce 或 hash，浏览器就会忽略 'unsafe-inline'。所以工具只在"无 nonce/hash"时才提示unsafe-inline风险，避免误报。

快速上手：两种使用方式

1. 在线使用：访问项目官网，输入框既可填单个域名，也可粘贴完整 CSP 头，结果实时刷新
2. 完全离线（推荐）：构建仓库内的 Dockerfile，构建过程中会用sed把远程数据源替换为镜像内自带的 data.tsv 与 credits.txt，执行docker run --rm -p 8080:80 cspbypass后访问http://localhost:8080/即可，全程无外部调用，匹配逻辑全部在本地浏览器完成

常见问题 ❓

Q：查了某个域名没有结果？先看它是否在 csp_domains.json 中——该文件收录了真实 CSP 头里出现过的域名，只有清单内的域名才会被接收为 data.tsv 的贡献（贡献规范见 README.md）。

Q：策略里明明白名单了域名，为什么没命中载荷？多半是协议或路径边界不满足：比如载荷只支持 http 而 token 指定了 https，或白名单路径过短。工具严格按规范匹配，不会放宽——这恰恰是它可信的原因。

小结

CSPBypass 的核心不过 360 行 JS，却完整覆盖了 CSP 规范里的几个边界：通配域名边界、路径段前缀、条件式协议校验，以及 nonce/hash 对unsafe-inline的压制作用。对做 Web 安全研究的新手来说，通读一遍 script.js 是系统理解 Content Security Policy 匹配规则的快速路径；而翻阅 data.tsv 则是熟悉 JSONP 类绕过载荷写法的最快方式。

所有载荷均来自社区，维护者名单收录在 credits.txt 中。最后提醒：本工具仅用于获得授权的安全测试，发现漏洞请遵循负责任披露流程，先报告站点所有者。