Reflexiones sobre los límites de XSS-Auditor, el filtro Anti-XSS de Google Chrome

Durante el trabajo de creación del libro “Hacking Web Applications: Client-Side Attacks“, Enrique Rando estuvo realizando muchas pruebas sobre los principales navegadores de Internet. Como os podéis imaginar, los filtros Anti-XSS, así como otras medidas de protección por defecto contra otros ataques “Client-Side” fueron su día a día. En este artículo nos trae sus reflexiones sobre los límites de XSS-Auditor, la herramienta de protección Anti-XSS de Google Chrome.

Figura 1: Reflexiones sobre los límites de XSS-Auditor, el filtro Anti-XSS de Google Chrome

Jugando con XSS-Auditor de Google Chrome

1.- Introducción

¡Ah, los filtros anti-XSS! Llevan ya su tiempo entre nosotros y sin embargo, siguen planteando problemas de difícil solución y alternativas sobre las que no nos ponemos de acuerdo. Aunque quizá el problema no radique tanto en los propios filtros sino en el inestable terreno en que éstos prestan sus servicios.

Porque: ¿dónde ponemos la línea roja que un filtro anti-XSS no debe permitir sobrepasar? ¿Es preferible ser súper exigentes y detener todos los ataques posibles a costa de sufrir muchos falsos positivos? ¿O es preferible asegurar el funcionamiento de las aplicaciones aunque esto suponga que de vez en cuando un ataque tenga éxito? ¿Está, como dice el refrán, la virtud en el término medio o acaso la falta de un criterio claro y definido no permitiría alcanzar ningún objetivo y sólo serviría para confundir? A veces me alegra pensar que será otro, y no yo, quien tenga que responder estas preguntas.

2.- Como saltarse XSS Auditor por menos de 6 euros

2.1.- La aplicación

Hace algún tiempo me encontré con una aplicación cuyo código tenía unas cuantas características curiosas. En ella me basé cuando escribí el siguiente código:

Figura 2: Se trata de una aplicación que te despierta a la hora que tú le digas.

Figura 3: El despertador

Analizando el código fuente se puede comprobar que existe una vulnerabilidad de XSS, explotable a través del parámetro GET “hora”. Pero XSS-Auditor impide el intento de inyectar código JavaScript en línea:

Figura 4: Bloqueado por XSS-Auditor

… o de insertar una etiqueta

… aunque el documento no sea dibujado en pantalla, los scripts previos al punto de inyección se ejecutarán y podrán interactuar con el DOM (Modelo de Objetos del Documento):

Figura 24: Los scripts previos a la inyección XSS se ejecutan

Y sólo cuando se llegue a la inyección se producirá el efecto que se habría esperado tener desde el principio.

Figura 25: A buenas horas.

Supongo que a alguien se le ocurrirá como sacar partido de esto ¿verdad?

2.5.- Para ir terminando

No es que XSS-Auditor sea una mala herramienta. Crear un filtro anti-XSS como éste es una tarea difícil y es imposible cubrir todos los posibles ataques a la vez que se intenta mantener la compatibilidad con todas esas aplicaciones que hay ahí afuera. Es que las aplicaciones deberían estar bien escritas.

Autor: Enrique Rando, escritor en en "Hacking Web Applications: SQL Injection", "Hacking con Buscadores", "Hacking Web Technologies" & "Hacking Web Applications: Client-Side Attacks".

FUENTE
Por |2017-08-28T05:40:18+00:00agosto 28th, 2017|Hacking|Sin comentarios

Deje su comentario