所以我一直在玩HTTP的乐趣telnet现在(即只是输入telnet google.com 80,并输入随机的get和post与不同的头之类的),但我遇到了一些东西,google.com传输在它的头,我不知道。

我一直在看http://www.w3.org/Protocols/rfc2616/rfc2616.html,并没有发现这个特殊的http-header的定义,谷歌似乎是喷涌而出:

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 01 Feb 2012 03:42:24 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6ddbc0a0342e7e63:FF=0:TM=1328067744:LM=1328067744:S=4d4farvCGl5Ww0C3; expires=Fri, 31-Jan-2014 03:42:24 GMT; path=/; domain=.google.com
Set-Cookie: NID=56=PgRwCKa8EltKnHS5clbFuhwyWsd3cPXiV1-iXzgyKsiy5RKXEKbg89gWWpjzYZjLPWTKrCWhOUhdInOlYU56LOb2W7XpC7uBnKAjMbxQSBw1UIprzw2BFK5dnaY7PRji; expires=Thu, 02-Aug-2012 03:42:24 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

1000

有人知道X-XSS-Protection是什么吗?


X-XSS-Protection是Internet Explorer 8(及更新版本)可以理解的HTTP报头。 这个报头允许域打开和关闭IE8的“XSS过滤器”,以防止某些类别的XSS攻击。 IE8在默认情况下激活了过滤器,但服务器可以通过设置将其关闭

   X-XSS-Protection: 0

参见http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx


更新后的反应

建议使用X-XSS-Protection: 0,并使用更强大、更灵活的Content-Security-Policy报头。

有关为什么不应该使用X-XSS-Protection的更多信息:什么是http头“X-XSS-Protection”?


过时的反应

X-XSS-Protection: 1:强制XSS保护(如果用户禁用XSS保护,则有用) X-XSS-Protection: 0:关闭XSS保护 如果检测到潜在的XSS反射(=非持久)攻击,令牌模式=块将阻止浏览器(IE8+和Webkit浏览器)呈现页面(而不是清除)。

/ !\警告,模式=块创建一个漏洞在IE8(更多信息)。

更多信息:http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx和http://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/


此响应标头可用于配置用户代理内置的反射XSS保护。目前,只有微软的Internet Explorer,谷歌Chrome和Safari (WebKit)支持此标头。

Internet Explorer 8包含了一项新功能,可以帮助防止反射的跨站点脚本攻击,即XSS筛选器。默认情况下,此筛选器在Internet、受信任和受限安全区域中运行。本地Intranet区域页面可以使用相同的头部选择加入保护。

关于你在问题中发布的标题,

头部X-XSS-Protection: 1;mode=block启用XSS过滤器。当检测到XSS攻击时,浏览器不会清除页面,而是会阻止页面的呈现。

在2010年3月,我们为IE8添加了一个新的令牌支持 保护头,mode=block。

X-XSS-Protection: 1; mode=block

当存在此令牌时,如果存在潜在的XSS反射攻击 检测到,Internet Explorer将阻止页面的呈现。 而不是试图消毒页面,以外科手术删除 XSS攻击,IE只会渲染“#”。 Internet Explorer识别出可能的跨站点脚本攻击。 它记录事件并向用户显示适当的消息。的 MSDN文章描述了这个头是如何工作的。

这个过滤器在IE中是如何工作的,

更多关于本文的信息,请访问https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing. With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification like the following: IE8 XSS Attack Notification The page has been modified and the XSS attack is blocked. In this case, the XSS Filter has identified a cross-site scripting attack in the URL. It has neutered this attack as the identified script was replayed back into the response page. In this way, the filter is effective without modifying an initial request to the server or blocking an entire response. The Cross-Site Scripting Filter event is logged when Windows Internet Explorer 8 detects and mitigates a cross-site scripting (XSS) attack. Cross-site scripting attacks occur when one website, generally malicious, injects (adds) JavaScript code into otherwise legitimate requests to another website. The original request is generally innocent, such as a link to another page or a Common Gateway Interface (CGI) script providing a common service (such as a guestbook). The injected script generally attempts to access privileged information or services that the second website does not intend to allow. The response or the request generally reflects results back to the malicious website. The XSS Filter, a feature new to Internet Explorer 8, detects JavaScript in URL and HTTP POST requests. If JavaScript is detected, the XSS Filter searches evidence of reflection, information that would be returned to the attacking website if the attacking request were submitted unchanged. If reflection is detected, the XSS Filter sanitizes the original request so that the additional JavaScript cannot be executed. The XSS Filter then logs that action as a Cross-Site Script Filter event. The following image shows an example of a site that is modified to prevent a cross-site scripting attack.

