引用站点策略（Referrer Policy）

Brendan_001

已于 2024-08-13 09:04:31 修改

阅读量1k

点赞数 13

文章标签：服务器

于 2024-08-13 09:02:16 首次发布

本文链接：https://blog.csdn.net/weixin_63490470/article/details/141154284

版权

引用站点策略（Referrer Policy）是HTTP响应头中的一个安全相关字段，用于控制在用户从一个页面导航到另一个页面时，是否以及如何发送 referrer 信息。Referrer 是指当前页面的上一个页面的 URL，通过这个字段可以追踪用户的来源。

默认情况下，浏览器会将完整的 referrer URL 发送给目标页面，这可能包含敏感信息如登录凭证或个人数据。为了保护用户隐私和安全，网站管理员可以通过设置 Referrer-Policy 来控制 referrer 的内容和发送方式。

Referrer-Policy 可以有多种不同的值，每种值对应不同的策略：

no-referrer：不发送任何 referrer 信息，这是最宽松且最不安全的策略。
no-referrer-when-downgrade：当协议安全性降低（例如从 HTTPS 转到 HTTP）时不发送 referrer 信息。
origin：只发送当前页面的 origin 部分（协议、主机和端口），而不包括路径和查询字符串。
origin-when-cross-origin：跨域请求时只发送当前页面的 origin 部分，同源请求则发送完整的 referrer URL。
same-origin：仅在同源请求时发送完整的 referrer URL。
strict-origin：与 origin 相似，但不允许发送虚假的 referrer 信息。
strict-origin-when-cross-origin：跨域请求时只发送当前页面的 origin 部分，且不允许发送虚假的 referrer 信息。
unsafe-url：允许发送完整的 referrer URL，但可能会暴露敏感信息。

Referrer-Policy 的设置可以通过以下几种方式实现：

在 HTTP 响应头中直接设置 Referrer-Policy 字段。
使用 meta 标签指定 name 值为 referrer 的属性。
在 a、area、img、iframe 或 link 元素上使用 referrerpolicy 属性。
使用 Link 关系中的 noreferrer 属性。

通过合理配置 Referrer-Policy，网站所有者可以在保护用户隐私和提高安全性之间找到平衡点，防止恶意活动，并遵守相关法规要求。

Referrer-Policy 的最新标准和最佳实践是什么？

Referrer-Policy（引用来源策略）的最新标准和最佳实践主要集中在如何控制浏览器在请求中包含引用来源信息的方式，以增强网站的安全性和隐私保护。根据，新版的Referrer Policy规定了五种策略：No Referrer、No Referrer with Origin、Same Origin、No Referrer When Downgrading、 always。这些策略旨在限制或完全不发送引用来源信息，以防止敏感数据泄露。

最佳实践方面，指出，对于自身服务器，通过客户端发来的请求中带有的referer信息可以用来防止CORS（跨站请求伪造）。然而，为了更好地防御CSRF攻击，最佳实践应该是结合多种防御措施，包括但不限于设置合适的Referrer-Policy策略。

具体到Referrer-Policy的使用，提供了联合国网络安全标准化机构（UN-ETSI）的建议，即可以通过修改链接的referrerpolicy属性来限制引用来源信息的传播，例如设置为"origin"以仅传递当前页面的域名部分，或者使用noreferrer属性来阻止浏览器自动设置Referer头。

如何在不同类型的网站（如电商、论坛、博客）中实施 Referrer-Policy 以保护用户隐私？

在不同类型的网站中实施Referrer-Policy以保护用户隐私，需要根据网站的具体需求和场景选择合适的策略。以下是一些基于搜索结果的建议：

电商网站：对于电商网站，保护用户隐私尤为重要，因为可能涉及支付信息和购物历史。可以使用strict-origin-when-cross-origin策略，这在跨域请求时只发送来源的域名（不包括路径），从而减少敏感信息的泄露。
论坛：论坛通常包含大量用户生成内容，保护用户隐私同样重要。可以采用no-referrer或no-referrer-when-downgrade策略，这些策略在大多数情况下不会发送Referrer头，但在降级（从HTTPS到HTTP）时会发送完整的URL，这有助于防止跟踪但同时保留了一定程度的统计功能。
博客：博客网站可能需要一定的统计功能来分析访问量和用户行为。可以使用same-origin策略，这仅在同源请求时发送Referrer头，适用于大多数博客场景，既能满足统计需求又不过度暴露用户隐私。
通用策略：无论哪种类型的网站，都可以考虑使用严格模式（如strict origin或strict-origin-when-cross-origin），这些策略在跨域请求时只发送来源的域名，有效防止了跨站跟踪。
配置方法：可以通过设置HTTP响应头中的Referrer-Policy，或者在HTML文档中通过<meta name="referrer" content="...">标签来指定Referrer策略。

