Filtro IE8 XSS: ¿qué hace realmente?
Internet Explorer 8 tiene una nueva característica de seguridad, un filtro XSS que intenta interceptar los intentos de scripting entre sitios. Se describe de esta manera:
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 sería devuelta al sitio web atacante si la solicitud atacante se enviara sin cambios. Si la reflexión es detectado, el filtro XSS desinfecta la solicitud original para que no se pueda ejecutar el JavaScript adicional.
Estoy descubriendo que el filtro XSS se activa incluso cuando no hay "evidencia de reflexión", y estoy empezando a pensar que el filtro simplemente se da cuenta cuando se hace una solicitud a otro sitio y la respuesta contiene JavaScript.
Pero incluso eso es difícil de verificar porque el efecto parece ir y venir. IE tiene diferentes zonas, y justo cuando creo que he reproducido el problema, el filtro ya no entra, y no se por qué.
¿Alguien tiene algún consejo sobre cómo combatir esto? ¿Qué está buscando realmente el filtro? ¿Hay alguna manera de que un buen tipo PUBLIQUE datos en un sitio de terceros que pueda devolver HTML para mostrarse en un iframe y no activar el filtro?
Background: Estoy cargando una biblioteca JavaScript desde un sitio de terceros. Que JavaScript recolecta algunos datos de la página HTML actual, y los publica en el sitio de terceros, que responde con algo de HTML que se mostrará en un iframe. Para verlo en acción, visita una página AOL Food y haz clic en el icono "Imprimir" justo encima de la historia.
3 answers
¿Qué hace realmente? Permite a terceros enlazar a una versión desordenada de su sitio.
Se activa cuando [se cumplen algunas condiciones y] ve una cadena en el envío de la consulta que también existe textualmente en la página, y que cree que podría ser peligrosa.
Asume que si <script>something()</script> existe tanto en la cadena de consulta como en el código de página, entonces debe ser porque su script del lado del servidor es inseguro y refleja esa cadena directamente como marcado sin escapar.
Pero, por supuesto, aparte del hecho de que es una consulta perfectamente válida que alguien podría haber escrito que coincide por coincidencia, también es posible que coincidan porque alguien miró la página y copió deliberadamente parte de ella. Por ejemplo:
Http://www.bing.com/search?q=%3Cscript + tipo%3D%22text%2Fjavascript % 22% 3E
Siga que en IE8 y he saboteado con éxito su página de Bing por lo que va a dar errores de script, y los bits de resultado pop-out no funcionarán. Esencialmente, le da a un atacante cuyo enlace está siendo seguido una licencia para seleccionar y deshabilitar partes de la página que no le gusta, y eso incluso podría incluir otras medidas relacionadas con la seguridad como los scripts de framebuster.
¿Qué considera IE8 'potencialmente peligroso'? Mucho más y cosas mucho más extrañas que solo esta etiqueta de script. eg. Además, parece coincidir con un conjunto de plantillas 'peligrosas' que utilizan un sistema de patrones de texto (presumiblemente regex), en lugar de cualquier tipo de analizador HTML como el que eventualmente analizará la página en sí. Sí, utilice IE8 y su navegador está pařṣing HTML con expresiones regulares.
'XSS protection' mirando las cadenas en la consulta es completamente falso. No se puede "arreglar"; el mismo concepto es intrínsecamente defectuoso. Aparte del problema de intervenir cuando no se quiere, en realidad no puede protegerte de nada más que de los ataques más básicos, y los atacantes seguramente solucionarán bloques como IE8 se usa más ampliamente. Si has estado olvidando escapar de tu salida HTML correctamente, seguirás siendo vulnerable; toda la "protección" XSS tiene que ofrecerte es una falsa sensación de seguridad. Desafortunadamente, a Microsoft parece gustarle esta falsa sensación de seguridad; hay una "protección" XSS similar en ASP.NET también, en el lado del servidor.
Así que si tienes una pista sobre la creación de aplicaciones web y has estado escapando correctamente la salida a HTML como un buen chico, definitivamente, es una buena idea desactivar esta intrusión no deseada, inviable y mal dirigida al emitir el encabezado:
X-XSS-Protection: 0
En sus respuestas HTTP. (Y usar ValidateRequest="false" en tus páginas si estás usando ASP.NET.)
Para todos los demás, que todavía slings cadenas juntos en PHP sin tener cuidado de codificar correctamente... bueno, podrías dejarlo puesto. No esperes que realmente proteja a tus usuarios, pero tu sitio ya está roto, así que a quién le importa si se rompe un poco más, ¿verdad?
Para verlo en acción, visite una página de Alimentos de AOL y haga clic en el icono "Imprimir" justo encima de la historia.
Ah sí, puedo ver esta ruptura en IE8. No es inmediatamente obvio donde IE ha hecho el hackeo al contenido que ha detenido su ejecución, aunque... la única solicitud cross-domain que puedo ver que es candidata para el filtro XSS es esta a http://h30405.www3.hp.com/print/start:
POST /print/start HTTP/1.1
Host: h30405.www3.hp.com
Referer: http://recipe.aol.com/recipe/oatmeal-butter-cookies/142275?
csrfmiddlewaretoken=undefined&characterset=utf-8&location=http%253A%2F%2Frecipe.aol.com%2Frecipe%2Foatmeal-butter-cookies%2F142275&template=recipe&blocks=Dd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%28%2B.%2F%2C%28%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk%7Cpspm%3Db3%3Fd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%7D%2F%27%2B%2C.%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk...
Ese parámetro blocks continúa con páginas más galimatías. Presumiblemente hay algo allí que (por coincidencia?) se refleja en el HTML devuelto y desencadena una de las ideas desordenadas de IE8 de cómo se ve un exploit XSS.
Para solucionar esto, HP necesita hacer que el servidor en h30405.www3.hp.com incluya el encabezado X-XSS-Protection: 0.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-01-12 22:28:46
Debería enviarme (ericlaw @ microsoft) una captura de red (www.fiddlercap.com) del escenario que crees que es incorrecto.
El filtro XSS funciona de la siguiente manera:
- ¿Está habilitado XSSFILTER para este proceso?
En caso afirmativo– proceder a la siguiente comprobación Si no-bypass Filtro XSS y continuar cargando - ¿Es una carga de "documento" (como un marco, no un subdownload)? En caso afirmativo– proceder a la siguiente comprobación Si no-bypass Filtro XSS y continuar cargando
- ¿Es una solicitud HTTP/HTTPS? En caso afirmativo– proceder a la siguiente comprobación Si no-bypass Filtro XSS y continuar cargando
- ¿La RESPUESTA contiene el encabezado x-xss-protection? Sí: Valor = 1: Filtro XSS habilitado (sin verificación de urlaction) Valor = 0: Filtro XSS desactivado (sin comprobación de urlaction) No: proceder a la siguiente comprobación
- ¿Se está cargando el sitio en una Zona donde URLAction habilita el filtrado XSS? (Por defecto: Internet, De confianza, Restringido) En caso afirmativo– proceder a la siguiente comprobación Si no-bypass Filtro XSS y continuar cargando
- ¿Es una solicitud cruzada? (Encabezado de referencia: ¿El nombre de dominio completo (post-redireccionamiento) final en el encabezado de referencia de la solicitud HTTP coincide con el nombre de dominio completo de la URL que se está recuperando?) En caso afirmativo, omita el filtro XSS y continúe cargando Si no, entonces la URL en la solicitud debe ser neutralizado.
- ¿La indicación heurística de los datos de RESPUESTA proviene de DATOS de SOLICITUD inseguros? En caso afirmativo: modifique la respuesta.
Ahora, los detalles exactos de #7 son bastante complicados, pero básicamente, puedes imagine que IE hace una coincidencia de datos de solicitud (URL/Cuerpo de Post) con datos de respuesta (cuerpos de script) y si coinciden, entonces los datos de respuesta se modificarán.
En el caso de tu sitio, querrás mirar el cuerpo del POST a http://h30405.www3.hp.com/print/start y la respuesta correspondiente.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-01-12 19:47:18
En realidad, es peor de lo que parece. El filtro XSS puede hacer que los sitios seguros sean inseguros. Leer aquí: http://www.h-online.com/security/news/item/Security-feature-of-Internet-Explorer-8-unsafe-868837.html
De ese artículo:
Sin embargo, Google desactiva el filtro XSS de IE enviando el encabezado X-XSS-Protection: 0, lo que lo hace inmune.
No se lo suficiente acerca de su sitio para juzgar si esto puede ser una solución, pero probablemente puede intentarlo. Más en profundidad, la discusión técnica del filtro y cómo desactivarlo está aquí: http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-01-12 19:30:02