---

概述

---

原因分析

Referrer Policy（引用策略）是 Web 应用程序的一个关键配置，用于定义浏览器在向目标网站发送请求时，如何处理并发送 Referer 头信息。Referer 头可能包含敏感信息（例如：用户名、密码、文件路径、页面 URL 等），如果没有正确配置 Referrer-Policy，这些信息可能被暴露给跨站点（第三方）请求，从而导致安全漏洞。

不正确的配置（例如使用 no-referrer-when-downgrade 或 unsafe-url）可能会导致：

• 敏感信息泄露：例如，包含敏感信息的 URL 可能会被无意间暴露给第三方网站。
• 跨站点泄漏：如果不适当地泄露了 Referer，其他站点可能会获得该敏感数据。
• 攻击者利用信息：例如，攻击者通过分析泄露的 Referer 信息，可能会获得关于用户身份、账户、甚至敏感资源的线索，从而进行攻击。

---

风险说明

1. 敏感数据泄露：

   • 如果 Referrer-Policy 配置不当，用户在浏览页面时，URL 地址中可能会暴露敏感信息（如用户名、密码、身份标识符、路径信息等），这些信息可能会通过 Referer 头发送到外部站点。
   • 特别是在 HTTP 到 HTTPS 跳转或跨站点请求时，URL 中的敏感数据可以被泄露，进一步加大了信息泄露的风险。

2. 用户信任受损：

   • 防备心不强的用户在网站上提供敏感信息（如信用卡号、社会保险号等）时，若系统没有正确保护其数据隐私（如通过不安全的 Referer 配置泄露了敏感信息），可能会引发信任危机。

3. 潜在的跨站点攻击：

   • 不正确的 Referrer-Policy 使得敏感信息可以通过 Referer 头泄漏给不受信任的第三方站点，这可能会为攻击者提供利用跨站点漏洞（如 CSRF、XSS 等）的机会。

---

Referrer-Policy 头配置选项

"no-referrer-when-downgrade" 和 "unsafe-url" 是泄露第三方网站完整 URL 的策略，它们可能导致敏感信息泄漏。

1. 不安全的策略

no-referrer-when-downgrade

• 定义：当请求从 HTTPS 协议降级到 HTTP 时，不会发送 Referer 头；但在其他情况下（包括 HTTPS 到 HTTPS，HTTP 到 HTTP），仍会发送完整的 Referer 头。
• 风险：
  • 当从 HTTPS 页面跳转到 HTTP 页面时，浏览器不会发送 Referer 头，以防泄露信息。
  • 然而，在 HTTPS 到 HTTPS 或 HTTP 到 HTTP 的情况下，Referer 头会包含完整的 URL（包括路径和查询参数），这可能会泄露敏感数据。
  • 该策略不能完全保护隐私，尤其是跨站点的情况。

unsafe-url

• 定义：始终发送完整的 Referer 头，包括 URL 的协议、主机、路径和查询参数，无论目标页面的协议如何。
• 风险：
  • 这种配置会导致 Referer 头泄漏所有请求的详细信息，包括路径和查询字符串。
  • 即使请求从 HTTPS 页面跳转到 HTTP 页面，浏览器仍会发送完整的 URL，这可能会导致敏感信息（如会话 ID、用户数据等）泄漏。
  • 强烈不建议使用该策略，尤其在涉及敏感数据的站点上。

2. 安全的策略

与上述不安全的策略相比，以下是一些更为安全的 Referrer-Policy 配置，能够有效防止敏感信息泄漏。

no-referrer

• 定义：完全禁止浏览器发送 Referer 头。
• 优点：
  • 提供最高级别的隐私保护，不会泄露任何来源信息。
  • 防止所有跨站点的 Referer 泄露。
• 缺点：
  • 对某些需要依赖 Referer 信息的功能（例如，分析或日志记录）会有影响。
  • 如果网站内部的某些操作依赖于 Referer，则需要考虑是否适合使用该策略。

origin

• 定义：仅发送请求的源（域名），而不包含路径和查询参数。
  • 例如，Referer: https://example.com/ 而不是 https://example.com/path?query=param。