Referrer-Policy 对SEO（搜索引擎优化）有何影响？

Referrer-Policy（引荐来源政策）对SEO（搜索引擎优化）有显著影响，主要体现在以下几个方面：

增强网页结构和可读性：通过在和标签中使用Referrer-Policy属性，可以提供一种语义化的方式来描述链接的目的，这不仅增强了网页的结构和可读性，同时也对搜索引擎优化（SEO）有着积极的影响。
控制Referrer信息传递：Referrer-Policy允许网站管理员定义出站链接中的referrer头信息的值。这意味着可以控制在用户点击链接时发送给目标网站的referrer信息，从而影响目标网站的分析工具和SEO策略。
加密流量与referrer数据共享：通过meta referrer tag，可以更好地控制如何传递referrer信息，即使是在使用HTTPS的情况下，也可以将referrer数据传递给所有网站，包括那些使用HTTP的网站。这有助于保持流量的加密同时保留HTTPS的所有好处，对于SEO来说是一个重要的考虑因素。
影响网站访问量和回访率：参考源站点策略可以帮助提高网站的访问量。搜索引擎可能会忽略那些与网站目标不符或目的不明确的网站，而从参考源站点访问的客户通常具有较高的回访率。

Referrer-Policy通过控制referrer信息的传递，影响网站分析工具的使用，以及通过参考源站点策略提高网站访问量和回访率，从而间接地对SEO产生积极影响。

在实际应用中，Referrer-Policy 导致的安全漏洞有哪些例子？

在实际应用中，Referrer-Policy 导致的安全漏洞主要体现在以下几个方面：

CSRF（跨站请求伪造）攻击：
- 通过修改或隐藏请求的Referer字段，攻击者可以绕过安全验证。例如，在2007年Gmail的CSRF漏洞中，攻击者能够隐藏甚至修改自己请求的Referer。
- 另一个案例是单点登录网站通过Referer盗取用户授权，这表明攻击者可以通过操控Referer字段来窃取用户的会话信息和cookie，从而模仿合法用户执行操作。
不安全的访问控制：
- 应用程序使用HTTP Referer头作为访问控制决策的基础。例如，一个应用程序可能严格控制对主要管理菜单的访问权限，但当用户请求某个特定的管理功能时，它可能会检查该请求是否来自管理菜单页面，并假设用户已经访问过该页面并因此拥有所需的权限。这种模型存在根本性缺陷，因为Referer头完全由用户控制，可以设置为任何值。
恶意内容或跨站脚本攻击：
- 设置不当的Referrer-Policy可能导致浏览器提供的安全特性失效，从而允许恶意内容或跨站脚本攻击。
隐私泄露：
- 如果没有正确设置Referrer-Policy，浏览器可能会发送过多的用户信息给服务器，导致隐私泄露。

Referrer-Policy 在实际应用中的不当配置可能导致多种安全漏洞，包括CSRF攻击、不安全的访问控制、恶意内容或跨站脚本攻击以及隐私泄露等问题。

如何测试和验证 Referrer-Policy 的有效性？

要测试和验证 Referrer-Policy 的有效性，可以采取以下步骤：

使用HTML解析器检查：根据，可以通过HTML解析器来检查是否设置了 Referrer-Policy。这通常通过在网页的元标签中查找<meta referrer>来实现。如果存在这样的标签，并且其内容与预期的 Referrer-Policy 值匹配，则可以认为 Referrer-Policy 已被正确设置。
检查HTTP响应头中的Referrer-Policy：提到，服务器对HTTP请求的响应头中应包含Referrer-Policy。如果在响应头中找到并确认了正确的Referrer-Policy值，则可以验证其有效性。
浏览器API的请求对象属性：根据，可以使用Web APIs中的Request接口的referrerPolicy只读属性来获取请求的Referrer-Policy。这允许开发者在客户端代码中检查和验证Referrer-Policy是否按预期工作。
实际操作测试：创建一个测试页面，尝试从不同的源加载资源，并观察浏览器如何处理Referrer头部。例如，从同一域名加载页面时，应看到Referrer头部包含当前页面的URL；而从不同域名加载时，Referrer头部可能为空或不包含任何信息，这取决于所使用的Referrer-Policy策略。
跨站请求伪造（CSRF）攻击测试：根据，可以通过模拟跨站请求来测试Referrer-Policy的有效性。如果Referrer-Policy能够阻止或限制这些请求，那么它就有效地防止了潜在的安全威胁。