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

Así que he estado jugando con HTTP por diversión en telnet ahora (es decir, simplemente escribiendo telnet google.com 80y colocando GET y POST aleatorios con diferentes encabezados y similares), pero me encontré con algo que google.com transmite en sus encabezados que yo no lo se

He estado buscando en http://www.w3.org/Protocols/rfc2616/rfc2616.html y no he encontrado ninguna definición para este encabezado http en particular que Google parece estar diciendo:

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 lo que X-XSS-Protectiones?

X-XSS-Protection es un encabezado HTTP entendido por Internet Explorer 8 (y versiones más recientes). Este encabezado permite que los dominios activen y desactiven el "Filtro XSS" de IE8, lo que evita algunas categorías de ataques XSS. IE8 tiene el filtro activado por defecto, pero los servidores pueden apagarse si se configuran

   X-XSS-Protection: 0

Ver 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

• X-XSS-Protection: 1 : Fuerza de protección XSS (útil si el usuario deshabilitó la protección XSS)

• X-XSS-Protection: 0 : Deshabilitar la protección XSS

• El token mode=blockevitará que el navegador (IE8 + y los navegadores Webkit) muestren páginas (en lugar de desinfectar) si se detecta un posible ataque de reflexión XSS (= no persistente).

/! \ Advertencia, mode=blockcrea una vulnerabilidad en 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 http://blog.veracode.com / 2014/03 / Guidelines-for-setting-security-headers /

Este encabezado de respuesta se puede utilizar para configurar la protección XSS reflectante integrada de un agente de usuario. Actualmente, solo Internet Explorer, Google Chrome y Safari (WebKit) de Microsoft admiten este encabezado.

Internet Explorer 8 incluye una nueva característica para ayudar a prevenir ataques de secuencias de comandos entre sitios reflejados, conocido como el filtro XSS . Este filtro se ejecuta de manera predeterminada en las zonas de seguridad de Internet, Confiable y Restringido. Las páginas de la zona de Intranet local pueden optar por la protección utilizando el mismo encabezado.

Sobre el encabezado que publicó en su pregunta,

El encabezado X-XSS-Protection: 1; mode=blockhabilita el filtro XSS. En lugar de desinfectar la página, cuando se detecta un ataque XSS, el navegador evitará la representación de la página.

En marzo de 2010, agregamos compatibilidad con IE8 para un nuevo token en el encabezado X-XSS-Protection, mode = block.

X-XSS-Protection: 1; mode=block

Cuando este token está presente, si se detecta un posible ataque XSS Reflection, Internet Explorer evitará la representación de la página. En lugar de intentar desinfectar la página para eliminar quirúrgicamente el ataque XSS, IE mostrará solo "#".

Internet Explorer reconoce un posible ataque de secuencias de comandos entre sitios. Registra el evento y muestra un mensaje apropiado al usuario. El artículo de MSDN describe cómo funciona este encabezado.

Cómo funciona este filtro en IE ,

Más sobre este artículo, https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

El filtro XSS funciona como un componente IE8 con visibilidad en todas las solicitudes / respuestas que fluyen a través del navegador. Cuando el filtro descubre XSS probable en una solicitud de sitios cruzados, identifica y neutraliza el ataque si se reproduce en la respuesta del servidor. A los usuarios no se les presentan preguntas que no pueden responder: IE simplemente bloquea la ejecución del script malicioso.

Con el nuevo filtro XSS, los usuarios de IE8 Beta 2 que encuentren un ataque XSS tipo 1 verán una notificación como la siguiente:

Notificación de ataque IE8 XSS

La página ha sido modificada y el ataque XSS está bloqueado.

En este caso, el filtro XSS ha identificado un ataque de secuencias de comandos entre sitios en la URL. Ha neutralizado este ataque cuando el guión identificado se volvió a reproducir en la página de respuesta. De esta manera, el filtro es efectivo sin modificar una solicitud inicial al servidor o bloquear una respuesta completa.

El evento Filtro de secuencias de comandos entre sitios se registra cuando Windows Internet Explorer 8 detecta y mitiga un ataque de secuencias de comandos entre sitios (XSS). Los ataques de secuencias de comandos entre sitios se producen cuando un sitio web, generalmente malicioso, inyecta (agrega) código JavaScript en solicitudes legítimas a otro sitio web. La solicitud original generalmente es inocente, como un enlace a otra página o un script de Interfaz de puerta de enlace común (CGI) que proporciona un servicio común (como un libro de visitas). El script inyectado generalmente intenta acceder a información o servicios privilegiados que el segundo sitio web no pretende permitir. La respuesta o la solicitud generalmente refleja los resultados al sitio web malicioso. El filtro XSS, una característica nueva de Internet Explorer 8, detecta JavaScript en las solicitudes URL y HTTP POST. Si se detecta JavaScript, el filtro XSS busca evidencia de reflexión, información que se devolvería al sitio web atacante si la solicitud atacante se presentara sin cambios. Si se detecta reflexión, el filtro XSS desinfecta la solicitud original para que no se pueda ejecutar el JavaScript adicional. El filtro XSS luego registra esa acción como un evento de filtro de secuencia de comandos entre sitios. La siguiente imagen muestra un ejemplo de un sitio que se modifica para evitar un ataque de secuencias de comandos entre sitios.

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

