ToB企服应用市场:ToB评测及商务社交产业平台

标题: Web安全 - “Referrer Policy“ Security 头值不安全 [打印本页]

---

作者: 科技颠覆者    时间: 4 天前
标题: Web安全 - “Referrer Policy“ Security 头值不安全

---

概述

---

原因分析

Referrer Policy（引用战略）是 Web 应用步伐的一个关键配置，用于界说欣赏器在向目的网站发送哀求时，如何处理并发送 Referer 头信息。Referer 头可能包罗敏感信息（例如：用户名、密码、文件路径、页面 URL 等），假如没有正确配置 Referrer-Policy，这些信息可能被袒露给跨站点（第三方）哀求，从而导致安全漏洞。
不正确的配置（例如使用 no-referrer-when-downgrade 或 unsafe-url）可能会导致：

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

---

风险阐明

• 敏感数据泄漏：
  
  
  
  • 假如 Referrer-Policy 配置不当，用户在欣赏页面时，URL 地址中可能会袒露敏感信息（如用户名、密码、身份标识符、路径信息等），这些信息可能会通过 Referer 头发送到外部站点。
    
  • 特殊是在 HTTP 到 HTTPS 跳转或跨站点哀求时，URL 中的敏感数据可以被泄漏，进一步加大了信息泄漏的风险。
    
  
  
• 用户信任受损：
  
  
  
  • 防备心不强的用户在网站上提供敏感信息（如信用卡号、社会保险号等）时，若系统没有正确掩护其数据隐私（如通过不安全的 Referer 配置泄漏了敏感信息），可能会引发信任危机。
    
  
  
• 潜在的跨站点攻击：
  
  
  
  • 不正确的 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 配置示例

1. http {
2.     add_header Referrer-Policy "strict-origin-when-cross-origin" always;
3. }

复制代码

• 不安全的战略（如 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 {
  2.     add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  3. }

  复制代码
• 虚拟主机设置：
  
  1. server {
  2.     listen 80;
  3.     server_name example.com;
  4.    
  5.     add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  6.    
  7.     # 其他配置...
  8. }

  复制代码
• 特定路径设置：
  
  1. server {
  2.     listen 80;
  3.     server_name example.com;
  4.    
  5.     location /some-path/ {
  6.         add_header Referrer-Policy "no-referrer" always;
  7.     }
  8.    
  9.     # 其他配置...
  10. }

  复制代码

总结

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4