¿Qué es el encabezado http "X-XSS-Protection"?

So I've been toying around with HTTP for fun in telnet now (i.e. just typing in telnet google.com 80 and putting in random GETs and POSTs with different headers and the like) but I've come across something that google.com transmits in it's headers that I don't know.

He estado mirando a través de http://www.w3.org/Protocols/rfc2616/rfc2616.html and have found no definition for this particular http-header that google seems to be spouting out:

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

Alguien sabe que X-XSS-Protection ¿es?

preguntado el 01 de febrero de 12 a las 03:02

FWIW, the "correct" place to look up header field specifications is no the HTTP spec (currently RFC 2616), but the IANA message header fields registry (that being said, it's not listed over there) -

@JulianReschke, Why is that so? Shouldn't the HTTP spec be authoritative on HTTP? -

The HTTP spec delegates the header registry to IANA. -

6 Respuestas

X-XSS-Protection is a HTTP header understood by Internet Explorer 8 (and newer versions). This header lets domains toggle on and off the "XSS Filter" of IE8, which prevents some categories of XSS attacks. IE8 has the filter activated by default, but servers can switch if off by setting

   X-XSS-Protection: 0

Véase también http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx

respondido 14 mar '13, 00:03

This is very vague. Exactly cómo does this header prevent XSS? So now IE sees X-XSS-Protection:1 and then, what algorithm does it use to prevent XSS? - Pacerier

Details are hard to find because it is a proprietary technology. Essentially, IE monitors if any of the suspiciously-looking parameters that the browser sends to a website come back in the response decoded. For example, if a user clicks on attack-me.com/… (which is "><script>alert('XSS')</script>, and receives as a result a page containing that script, IE will prevent that. - Luca Invernizzi

As such, it seems to me (proof is hard to find) that it only protects against Reflected XSS (infosecisland.com/blogview/…), also because it does not have any mean to detect Stored XSS (also called Persistent XSS). - Luca Invernizzi

hmm seems like fluff around marketing by microsoft in attempt to make IE look better.... - Matej

Well, it's presented in marketing fluff, but the code seem to work. You can test it here enhanceie.com/test/xss/BlockMode.asp (also linked in the MSDN blog post). - Luca Invernizzi

  • X-XSS-Protection: 1 : Force XSS protection (useful if XSS protection was disabled by the user)

  • X-XSS-Protection: 0 : Disable XSS protection

  • El token mode=block will prevent browser (IE8+ and Webkit browsers) to render pages (instead of sanitizing) if a potential XSS reflection (= non-persistent) attack is detected.

/!\ Warning, mode=block creates a vulnerability in IE8 (MÁS INFORMACIÓN).

Más información : http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx y la http://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/


Noticias

Se recomienda tener X-XSS-Protection: 0 and use the more powerful and flexible Content-Security-Policy encabezado en su lugar.

For more information about why X-XSS-Protection No debería ser usado: ¿Qué es el encabezado http "X-XSS-Protection"?

Respondido el 27 de Septiembre de 21 a las 16:09

For the record, the IE8 bug was fixed (CVE-2009-4074) - yakatz

developer.mozilla.org/es/docs/Web/HTTP/Headers/X-XSS-Protection In this link, we can find the description of X-XSS-Protection - Maria Montenegro

Tenga en cuenta que 0 is the only safe value for this header. See stackoverflow.com/a/57802070/334451 para detalles. - Mikko Rantalainen

This response header can be used to configure a user-agent's built in reflective XSS protection. Currently, only Microsoft's Internet Explorer, Google Chrome and Safari (WebKit) support this header.

Internet Explorer 8 included a new feature to help prevent reflected cross-site scripting attacks, known as the XSS Filter. This filter runs by default in the Internet, Trusted, and Restricted security zones. Local Intranet zone pages may opt-in to the protection using the same header.

About the header that you posted in your question,

El encabezado X-XSS-Protection: 1; mode=block enables the XSS Filter. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.

In March of 2010, we added to IE8 support for a new token in the X-XSS-Protection header, mode=block.

X-XSS-Protection: 1; mode=block

When this token is present, if a potential XSS Reflection attack is detected, Internet Explorer will prevent rendering of the page. Instead of attempting to sanitize the page to surgically remove the XSS attack, IE will render only “#”.

Internet Explorer recognizes a possible cross-site scripting attack. It logs the event and displays an appropriate message to the user. The MSDN article describes how this header works.

How this filter works in IE,

More on this article, 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.

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

Web developers may wish to disable the filter for their content. They can do so by setting an HTTP header:

X-XSS-Protection: 0

More on security headers in,

respondido 21 nov., 17:15

Tenga en cuenta que X-XSS-Protection: 0 is the only safe header for this feature. For details, see stackoverflow.com/a/57802070/334451 - Mikko Rantalainen

TL; DR: All well written web sites (/apps) must emit the header X-XSS-Protection: 0 and just forget about this feature. If you want to have extra security that better user agents can provide, use a strict Content-Security-Policy cabecera.

Respuesta larga:

Encabezado HTTP X-XSS-Protection is one of those things that Microsoft introduced in Internet Explorer 8.0 (MSIE 8) that was supposed to improve security of incorrectly written web sites.

The idea is to apply some kind of heuristics to try to detect reflection XSS attack and automatically neuter the attack.

The problematic parts are "Heurística"Y"castración". The heuristics causes false positives and neutering cannot be safely done because it causes side-effects that can be used to implementar XSS attacks and side-channel data attacks on perfectly safe web sites.

The bad part is that if a web site does not emit the header X-XSS-Protection then the browser will behave as if the header X-XSS-Protection: 1 had been emitted. The worst part is that this value is the least-safe value of all possible values for this header!

For a given secure web site (that is, the site does not have reflected XSS vulnerabilities) this "XSS protection" feature permite following attacks:

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> .

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.

Currently this feature is enabled by default in MSIE, Safari and Google Chrome. This used to be enabled in Edge but Microsoft already removed this mis-feature from Edge. Mozilla Firefox never implemented this.

Ver también:

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

Respondido el 30 de junio de 21 a las 14:06

Puedes ver en esto List of useful HTTP headers.

X-XSS-Protection: This header enables the Cross-site scripting (XSS) filter built into most recent web browsers. It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.

Respondido el 18 de diciembre de 17 a las 23:12

Unfortunately, this feature causas security issues and only safe value is X-XSS-Protection: 0. Para obtener más detalles, consulte stackoverflow.com/a/57802070/334451 - Mikko Rantalainen

This header is getting somehow deprecated. You can read more about it here - Protección X-XSS

  • Chrome has removed their XSS Auditor
  • Firefox has not, and will not implement X-XSS-Protection
  • Edge has retired their XSS filter

This means that if you do not need to support legacy browsers, it is recommended that you use Content-Security-Policy without allowing unsafe-inline scripts instead.

Respondido el 24 de junio de 21 a las 10:06

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.