What is the http-header "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.
I've been looking through 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
Anyone know what X-XSS-Protection
is?
Solution 1:
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
See also http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx
Solution 2:
-
X-XSS-Protection: 1
: Force XSS protection (useful if XSS protection was disabled by the user) -
X-XSS-Protection: 0
: Disable XSS protection -
The 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 (more info).
More information : http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx and http://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/
Update
It is recommended to have X-XSS-Protection: 0
and use the more powerful and flexible Content-Security-Policy
header instead.
For more information about why X-XSS-Protection
should not be used: What is the http-header "X-XSS-Protection"?
Solution 3:
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,
The header 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.
Source: 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,
Guidelines for Setting Security Headers
Security HTTP Headers - X-XSS-PROTECTION
MDN Docs X-XSS-Protection