Web安全 - “Referrer Policy“ Security 头值不安全

文章目录


概述


原因分析

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

不正确的配置(例如使用 no-referrer-when-downgradeunsafe-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 配置示例

nginx 复制代码
http {
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
  • 不安全的策略 (如 no-referrer-when-downgradeunsafe-url)会泄漏敏感信息,尤其是在跨站点请求时。
  • 推荐的策略 (如 strict-origin-when-cross-originorigin-when-cross-origin)能够在保持功能正常的同时,最大限度地保护用户隐私。
  • 配置 Referrer-Policy 头是 Web 安全的重要措施,确保适当配置可以降低泄漏敏感数据的风险。

在 Nginx 中配置 Referrer-Policy

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

配置示例

  1. 全局设置

    nginx 复制代码
    http {
        add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    }
  2. 虚拟主机设置

    nginx 复制代码
    server {
        listen 80;
        server_name example.com;
        
        add_header Referrer-Policy "strict-origin-when-cross-origin" always;
        
        # 其他配置...
    }
  3. 特定路径设置

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

总结

  • Referrer-Policy 头是防止敏感数据泄露的有效工具。合理配置此头可以保护用户隐私,防止跨站点泄露敏感信息。
  • 避免使用不安全的策略,如 no-referrer-when-downgradeunsafe-url,并优选使用 strict-origin-when-cross-origin 或更严格的策略。
  • 定期检查并更新你的 Web 应用配置,确保所有安全头都已正确设置,以减少潜在的安全风险。
相关推荐
?333336 小时前
常见cms获取Shell漏洞(Wordpress、dedecms、ASPCMS、PhpMyadmin)
安全·web安全·网络安全·php
网络安全-老纪7 小时前
[网络安全] DVWA之 Command Injection 攻击姿势及解题详析合集
安全·web安全
建爱永恒7 小时前
数据库工程师进阶秘籍:云计算基础知识题目精选与答案(附PDF)
数据库·安全·云计算·数据库系统
联蔚盘云7 小时前
Lianwei 安全周报|2025.1.2
安全
koko爱英语7 小时前
区块链安全常见的攻击分析——Unprotected callback - ERC721 SafeMint reentrancy【8】
安全·区块链
贝塔实验室8 小时前
FPGA三模冗余TMR工具(二)
安全·fpga开发·重构·硬件架构·硬件工程·软件构建·fpga
Fab1an10 小时前
打靶记录23——Raven2
网络·数据库·笔记·安全·web安全
R3de3m12 小时前
吾杯网络安全技能大赛——Misc方向WP
数据库·python·web安全·网络安全
成为大佬先秃头13 小时前
安全框架:Apache Shiro
spring boot·安全·apache·shiro