来源:https://msdn.microsoft.com/en-us/library/dd565647 (v = vs.85) . aspx

Web开发人员可能希望禁用其内容的过滤器。他们可以通过设置HTTP报头来实现:

X-XSS-Protection: 0

关于安全头的更多信息,

设置安全报头的指导原则 安全HTTP头- x - xss保护 MDN Docs X-XSS-Protection


你可以在这个列表中看到有用的HTTP头。

X-XSS-Protection:这个报头允许跨站点脚本(XSS)过滤器内置在最新的web浏览器中。它通常在默认情况下是启用的,所以这个头的作用是重新启用这个特定网站的过滤器,如果它被用户禁用了。IE 8+和Chrome(不确定是哪个版本)都支持这个头。Chrome 4中增加了抗xss过滤器。不知道那个版本是否尊重这个头文件。


TL;DR:所有写得好的网站(/应用程序)都必须发出头部X-XSS-Protection: 0,忘记这个功能吧。如果您希望拥有更好的用户代理能够提供的额外安全性,请使用严格的Content-Security-Policy报头。

长一点的回答:

HTTP报头X-XSS-Protection是微软在Internet Explorer 8.0 (MSIE 8)中引入的功能之一,旨在提高错误书写网站的安全性。

其思想是应用某种启发式方法来检测反射XSS攻击并自动消除攻击。

有问题的部分是“启发式”和“绝育”。启发式会导致误报和绝杀不能安全地完成,因为它会导致副作用,可以用于在完全安全的网站上实现XSS攻击和侧通道数据攻击。

不好的部分是,如果一个网站没有发出X-XSS-Protection头,那么浏览器就会表现得好像发出了X-XSS-Protection: 1头。最糟糕的是,这个值是这个头的所有可能值中最不安全的值!

对于一个给定的安全网站(也就是说,该网站没有反映XSS漏洞),这种“XSS保护”特性允许以下攻击:

X-XSS-Protection: 1 allows attacker to selectively block parts of JavaScript and keep rest of the scripts running. This is possible because the heuristics of this feature are simply "if value of any GET parameter is found in the scripting part of the page source, the script will be automatically modified in user agent dependant way". In practice, the attacker can e.g. add query parameter ?disablexss=<script%20src="framebuster.js" and the browser will automatically remove the string <script src="framebuster.js" from the actual page source. Note that the rest of the page continues execute JavaScript and the attacker just selectively removed this part of page security. In practice, any JS in the page source can be modified. For some cases, a page without XSS vulnerability having reflected content can be used to run selected JavaScript on page due the neutering incorrectly turning plain text data into executable JavaScript code. (That is, turn textual data within a normal DOM text node into content of <script> tag and execute it!)

X-XSS-Protection: 1; mode=block allows attacker to leak data from the page source by using the behavior of the page as a side-channel. For example, if the page contains JavaScript code along the lines of var csrf_secret="521231347843", the attacker simply adds an extra parameter e.g. leak=var%20csrf_secret="3 and if the page is NOT blocked, the 3 was incorrect first digit. The attacker tries again, this time leak=var%20csrf_secret="5 and the page loading will be aborted. This allows the attacker to know that the first digit of the secret is 5. The attacker then continues to guess the next digit. This allows easily brute-forcing of CSRF secrets one digit at a time or any other secret value in the <script> source.

In the end, if your site is full of XSS reflection attacks, using the default value of 1 will reduce the attack surface a little bit. However, if your site is secure and you don't emit X-XSS-Protection: 0, your site will be vulnerable with any browser that supports this feature. If you want defense in depth support from browsers against yet-unknown XSS vulnerabilities on your site, use a strict Content-Security-Policy header and keep sending 0 for this mis-feature. That doesn't open your site to any known vulnerabilities.

目前该功能在MSIE, Safari和谷歌Chrome默认启用。这曾经在Edge中启用,但微软已经从Edge中删除了这一错误功能。Mozilla Firefox从未实现此功能。

参见:

https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html https://blog.innerht.ml/the-misunderstood-x-xss-protection/ http://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf https://www.slideshare.net/masatokinugawa/xxn-en https://bugs.chromium.org/p/chromium/issues/detail?id=396544 https://bugs.chromium.org/p/chromium/issues/detail?id=498982


这个头在某种程度上被弃用了。你可以在这里阅读更多关于它- X-XSS-Protection

Chrome已经删除了他们的XSS审计 Firefox还没有,将来也不会实现X-XSS-Protection Edge已经淘汰了他们的XSS过滤器

这意味着如果您不需要支持传统浏览器,那么它就是 建议您在不允许的情况下使用内容安全策略 而是使用不安全的内联脚本。