论坛
潜水/灌水快乐,沉淀知识,认识更多同行。
ToB圈子
加入IT圈,遇到更多同好之人。
朋友圈
看朋友圈动态,了解ToB世界。
ToB门户
了解全球最新的ToB事件
博客
Blog
排行榜
Ranklist
文库
业界最专业的IT文库,上传资料也可以赚钱
下载
分享
Share
导读
Guide
相册
Album
记录
Doing
搜索
本版
文章
帖子
ToB圈子
用户
免费入驻
产品入驻
解决方案入驻
公司入驻
案例入驻
登录
·
注册
只需一步,快速开始
账号登录
立即注册
找回密码
用户名
Email
自动登录
找回密码
密码
登录
立即注册
首页
找靠谱产品
找解决方案
找靠谱公司
找案例
找对的人
专家智库
悬赏任务
圈子
SAAS
ToB企服应用市场:ToB评测及商务社交产业平台
»
论坛
›
安全
›
网络安全
›
Web安全 - “Referrer Policy“ Security 头值不安全 ...
Web安全 - “Referrer Policy“ Security 头值不安全
科技颠覆者
金牌会员
|
4 天前
|
显示全部楼层
|
阅读模式
楼主
主题
893
|
帖子
893
|
积分
2679
概述
原因分析
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 配置示例
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 来制止泄漏敏感信息。
配置示例
全局设置
:
http {
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
复制代码
虚拟主机设置
:
server {
listen 80;
server_name example.com;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# 其他配置...
}
复制代码
特定路径设置
:
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 应用配置,确保所有安全头都已正确设置,以淘汰潜在的安全风险。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有账号?
立即注册
x
回复
使用道具
举报
0 个回复
倒序浏览
返回列表
快速回复
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
or
立即注册
本版积分规则
发表回复
回帖并转播
回帖后跳转到最后一页
发新帖
回复
科技颠覆者
金牌会员
这个人很懒什么都没写!
楼主热帖
XAML 设计器已意外退出。(退出代码: e0 ...
OpenCV提取十字标中心点的几种思路 ...
我分析30w条数据后发现,西安新房公摊 ...
Windows | RDPWrap 远程桌面登录加强工 ...
码上加速,低代码解锁高效交付案例 ...
计算机网络学习—计算机网络概述 ...
WPF 使用 MAUI 的自绘制逻辑
Cesium 案例(二)Web MapTile Service ...
K8S 实用工具之三 - 图形化 UI Lens ...
Python itertools 库的使用记录
标签云
挺好的
服务器
快速回复
返回顶部
返回列表