Los desarrolladores web pueden deshabilitar el filtro para su contenido. Pueden hacerlo configurando un encabezado HTTP:

X-XSS-Protection: 0

Más sobre encabezados de seguridad en,

• Pautas para configurar encabezados de seguridad

• Encabezados HTTP de seguridad - X-XSS-PROTECTION

• MDN Docs X-XSS-Protection

Puede ver en esta Lista de encabezados HTTP útiles .

Protección X-XSS: este encabezado habilita el filtro de secuencias de comandos entre sitios (XSS) integrado en los navegadores web más recientes. Por lo general, está habilitado de manera predeterminada, por lo que la función de este encabezado es volver a habilitar el filtro para este sitio web en particular si el usuario lo deshabilitó. Este encabezado es compatible con IE 8+ y Chrome (no estoy seguro de qué versiones). El filtro anti-XSS se agregó en Chrome 4. No se sabe si esa versión cumplió con este encabezado.

TL; DR: Todos los sitios web (/ aplicaciones) bien escritos tienen que emitir encabezado X-XSS-Protection: 0y simplemente olvidarse de esta característica. Si desea tener seguridad adicional que los mejores agentes de usuario pueden proporcionar, use un Content-Security-Policyencabezado estricto .

Respuesta larga:

El encabezado HTTP X-XSS-Protectiones una de esas cosas que Microsoft introdujo en Internet Explorer 8.0 (MSIE 8) que supuestamente mejoraría la seguridad de los sitios web escritos incorrectamente.

La idea es aplicar algún tipo de heurística para tratar de detectar el ataque de reflexión XSS y neutralizar automáticamente el ataque.

La parte problemática de esto es "heurística" y "castración". La heurística causa falsos positivos y la esterilización no se puede realizar de manera segura porque causa efectos secundarios que se pueden usar para implementar ataques XSS y ataques DoS en sitios web perfectamente seguros.

Lo malo es que si un sitio web no emite el encabezado X-XSS-Protection, el navegador se comportará como si el encabezado X-XSS-Protection: 1hubiera sido emitido. ¡La peor parte es que este valor es el valor menos seguro de todos los valores posibles para este encabezado!

Para un sitio web seguro dado (es decir, el sitio no tiene vulnerabilidades XSS de reflexión), esta característica de "protección XSS" permite los siguientes ataques:

X-XSS-Protection: 1permite al atacante bloquear selectivamente partes de JavaScript y mantener el resto de los scripts en ejecución. Esto es posible porque la heurística de esta característica es simplemente "si el valor de cualquier parámetro GET se encuentra en la parte de secuencia de comandos de la fuente de la página, la secuencia de comandos se modificará automáticamente de forma dependiente del agente de usuario". En la práctica, el atacante puede, por ejemplo, agregar parámetros disablexss=<script src="framebuster.js"y el navegador eliminará automáticamente la cadena <script src="framebuster.js"de la fuente de la página real. Tenga en cuenta que el resto de la página continúa ejecutándose y el atacante acaba de eliminar esta parte de la seguridad de la página. En la práctica, cualquier JS en la fuente de la página puede modificarse. En algunos casos, una página sin vulnerabilidad XSS que tenga contenido reflejado se puede usar para ejecutar JavaScript seleccionado en la página debido a la esterilizaciónconvertir incorrectamente datos de texto sin formato en código JavaScript ejecutable .

X-XSS-Protection: 1; mode=blockpermite al atacante filtrar datos de la fuente de la página utilizando el comportamiento de la página como canal lateral. Por ejemplo, si la página contiene código JavaScript a lo largo de las líneas de var csrf_secret="521231347843", el atacante simplemente agrega un parámetro adicional, por ejemplo, leak=var%20csrf_secret="3y si la página NO está bloqueada, el 3primer dígito era incorrecto. El atacante lo intenta nuevamente, esta vez leak=var%20csrf_secret="5y la carga de la página se cancelará. Esto le permite al atacante saber que el primer dígito del secreto es 5. El atacante continúa adivinando el siguiente dígito.

Al final, si su sitio está lleno de ataques de reflexión XSS, el uso del valor predeterminado de 1reducirá un poco la superficie de ataque. Sin embargo, si su sitio es seguro y no emite X-XSS-Protection: 0, su sitio será vulnerable con cualquier navegador que admita esta función. Si desea un soporte de defensa en profundidad de los navegadores contra vulnerabilidades XSS aún desconocidas en su sitio, use un Content-Security-Policyencabezado estricto . Eso no abre su sitio a vulnerabilidades conocidas.

Actualmente, esta función está habilitada de forma predeterminada en MSIE, Safari y Google Chrome. Esto solía estar habilitado en Edge, pero Microsoft ya eliminó esta característica errónea de Edge . Mozilla Firefox nunca implementó esto.

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