使用Referer Meta标签控制referer -
| 关注黑客与极客
使用Referer Meta标签控制referer
共138931人围观
，发现 5 个不明物体
本文描述了一个关于 http 协议中 referer 的 metadata 参数的提议，使用这个 metadata 参数，html 文档可以控制 http 请求中的 referer ，比如是否发送 referer、只发送 hostname 还是发送完整的 referer 等。虽然有一些方法可以控制 referer ，比如 flash，以及一些 js 的 tricks，但是本文中描述的是另外一番景象。
在某些情况下，出于一些原因，网站想要控制页面发送给 server 的 referer 信息的情况下，可以使用这一 referer metadata 参数。
社交网站一般都会有用户个人页面，这些页面中用户都有可能添加一些外网的链接，而社交网站有可能不希望在用户点击了这些链接的时候，泄露用户页面的 URL ，因为这些 URL 中可能包含一些敏感信息。当然，有些社交网站可能只想在 referer 中提供一个 hostname，而不是完整的 URL 信息。
有些使用了 https 的网站，可能在 URL 中使用一个参数(sid 等)来作为用户身份凭证，而又需要引入其他 https 网站的资源，这种情况下，网站肯定不希望泄露用户的身份凭证信息。
Object-Capability Discipline
有些网站遵循Object-Capability Discipline，而 referer 刚好与这一策略相悖，所以，网站能够控制 refeer 将对 Object-Capability Discipline 很有利。
referer 的 metedata 参数可以设置为以下几种类型的值：
如果在文档中插入 meta 标签，并且 name 属性的值为 referer，浏览器客户端将按照如下步骤处理这个标签：
1.如果&meta&标签中没有&content&属性，则终止下面所有操作
2.将&content&的值复制给&referrer-policy&，并转换为小写
3.检查&content&的值是否为上面&list&中的一个，如果不是，则将值置为&default
上述步骤之后，浏览器后续发起 http 请求的时候，会按照 content 的值，做出如下反应(下面 referer-policy 的值即 meta 标签中 content 的值)：
1.如果&referer-policy&的值为never：删除&http&head&中的&referer；
2.如果&referer-policy&的值为default：如果当前页面使用的是&https&协议，而正要加载的资源使用的是普通的&http&协议，则将&http&header&中的&referer&置为空；
3.如果&referer-policy&的值为&origin：只发送&origin&部分；
4.如果&referer-policy&的值为&always：不改变http&header&中的&referer&的值，注意：这种情况下，如果当前页面使用了&https&协议，而要加载的资源使用的是&http&协议，加载资源的请求头中也会携带&referer。
如果页面中包含了如下 meta 标签，所有从当前页面中发起的请求将不会携带 referer：
&meta&name=&referrer&&content=&never&&
如果页面中包含了如下 meta 标签，则从当前页面中发起的 http请求将只携带 origin 部分（注：根据原文中的语境，我理解这里的 origin 是包含了 schema 和 hostname 的部分 url，不包含 path 等后面的其他 url 部分），而不是完整的 URL ：
&meta&name=&referrer&&content=&origin&&
注意：在使用本文中所述的 meta 标签的时候，浏览器原有的 referer 策略将被打破，比如从 http 协议的页面跳转到 https 的页面的时候，如果设置了适当的值，也会携带 referer。
这与 rel=noreferer 有什么关系呢？可能 rel=noreferer 会覆盖掉本文中的 meta 标签所设置的值。也就是功能覆盖。origin 信息不是一个完整的 url，所以浏览器客户端估计会在 origin 后面加一个 / 来作为 path 部分。如果 origin 是唯一的，会发生什么情况呢？估计 referer 会被忽略。
这篇文章最初写于2012年，目前在已经是废弃状态，并且已经提供了w3c 的&页面，但是，译者注意到，目前很多网站在防御 CSRF 的时候，都采用校验 referer 的方法，有时候允许 referer 为空，并且某些 BAT 厂商的重要业务在防御 JSON 劫持的时候，也采用校验 referer 的方法并允许 referer 为空，也许你会觉得本文中描述的只是一种提议，但是，FireFox 在中已经声明，从 Firefox 36 Beta 开始，将会支持 referer-policy，这无疑会让一些厂商的业务面临威胁。
[参考来源，转载请注明来自FreeBuf黑客与极客（）]
17篇文章等级：5级
这家伙太懒，还未填写个人描述！
必须您当前尚未登录。
必须（保密）
这家伙太懒，还未填写个人描述！
分享每日精选文章A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on
(such as one of ) or send an e-mail to
with your desired username and an explanation of the first edit you'd like to make. (Do not use this e-mail address for any other inquiries, as they will be ignored or politely declined.)
From WHATWG Wiki
This document is obsolete.For the current specification, see:
This document describes a proposal the "referrer" metadata name.
Using the referrer metadata attribute, a document can control the behavior if the Referer HTTP header attached to requests that originate from the document.
An author might wish to control the Referer header omitted by a document for a number of reasons.
A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands.
The social networking site might not wish to leak the user's profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).
Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user's profile contained the links.
A web application uses HTTPS and a URL-based session identifier.
The web application might wish to link to HTTPS resources on other web sites without leaking the user's session identifier in the URL.
A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive
Some web applications wish to follow an object-capability discipline.
The Referer header constitutes an ambient authority, contrary to an object-capability discipline.
Having the ability to disable the Referer header makes it easier for these web applications to follow this discipline.
Keyword: referrer
The referrer metadata attribute can have one of four values for its content attribute:
When a meta element is inserted into the document, if its name attribute is presents and matches the referrer metadata name, then the user agent must run the following algorithm:
If the meta element lacks a content attribute, abort these steps.
Let the document's referrer-policy be the value of the content attribute converted to lower case with leading and trailing LWS removed.
If the document's referrer-policy is not one of the strings listed above, replace the document's referrer-policy with the string default.
TODO: This algorithm causes the most recently added meta element to control the referrer-policy.
Should we support changing the policy by setting the content attribute?
Replace Step 3 of Fetching resources in the HTML standard [] with the following text:
Let the referrer-header-value be the document's current address of document.
Remove any &fragment& component from the referrer-header-value.
If the origin of the appropriate Document is not a scheme/host/port tuple, then replace the referrer-header-value with the empty string, regardless of its value.
If the referrer-policy is never:
Replace the referrer-header-value with the empty string, regardless of its value.
If the referrer-policy is default:
Replace the referrer-header-value with the empty string if the &scheme& component of the referrer-header-value represents a protocol that uses transport-layer security and the &scheme& component of the resource being fetched does not.
If the referrer-policy is origin:
Replace the referrer-header-value with the ASCII serialization [] of the origin' of the appropriate Document.
If the referrer-policy is always:
Do not alter the referrer-header-value.
Note: This might cause https referrers to be sent over the network as part of unencrypted HTTP requests.
Question: Do we need a always-origin value as well? As to permit websites to use the always policy while still just sending the origin? For example to enable https websites to send an origin to http websites.
In Step 5 of Fetching resources in the HTML standard [], replace the text "For the purposes of the Referer (sic) header, [...]" with the following text:
For the purposes of the Referer (sic) header, use the referrer-header-value are generated in Step 3.
TODO: We want this policy to affect resource loads done by the speculative parser.
I'm not sure the speculative parser is part of the spec's machinery, so we need to figure out how to specify its behavior...
Perhaps in an implementation consideration section?
This meta element instructs the user agent to omit the Referer header in all HTTP requests that originate from the document containing the element:
&meta name=&referrer& content=&never&&
This meta element instructs the user agent to include the document's origin in the Referer header rather than the full URL of the document:
&meta name=&referrer& content=&origin&&
Note: The user agent will include the origin string in the Referer header even for links from HTTPS to HTTP resources.
How does this interact with rel=noreferrer?
Presumably rel=noreferrer should override whatever global setting the user agent gets from the meta element.
The origin is not a canonical URL as it lacks a path. The user agent should probably just add / as path.
What should happen if the origin is unique? Presumably the referrer should be omitted in that case.使用 Referer Meta 标签控制 referer—详解 referrer-policy - 推酷
使用 Referer Meta 标签控制 referer—详解 referrer-policy
本文描述了一个关于 http 协议中 referer 的 metadata 参数的提议，使用这个 metadata 参数，html 文档可以控制 http 请求中的 referer ，比如是否发送 referer、只发送 hostname 还是发送完整的 referer 等。虽然有一些方法可以控制 referer ，比如 flash，以及一些 js 的 tricks，但是本文中描述的是另外一番景象。
在某些情况下，出于一些原因，网站想要控制页面发送给 server 的 referer 信息的情况下，可以使用这一 referer metadata 参数。
社交网站一般都会有用户个人页面，这些页面中用户都有可能添加一些外网的链接，而社交网站有可能不希望在用户点击了这些链接的时候，泄露用户页面的 URL ，因为这些 URL 中可能包含一些敏感信息。当然，有些社交网站可能只想在 referer 中提供一个 hostname，而不是完整的 URL 信息。
有些使用了 https 的网站，可能在 URL 中使用一个参数(sid 等)来作为用户身份凭证，而又需要引入其他 https 网站的资源，这种情况下，网站肯定不希望泄露用户的身份凭证信息。
Object-Capability Discipline
有些网站遵循Object-Capability Discipline，而 referer 刚好与这一策略相悖，所以，网站能够控制 refeer 将对 Object-Capability Discipline 很有利。
referer 的 metedata 参数可以设置为以下几种类型的值：
如果在文档中插入 meta 标签，并且 name 属性的值为 referer，浏览器客户端将按照如下步骤处理这个标签：
1.如果 meta 标签中没有 content 属性，则终止下面所有操作
2.将 content 的值复制给 referrer-policy ，并转换为小写
3.检查 content 的值是否为上面 list 中的一个，如果不是，则将值置为 default
上述步骤之后，浏览器后续发起 http 请求的时候，会按照 content 的值，做出如下反应(下面 referer-policy 的值即 meta 标签中 content 的值)：
1.如果 referer-policy 的值为never：删除 http head 中的 referer；
2.如果 referer-policy 的值为default：如果当前页面使用的是 https 协议，而正要加载的资源使用的是普通的 http 协议，则将 http header 中的 referer 置为空；
3.如果 referer-policy 的值为 origin：只发送 origin 部分；
4.如果 referer-policy 的值为 always：不改变http header 中的 referer 的值，注意：这种情况下，如果当前页面使用了 https 协议，而要加载的资源使用的是 http 协议，加载资源的请求头中也会携带 referer。
如果页面中包含了如下 meta 标签，所有从当前页面中发起的请求将不会携带 referer：
&meta name=&referrer& content=&never&&
如果页面中包含了如下 meta 标签，则从当前页面中发起的 http请求将只携带 origin 部分（注：根据原文中的语境，我理解这里的 origin 是包含了 schema 和 hostname 的部分 url，不包含 path 等后面的其他 url 部分），而不是完整的 URL ：
&meta name=&referrer& content=&origin&&
注意：在使用本文中所述的 meta 标签的时候，浏览器原有的 referer 策略将被打破，比如从 http 协议的页面跳转到 https 的页面的时候，如果设置了适当的值，也会携带 referer。
这与 rel=noreferer 有什么关系呢？可能 rel=noreferer 会覆盖掉本文中的 meta 标签所设置的值。也就是功能覆盖。
origin 信息不是一个完整的 url，所以浏览器客户端估计会在 origin 后面加一个 / 来作为 path 部分。
如果 origin 是唯一的，会发生什么情况呢？估计 referer 会被忽略。
这篇文章最初写于2012年，目前在
已经是废弃状态，并且已经提供了w3c 的
页面，但是，译者注意到，目前很多网站在防御 CSRF 的时候，都采用校验 referer 的方法，有时候允许 referer 为空，并且某些 BAT 厂商的重要业务在防御 JSON 劫持的时候，也采用校验 referer 的方法并允许 referer 为空，也许你会觉得本文中描述的只是一种提议，但是，FireFox 在
中已经声明，从 Firefox 36 Beta 开始，将会支持 referer-policy，这无疑会让一些厂商的业务面临威胁。
，转载请注明来自FreeBuf黑客与极客（）]
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致header头referer字段反射xss利用>>脚本渗透>>中国云安网 Www.Yunsec.Net -
热门关键字： 　　 　 　 　 　
header头referer字段反射xss利用
摘要：##伪造referer 自从flash修复伪造referer之后，目前没有已知的伪造referer的方式。 ##利用跳转 跳转存在的问题就是在chrome和firefox中，query会被URL编码，IE不会。 跳转的方式主要有 META标签内跳转 javascript跳转 header头跳转 测试方式脚本，存在漏洞的...
##伪造referer
自从flash修复伪造referer之后，目前没有已知的伪造referer的方式。
##利用跳转
跳转存在的问题就是在chrome和firefox中，query会被URL编码，IE不会。
跳转的方式主要有
META标签内跳转
javascript跳转
header头跳转
测试方式脚本，存在的页面：
&echo&'123';&echo&$_SERVER['HTTP_REFERER'];&&
在本地新建页面，代码如下，firefox中访问：
http://127.0.0.1/referer.html?&xsscode&
&window.location.href='http://www.yunsec.net/referer.php'&&
123http://127.0.0.1/referer.html?%3Cxsscode%3E
IE8中测试，发现使用.location.href跳转，不会发送referer。(本文中提到的IE都是IE8测试)，这个是IE的问题。可以通过其他的方式带上refer。这是另外一个问题了，这里不做过多讨论了，只提供一种可以利用的方式。
参考：/exploiting_xss_in_referer_header
&&&id=&xss&&name=&xss&&method=&GET&&action=&/vulnerable.php&&&&document.getElementById(&xss&).submit();&&&&
也可以使用iframe，因为iframe发出的请求是带referer的
#使用子域名和路径。
跳转的时候使用子域名或者路径承载payload，子域名没有测试，测试了下路径，IE8会对路径中的&&&进行url编码。
##使用datauri
参考：http://masatokinugawa.l0.cm/2013/10/referrer-xss.html
感谢神秘的M提供的技术翻译。如下：
IE的情况比较简单。因为IE不会对query中的&&进行Encode,所以下面的这种情况在IE是可利用的：
http://l0.cm/xss_referrer.html?&script&alert(&1&)&/script&
但是Firefox.Chrome.Safari和IE却不同。他们会对query中的&&进行Encode,进而导致不能利用。所以我在这里和大家分享一个小的技巧（我自认为，这种手法是别人应该都还没有公开过的）
data:text/html,&meta name=&referrer& content=&always&&&script&if(location.protocol!='data:'){alert(1)}else{location.href=&http://vulnerabledoma.in/location/&}&/script&
当我们在data:URL中加上&meta name=&referrer& content=&always&&这个标签时，我们就可以让正常情况下无法发送referrer的data:URL变得可以发送referrer信息了。通过这种方式呢，我们就可以在Chrome和safari下包含一个可以正常执行的&&&&了.
当然，等firefox开始支持&meta name=&referrer&&了，也许同样的方法也可以应用在firefox上面。
测试了下，最新版chrome这种方式已经不可以了。根据M的测试结果，目前，safari还是可以的。
标签分类：Meta Referrer标签：在SEO与互联网上的进阶
作者：网站分析星期三|
发表时间： 17:51:12
通过HTTPS让网络更安全给站长带来了诸多好处,除了提升网站的安全性能，HTTPS 能够为未来的网络营销技术和SEO营销人员带来潜在的益处。
HTTPS的搜索结果数量一直在攀升,Dr. Pete的“MozCast数据”显示现在谷歌首页几乎20%的搜索结果是HTTPS（下图为6月8日-6月17日谷歌首页HTTPS网站比重变化）。
然而，HTTPS仍然有它的弱点。
将常规的HTTP站点转换为HTTPS站点是营销人员遇到的首个挑战。
首先是技术上的挑战，转换通常涉及通过一系列的301重定向为你的站点规划路径。
从历史经验来说，通过这种重定向通常会因损失链接的权重而导致排名下滑（大概在15%左右）。这能抵消谷歌声称的任何SEO优点。
罗斯·哈金斯在Tweet进行了完美的总结：“HTTPS是一个影响排名的因素”，当HTTP转化为HTTPS， 链接通过301损失了权重。从HTTPS获得比付出的权重少，权重下降导致排名下降，最终导致流量的损失。
很多SEO从业者都分享过HTTPS站点在谷歌搜索结果中的良好表现的事例（并且我们即将出版的【排名因素】的数据也似乎能支持这个论点）.然而，这种大量301跳转的短期影响仍然很难去把握。近期Moz转而研究如何为转HTTPS的登入者提供更佳的安全性，我们看到我们的自然流量下降了8-9%（这里所提及“我们的自然流量”可能是指文章作者自己的网站）。
第二个问题是这篇文章的主题，它涉及了来路数据的遗失。
通常情况下，当一个站点给另一个站点传送流量时，信息被传送出去，这个初始站点被认作为流量的源头。 这些珍贵的数据让人们看到流量是从何处而来，并且有助于信息在网站之间的传播。
SEO优化人员为了实现更好的优化效果而长期使用来路数据。通常，当人们发现在他们的分析数据中有来路数据时，会链回或检查流量来源的站点。从近期通过referrer作弊的增长，我们发现黑帽SEOer已经了解了这种方法。
当流量从一个HTTPS站点到另一个安全性低的HTTP站点，Referrer标签就没有起到作用，在这种情况下，没有来路数据。站长就无法得知网站流量来源。
这是Moz转成HTTPS后，我的个人网址上referral数据的样子。看不到我网站的流量来来自哪里。我没有办法再获得来路数据了！
了解meta referrer标签
虽然我们无法解决因站点转换到HTTPS导致的排名问题，但我们能解决来路数据损失的问题，而且非常简单。
大多数市场营销人员几乎对相对新的meta referrer标签一无所知（实际上它已有些年头了），而它们被设计出来的目的就是为了帮助市场营销人员解决问题的。
更棒的是，这个标签允许你去把控你的推荐信息如何传递。
大部分浏览器中的Meta referrer标签信息的传递是由用户自定义的。流量数据被加密并且HTTPS的全部优势也依旧保留下来。但是现在你能将来路数据传递到全部网站，甚至包括那些使用HTTP的网站。
如何使用meta referrer标签
下列所述是非常精简的meta referrer标签的使用说明。为了更深入的理解，我们强烈推荐参阅W3C的说明书。
Meta referrer标签被放置在你HTML的部分，并把五种定义中的一种，控制浏览器如何发送referrer信息到你的站点。这五种定义是：
1、None：绝不允许referrer data通过
标签写法：
2、None When Downgrade：发送referrer信息去安全的HTTPS站点，而非不稳定的HTTP站点。
标签写法：
3、Origin Only: 发送协议、主机和端口（即子域）没有一个完整的URL作为来源，即/example.html只会发送
标签写法：
4、Origin When Cross-Origin: 当传origin-only来路信息发送给外部站点时，如果目标有相同的协议、主机和端口（即子域），无论它是HTTP或HTTPS，都将全部的URL作为Referrer发送出去。（注解：官方说明书上有一处排印错误，将来的版本应该是\&origin-when-cross-origin\&）
标签写法：
5、Unsafe URL: 总是将URL字串作为一个referrer通过。注意：如果你的URL中存在任何敏感信息，这不是最安全的选择。其中URL的片段、用户名、密码被自动剥去。
标签写法：
Meta referrer 标签的运转
点开如下链接，你能感知到meta referrer是如何运作。
我们为Moz将meta referrer设置为了“origin”,意味着当我们链出去另一个站点，我们通过了我们的协议、主机和端口.你会看到的最终结果是作为referrer，URL的全部路径被剥去 (/meta-referrer-tag).
我的个人站点每天能从Moz接收到数个访客，这里是在我们用过meta referrer标签前后我分析数据中体现出的情况。
为了简单与安全性，大部分站点都想使用\&origin\& 状态，但是也有缺憾。
其中一个负作用就是一旦使用meta referrer标签，我们用来作重定向的AdRoll统计就会停止工作。这证明AdRoll是用我们的referrer信息来作分析，但是mata referrer标签的\&origin\& 状态意味着被识别和报告过的URL只有。
meta referrer标签让信息流在互联网上快速传播，因此我们是喜欢它的。这应该是互联网运作所必不可少的方式。
它帮助营销人员和站长确切的看清了流量从何而来。它鼓励了互链 ，流量交换交流，甚至友链等（根据上文所提及意思，可理解为网站之间流量的交互）能最终导向SEO效果提升的因素。
苏月：目前就职于群邑搜索团队，负责文章的翻译工作。
李炜：目前就职于群邑搜索团队，负责文章的校对工作。
关于我们 ChinaWAW网站分析星期三(Web Analytics Wednesday) 是一个顶尖的互联网交流和分享的NGO平台， 同时也是国内最大的系统介绍网站分析以及互联网营销分析和优化的专业网站（www.chinawaw.org)
联系我们发送邮件至wechat@wawchina.org
长按2秒 关注我们
微信号:chinawaw
公众号回复数字编号，查看你感兴趣的文章：
1 PC站有必要吗
2 网站分析师
3 怎样学SEO
4 SEO数据化漏斗
5 免费流量
6 谷歌分析的秘密
7 网站如何优化
8 互联网人群画像
9 APP用户留存指标
10 网站分析checklist
11 百度SEO如何优化
12 百度不提供关键词数据
13 网站分析工具
15 牛逼电商运营团队
17 广告拦截
18 网站实例分析
19 虚荣指标
Y001 活动回顾
Z001 活动预告