Referer头跨站信息泄露的量化威胁建模与攻击面分析

Referer 头的设计初衷是帮助网站分析流量来源，但在跨域场景下，它成为了一把双刃剑 —— 当用户从 A 站跳转至 B 站，或加载第三方资源时，浏览器会将当前页面的完整 URL（包括路径和查询参数）一并发送。这一机制在缺乏适当策略控制的情况下，构成了持续且可量化的隐私泄露攻击面。

泄露机制与攻击面定义

Referer 头的泄露路径主要存在于三类请求场景：导航跳转（用户点击外链）、子资源加载（图片、脚本、iframe 等）、以及表单提交。当目标资源位于不同域名时，浏览器默认会将完整 URL 附加到请求头中。PortSwigger 将此问题归类为 CWE-200（信息暴露），其核心风险在于：URL 中常包含会话令牌、用户 ID、交易流水号、乃至密码重置凭证等敏感参数，这些信息一旦进入第三方服务器的访问日志，即形成不可逆的数据暴露。

现代浏览器虽已逐步采用 strict-origin-when-cross-origin 作为默认策略，仅向跨域请求发送来源域名而非完整路径，但这一防护并非绝对。首先，仍有大量网站未显式配置 Referrer-Policy，依赖浏览器默认行为，而不同浏览器的默认策略存在差异；其次，即便在严格策略下，HTTPS 向 HTTP 的请求仍可能完全剥离 Referer，但 HTTP 站点的内部流量分析需求往往促使开发者采用更宽松的策略，从而在高风险场景下打开泄露通道。

量化威胁模型构建

对 Referer 泄露进行威胁建模，需从三个维度建立量化指标：泄露信息量、泄露范围、以及泄露概率。

泄露信息量取决于 URL 中包含的敏感参数类型。可将泄露内容按敏感度分级：高危参数包括会话 ID、密码重置 token、一次性验证码、个人身份信息（如姓名、邮箱、手机号）；中危参数涵盖用户 ID、订单号、交易 ID、搜索关键词等可关联到特定用户或行为的标识；低危信息则为单纯的来源域名或路径结构。据 PortSwigger 的漏洞分类，当 Referer 头包含会话标识符时，其风险等级从 "Information" 跃升至可直接导致账户接管的高危范畴。

泄露范围可通过统计页面加载的跨域第三方资源数量来估算。一个典型网页可能加载来自 5 至 15 个不同域名的资源（包括 CDN、分析服务、广告网络、社交媒体插件等），每个资源请求都构成独立的泄露通道。若页面包含用户生成的内容或外部链接，攻击者甚至可通过诱导用户点击特定链接，将敏感 URL 定向发送至其控制的域名。

泄露概率与网站的 Referrer-Policy 配置覆盖率直接相关。未配置策略的页面完全依赖浏览器默认行为，而显式配置 unsafe-url 或 no-referrer-when-downgrade 策略的页面则在跨域场景下保持高泄露概率。量化评估时，可将策略严格程度映射为概率系数：no-referrer 为 0，same-origin 为 0.1，strict-origin-when-cross-origin 为 0.3，origin-when-cross-origin 为 0.6，no-referrer-when-downgrade 为 0.8，unsafe-url 为 1.0。

典型攻击场景与影响评估

场景一：会话固定攻击

某电商网站将会话 ID 附加在 URL 参数中用于跟踪用户行为（如 https://shop.example.com/cart?session_id=abc123）。用户浏览商品时，页面加载了第三方统计脚本。由于网站未配置 Referrer-Policy，浏览器将完整 URL（含 session_id）发送至统计服务商。若该服务商的数据库被泄露或内部人员滥用，攻击者可获取有效会话 ID，直接劫持用户账户。

场景二：密码重置凭证泄露

用户点击邮件中的密码重置链接，URL 包含一次性 token（如 https://app.example.com/reset?token=xyz789）。重置页面加载了外部字体或图片资源，Referer 头将 token 发送至第三方 CDN。攻击者通过购买 CDN 日志或利用日志分析服务的漏洞，可获取未使用的重置 token，完成账户接管。

场景三：企业内部信息泄露

企业使用的 SaaS 服务 URL 常包含项目代号、客户名称、文档标题等敏感信息（如 https://docs.corp.example.com/project-alpha/financial-q3）。员工访问这些页面时，若页面加载了外部资源（如公共图片、社交分享按钮），Referer 头会将内部项目结构暴露给第三方，为竞争对手提供商业情报。

可落地的检测与防护方案

策略配置检查清单

网站应显式设置全站级别的 Referrer-Policy，推荐值为 strict-origin-when-cross-origin，在保留同域完整 Referer 的同时，向跨域请求仅发送来源域名。配置方式包括 HTTP 响应头：Referrer-Policy: strict-origin-when-cross-origin，或 HTML meta 标签：<meta name="referrer" content="strict-origin-when-cross-origin">。对于特定元素需要更宽松策略的场景，可在元素级别覆盖，如 <img src="..." referrerpolicy="no-referrer-when-downgrade">。

敏感参数检测正则

建立 URL 敏感参数识别规则，用于安全扫描和日志审计。高危参数模式示例：/(token|session|sid|auth|key|password|pwd|secret|api[_-]?key)=[^&]+/i，中危参数模式：/(user[_-]?id|uid|order[_-]?id|transaction|search|q)=[^&]+/i。安全团队应定期扫描代码库和访问日志，识别包含敏感参数的 URL 是否通过 Referer 头泄露至第三方。

第三方域名白名单与监控

建立页面加载资源的域名清单，按信任度分级：一级信任（自有 CDN、核心服务）、二级信任（知名 SaaS、支付服务商）、三级不信任（广告网络、社交插件、未知域名）。对三级域名的请求应强制采用 no-referrer 策略，或在 CSP（内容安全策略）中限制其加载。同时监控 Referer 日志，识别异常的数据外发模式。

日志脱敏规则

对于必须记录 Referer 头的场景（如访问分析、安全审计），实施参数级脱敏。在日志采集层配置正则替换规则，将匹配敏感参数的值替换为 [REDACTED]，如 token=[^&]+ 替换为 token=[REDACTED]。同时建立日志保留策略，Referer 数据在分析完成后应及时清理，降低数据泄露后的影响面。

替代方案与纵深防御

避免依赖 Referer 头进行安全校验（如 CSRF 防护），因其可被攻击者控制或用户隐私设置屏蔽。替代方案包括：使用 CSRF Token 作为主要防护手段，配合 SameSite Cookie 属性；使用 Origin 头替代 Referer 进行跨域请求来源验证；使用 Sec-Fetch-Site 头判断请求是否为跨站请求。对于支付等敏感流程，采用请求参数哈希签名机制，确保请求完整性不依赖 Referer 校验。

结论

Referer 头的跨站信息泄露是一个可量化、可分级、可防护的安全风险。通过建立泄露信息量、泄露范围、泄露概率的三维评估模型，安全团队能够精准识别高风险页面和敏感数据流。结合严格的 Referrer-Policy 配置、敏感参数检测、第三方资源管控、以及日志脱敏等技术措施，可将 Referer 泄露风险降至可控水平。在隐私法规日益严格的背景下，将 Referer 管理纳入应用安全基线，已成为 Web 安全建设的必要环节。

资料来源

• PortSwigger: Cross-domain Referer leakage (CWE-200)
• web.dev: Referer and Referrer-Policy best practices
• MDN Web Docs: Referer header: privacy and security concerns

security