Tipos de ataques XSS, clases, variantes. Los ataques XSS generalmente se pueden clasificar en dos categorías: almacenados y reflejados. Hay un tercer tipo de ataque XSS, mucho menos conocido, llamado DOM Based XSS, que se trata por separado aquí .
Ataques XSS almacenados
Los ataques almacenados son aquellos en los que el script inyectado se almacena permanentemente en los servidores de destino, como en una base de datos, en un foro de mensajes, registro de visitantes, campo de comentarios, etc. La víctima luego recupera el script malicioso del servidor cuando solicita el almacenamiento almacenado. información. El XSS almacenado también se denomina a veces XSS persistente o tipo I.
La vulnerabilidad XSS persistente (o almacenada ) es una variante más devastadora de una falla de secuencias de comandos entre sitios: se produce cuando el servidor guarda los datos proporcionados por el atacante y luego los muestra de forma permanente en las páginas «normales» devueltas a otros usuarios en El curso de la navegación regular, sin mostrar un HTML adecuado. Un ejemplo clásico de esto es con los tableros de mensajes en línea donde los usuarios pueden publicar mensajes en formato HTML para que otros usuarios puedan leerlos.
Por ejemplo, supongamos que hay un sitio web de citas donde los miembros escanean los perfiles de otros miembros para ver si parecen interesantes. Por razones de privacidad, este sitio oculta el nombre real y el correo electrónico de todos. Estos se mantienen en secreto en el servidor. La única vez que el nombre real y el correo electrónico de un miembro están en el navegador es cuando el miembro ha iniciado sesión y no puede ver a nadie más.
Supongamos que Daniel José, un atacante, se une al sitio y quiere averiguar los nombres reales de las personas que ve en el sitio. Para ello, se escribe un guión diseñado para ejecutarse desde los navegadores de otras personas cuando ellos visitan su perfil. El script luego envía un mensaje rápido a su propio servidor, que recopila esta información.
Para hacer esto, para la pregunta «Describa su primera cita ideal», Daniel José da una respuesta corta (para que parezca normal) pero el texto al final de su respuesta es su guión para robar nombres y correos electrónicos. Si el script está incluido dentro de un elemento Script.no se mostrará en la pantalla. Entonces, supongamos que Christian Eduardo, un miembro del sitio de citas, alcanza el perfil de Daniel José, que tiene su respuesta a la pregunta de la Primera cita. Su script es ejecutado automáticamente por el navegador y roba una copia del nombre real de Christian Eduardo y del correo electrónico directamente desde su propia máquina.
Las vulnerabilidades persistentes de XSS pueden ser más significativas que otros tipos porque el script malicioso de un atacante se procesa automáticamente, sin la necesidad de atacar individualmente a las víctimas o atraerlas a un sitio web de terceros. Particularmente en el caso de los sitios de redes sociales, el código se diseñaría aún más para auto-propagarse a través de las cuentas, creando un tipo de gusano del lado del cliente.
Los métodos de inyección pueden variar mucho; en algunos casos, es posible que el atacante ni siquiera tenga que interactuar directamente con la funcionalidad web para explotar ese agujero. Cualquier dato recibido por la aplicación web (por correo electrónico, registros del sistema, mensajería instantánea, etc.) que pueda ser controlado por un atacante podría convertirse en un vector de inyección.
Ataques XSS reflejados
Los ataques reflejados son aquellos en los que el script inyectado se refleja fuera del servidor web, como en un mensaje de error, resultado de búsqueda o cualquier otra respuesta que incluya parte o toda la entrada enviada al servidor como parte de la solicitud. Los ataques reflejados se envían a las víctimas a través de otra ruta, como en un mensaje de correo electrónico o en algún otro sitio web. Cuando se engaña a un usuario para que haga clic en un enlace malicioso, envíe un formulario especialmente diseñado o simplemente navegue a un sitio malicioso, el código inyectado viaja al sitio web vulnerable, que refleja el ataque al navegador del usuario. El navegador ejecuta el código porque proviene de un servidor «confiable». El XSS reflejado también se conoce a veces como XSS no persistente o tipo II.
La vulnerabilidad de secuencias de comandos entre sitios no persistente (o reflejada ) es, con mucho, el tipo más básico de vulnerabilidad web. Estos agujeros se muestran cuando los datos proporcionados por un cliente web, más comúnmente en los parámetros de consulta HTTP (por ejemplo, envío de formularios HTML), son utilizados inmediatamente por los scripts del lado del servidor para analizar y mostrar una página de resultados para y para ese usuario , sin desinfectar adecuadamente la solicitud.
Debido a que los documentos HTML tienen una estructura en serie plana que combina declaraciones de control, formato y el contenido real, cualquier dato no validado suministrado por el usuario incluido en la página resultante sin la codificación HTML adecuada, puede llevar a una inyección de marcado.
Un ejemplo clásico de un vector potencial es un motor de búsqueda en el sitio: si uno busca una cadena, la cadena de búsqueda normalmente se volverá a mostrar en forma literal en la página de resultados para indicar qué se buscó. Si esta respuesta no escapa o rechaza correctamente los caracteres de control HTML, se producirá una falla de secuencias de comandos entre sitios.
Un ataque reflejado normalmente se entrega a través de correo electrónico o un sitio web neutral. El cebo es una URL de apariencia inocente, que apunta a un sitio de confianza pero que contiene el vector XSS. Si el sitio de confianza es vulnerable al vector, hacer clic en el enlace puede hacer que el navegador de la víctima ejecute el script inyectado.
Otros tipos de vulnerabilidades de XSS
Además de XSS almacenado y reflejado, otro tipo de XSS, XSS basado en DOM fue identificado por Amit Klein en 2005 .
Históricamente, las vulnerabilidades de XSS se encontraron por primera vez en aplicaciones que realizaban todo el procesamiento de datos en el lado del servidor. La entrada del usuario (incluido un vector XSS) se enviará al servidor y luego se enviará al usuario como una página web. La necesidad de una experiencia de usuario mejorada resultó en la popularidad de las aplicaciones que tenían la mayoría de la lógica de presentación (tal vez escrita en JavaScript ) trabajando en el lado del cliente que extraía los datos, a pedido, del servidor utilizando AJAX .
Como el código JavaScript también estaba procesando la entrada del usuario y representándola en el contenido de la página web, comenzó a aparecer una nueva subclase de ataques XSS reflejados que se denominó secuencias de comandos entre sitios basadas en DOM . En un ataque XSS basado en DOM, los datos maliciosos no tocan el servidor web. Más bien, se refleja en el código JavaScript, completamente en el lado del cliente.
Un ejemplo de una vulnerabilidad XSS basada en DOM es el error encontrado en 2011 en varios complementos de JQuery . Las estrategias de prevención para ataques XSS basados en DOM incluyen medidas muy similares a las estrategias de prevención XSS tradicionales pero implementadas en código JavaScript y contenidas en páginas web (es decir, validación de entrada y escape). Algunos marcos de JavaScript tienen contramedidas incorporadas contra este y otros tipos de ataques, por ejemplo, Angular.js .
Auto-XSS
Self-XSS es una forma de vulnerabilidad XSS que se basa en la ingeniería social para engañar a la víctima para que ejecute un código JavaScript malicioso en su navegador. Aunque técnicamente no es una verdadera vulnerabilidad XSS debido al hecho de que depende de la ingeniería social de un usuario para que ejecute el código en lugar de una falla en el sitio web afectado que permite que un atacante lo haga, todavía presenta los mismos riesgos que una vulnerabilidad XSS regular si correctamente ejecutado.
XSS mutado (mXSS)
El XSS mutado ocurre cuando el atacante inyecta algo que parece seguro, pero que el navegador reescribe y modifica, mientras analiza el marcado. Esto hace que sea extremadamente difícil detectar o sanear dentro de la lógica de la aplicación de sitios web. Un ejemplo es reequilibrar las comillas no cerradas o incluso agregar comillas a los parámetros sin comillas en los parámetros de la familia de fuentes CSS.
Leer también: Descripción de los ataques XSS ; Cómo funcionan los ataques XSS ; Que son los ataques XSS, vulnerabilidades; definición, significado
This post is also available in:
Español