• 优点：
  • 只泄露源（域名），不泄露路径或查询字符串，适合保护用户隐私。
• 缺点：
  • 适用于需要保护隐私的跨站点请求，但在某些情况下，源信息可能不足以满足需要跟踪源的应用程序需求。

origin-when-cross-origin

• 定义：当请求是同源请求时，发送完整的 Referer 头（包括路径和查询参数）；当请求是跨站点请求时，仅发送源（域名）。
• 优点：
  • 为同源请求提供完全的 Referer 信息，而对于跨站点请求则仅泄露源信息，最大限度地减少跨站点泄露敏感信息的风险。
  • 推荐用于保护隐私并确保同源请求的正常运作。
• 缺点：
  • 对跨站点请求仍然可能会限制某些分析或跟踪功能，但在隐私和安全性方面提供了更好的平衡。

same-origin

• 定义：只有在请求目标与当前页面同源时，才会发送 Referer 头。跨站点请求将不发送 Referer。
• 优点：
  • 最大限度地保护跨站点隐私，完全防止了跨站点泄漏 Referer 信息。
• 缺点：
  • 对于跨站点请求（如 API 调用），无法发送 Referer 信息，这可能影响一些站点功能（如跨站点资源共享等）。

strict-origin

• 定义：只有在请求的目标是安全站点（即 HTTPS）并且协议一致时，才发送 Referer 头。对跨站点请求的保护比 origin 更严格。
• 优点：
  • 对跨站点请求有更强的隐私保护，确保只有同协议的请求会发送源信息。
• 缺点：
  • 如果目标站点使用的是 HTTP 协议，甚至源信息也不会被发送。

strict-origin-when-cross-origin

• 定义：如果请求是同源请求，则发送完整的 Referer 头；如果请求是跨站点请求，则仅发送源（域名）；且目标站点需要使用 HTTPS 协议时才会发送 Referer。
• 优点：
  • 这是目前最为推荐的策略，在保证跨站点隐私的同时，允许同源请求发送完整的 Referer 信息。即使是跨站点请求，也只会泄露源信息，并且只有目标是安全的 HTTPS 网站时，才会发送 Referer 信息。
  • 提供了对隐私的最大保护，同时不会干扰正常功能。
• 缺点：
  • 对于不使用 HTTPS 的目标站点，Referer 信息将不被发送。

---

推荐配置

对于大多数站点，strict-origin-when-cross-origin 是最佳选择，因为它在保障隐私和安全的同时，不会对大多数跨站点请求产生负面影响。

Nginx 配置示例

http {
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

• 不安全的策略（如 no-referrer-when-downgrade 和 unsafe-url）会泄漏敏感信息，尤其是在跨站点请求时。
• 推荐的策略（如 strict-origin-when-cross-origin、origin-when-cross-origin）能够在保持功能正常的同时，最大限度地保护用户隐私。
• 配置 Referrer-Policy 头是 Web 安全的重要措施，确保适当配置可以降低泄漏敏感数据的风险。

---

在 Nginx 中配置 Referrer-Policy

可以通过在 Nginx 配置中设置适当的 Referrer-Policy 来避免泄漏敏感信息。

配置示例

1. 全局设置：

   http {
       add_header Referrer-Policy "strict-origin-when-cross-origin" always;
   }
   

2. 虚拟主机设置：

   server {
       listen 80;
       server_name example.com;
       
       add_header Referrer-Policy "strict-origin-when-cross-origin" always;
       
       # 其他配置...
   }
   

3. 特定路径设置：

   server {
       listen 80;
       server_name example.com;
       
       location /some-path/ {
           add_header Referrer-Policy "no-referrer" always;
       }
       
       # 其他配置...
   }
   

总结

• Referrer-Policy 头是防止敏感数据泄露的有效工具。合理配置此头可以保护用户隐私，防止跨站点泄露敏感信息。
• 避免使用不安全的策略，如 no-referrer-when-downgrade 和 unsafe-url，并优选使用 strict-origin-when-cross-origin 或更严格的策略。
• 定期检查并更新你的 Web 应用配置，确保所有安全头都已正确设置，以减少潜在的安全风险。