Si es un gurú de las pruebas de seguridad y participa una o dos veces en programas de recompensas de grandes empresas de TI, y la cantidad de XSS que ha encontrado es de decenas o incluso cientos, puede ignorar este artículo con seguridad. Si es nuevo en el tema y está empezando a estar interesado en encontrar vulnerabilidades, bienvenido en cat.
Definición
XSS (Cross-Site Scripting) es una vulnerabilidad bastante común que se puede encontrar en muchas aplicaciones web. Su esencia es bastante simple; un atacante logra inyectar código JavaScript en la página que no fue proporcionado por los desarrolladores. Este código se ejecutará cada vez que las víctimas (usuarios habituales) visiten la página de la aplicación donde se agregó este código. Y luego hay varios escenarios de desarrollo.
Primero, un atacante podrá obtener las credenciales del usuario e iniciar sesión en su cuenta.
En segundo lugar, un atacante puede, sin que la víctima lo note, redirigirlo a otra página de clonación. Esta página puede parecer completamente idéntica a la que esperaba el usuario. Pero pertenecerá al intruso. Si el usuario no nota la sustitución e ingresa algún dato sensible en esta página, es decir, datos personales, el atacante los tendrá.
El tercero ... sí, en general, se te ocurren muchas más. Casi todo lo que puede hacer JavaScript está disponible para un atacante. A continuación, veremos más de cerca uno de estos ejemplos. Mientras tanto, intentemos discutir con un poco más de detalle cómo funciona la vulnerabilidad. ¿Y por qué un atacante logra inyectar su código en la aplicación de otra persona sin acceder a su fuente?
Una pequeña advertencia. Toda la información a continuación se presenta solo con fines informativos. El evaluador debe poder probar su aplicación web en busca de vulnerabilidades. Sin embargo, es ilegal explotar las vulnerabilidades XSS en los recursos de otras personas.
Si hablamos de la legislación rusa actual, cuando un investigador prueba el producto de otra persona en busca de vulnerabilidades o ingresa a la red de otra persona sin el conocimiento y consentimiento del propietario, sus acciones pueden considerarse ilegales.
Pero volvamos a XSS.
¿Cómo funciona la vulnerabilidad?
En primer lugar, ¿cómo se las arregla exactamente para inyectar código JavaScript en una página que no existía antes? ¿Y cómo distribuye este código a otros usuarios?
Por ejemplo, puede agregar código JavaScript a un campo de entrada, el texto desde el cual se guarda y luego se muestra en la página para todos los usuarios. Este puede ser un campo para ingresar información sobre usted en una página de perfil de red social o comentarios en un foro.
El atacante ingresa texto (y para un código malicioso), que se guarda en la página. Cuando otros usuarios visitan la misma página, descargarán el JavaScript del atacante junto con el texto. En el momento de la carga, este código funcionará. Por supuesto, la vulnerabilidad solo funcionará si el texto no es seguro cuando se guarda. Hablaremos un poco más adelante sobre cómo hacer esto y por qué los desarrolladores a veces lo olvidan.
Este es solo el ejemplo más simple y obvio de dónde se puede ocultar una vulnerabilidad. A continuación, consideraremos un ejemplo más interesante en una página de demostración especialmente preparada.
Hasta entonces, sigamos adelante.
¿Por qué estos errores se encuentran a menudo en proyectos web?
La conclusión es que el navegador no puede distinguir de forma independiente el texto sin formato del texto que es código CSS, HTML o JavaScript. Intentará tratar cualquier cosa entre las etiquetas <script> como código JavaScript. Cualquier cosa entre las etiquetas <style> se considera CSS. Y todo lo que parece una etiqueta se considera código HTML.
Si un desarrollador desea que algún texto solo se vea como código, pero no lo es (es decir, el navegador no lo procesó, sino que se muestra como está), este texto debe procesarse especialmente antes de entregarlo al navegador. Este procesamiento se llama "blindaje".
En el proceso de escapar del texto en este texto, todos los especiales. los caracteres son reemplazados por sus "contrapartes" y el navegador ya sabe con certeza que es solo texto. Lo más importante es procesar el texto que viene del usuario, ya que cualquier usuario puede resultar un intruso y enviar algún código junto con el texto. Por desgracia, a veces los desarrolladores se olvidan de escapar en ciertos lugares de una aplicación web y el texto se muestra sin ningún procesamiento. Puede haber varias razones para esto.
Por ejemplo, el programador no siempre tiene en cuenta todos los lugares donde aparece en la página el texto especificado por el usuario. Además, a veces se pueden crear diferentes partes del sitio en diferentes momentos y / o por diferentes personas. En este caso, aumenta la probabilidad de error.
Otra razón puede ser que la vulnerabilidad no está en el código del propio desarrollador, sino en el código de la biblioteca que usa. Por lo general, estos son algunos marcos prefabricados para crear servicios web. En este caso, el desarrollador, por supuesto, puede que ni siquiera sospeche que al conectar este marco al proyecto, automáticamente le conecta una vulnerabilidad lista para usar.
Siempre existe ese riesgo. Sin embargo, escribir una aplicación completamente desde cero, sin utilizar ninguna biblioteca, es largo y caro hoy en día. No todas las empresas pueden permitirse desarrollar este nivel.
En este caso, toda la esperanza es para los probadores.
¿Por qué es peligrosa una vulnerabilidad XSS?
Una vez más, hablemos con más detalle sobre los peligros de una vulnerabilidad XSS. La vulnerabilidad en sí misma no es peligrosa. Se vuelve peligroso cuando un intruso lo encuentra y comienza a usarlo para sus propios fines. La explotación de una vulnerabilidad se denomina "vector de ataque". En el caso de XSS, existen bastantes vectores de ataque.
El ejemplo más simple es el robo de cookies de autorización de los usuarios de una aplicación web. La mayoría de las veces, el sitio en el que hay autorización distingue al usuario autorizado por la llamada cookie de sesión. Si no está allí, el usuario no está autorizado. Y si lo es, por el valor de esta cookie, el servidor puede distinguir a un usuario de otro.
Todas las cookies se almacenan en la computadora del usuario. Si inicio sesión como mi usuario, veré el valor de mi cookie. Y simplemente no puedo averiguar el significado de un extraño.
Lo mismo ocurre con el código JavaScript que se ejecuta en el navegador del usuario. Este código JavaScript verá el valor de la cookie del usuario en cuyo navegador se ejecuta y solo ese.
Ahora, digamos que un atacante logra inyectar código JavaScript en la página de una aplicación web. Cualquier usuario que visite ahora esta página tendrá el código JavaScript ejecutado en el navegador. Leerá el valor de la cookie de este usuario (ahora la víctima). Solo queda pasar este valor al atacante, y el trabajo está hecho. Pero, ¿cómo pasar el valor, ya que el código malicioso se ejecuta en el navegador de la víctima?
Es bastante simple. El mismo código JavaScript puede crear una solicitud AJAX al servidor remoto. Por ejemplo, a la siguiente URL: www.zloy-site.ru/stolen= { victim_cookie_value }
El dominio zloy-site pertenece al atacante de nuestro ejemplo. Todas las solicitudes que llegan a este dominio se registran en la base de datos. Al observar los parámetros de la URL, el atacante aprende los valores de las cookies de la víctima y puede usarlos para ingresar a sus cuentas.
Como comentamos anteriormente, esta no es la única razón por la que una vulnerabilidad XSS es peligrosa. Por lo tanto, en aras de la seguridad y para proteger a sus usuarios, debe poder encontrar y cerrar dichas vulnerabilidades en sus proyectos.
¿Dónde puedo encontrar XSS? ¿Cómo lidiar con ello? Página de demostración con ejemplo
En primer lugar, vale la pena verificar las vulnerabilidades XSS en aquellos lugares del sitio en los que un usuario común tiene la oportunidad de influir en el contenido. Si puede agregar texto en alguna parte, también puede intentar agregar código JavaScript.
Veamos esto con un ejemplo específico. Preparé una caja de arena muy simple donde se escondía la vulnerabilidad XSS. Sugiero intentar encontrarlo juntos.
Abriendo la caja de arena: https://playground.learnqa.ru/demo/xss
Primero, veamos cómo funciona la página. Es esencialmente un catálogo de libros muy simple que se puede buscar. Si ingresamos “Ray Bradbury” en la consulta, veremos todos los libros que están en este directorio de este autor.
Un usuario atento ya ha notado que el texto que ingresamos en el campo de búsqueda terminó inmediatamente en la URL. Este momento todavía nos es útil.
Por ahora, intentemos insertar algunas tonterías en el cuadro de búsqueda: "fwefewf".
Veremos que en este caso no se encontró nada en la página. Y el texto de la solicitud se repitió en el texto de error:
Entonces, tú y yo encontramos el lugar donde aparece el texto ingresado por nosotros. Por lo tanto, este es un sitio potencial para una vulnerabilidad XSS. Intentemos insertar el código JavaScript más popular para comprobar si existe una vulnerabilidad.
<script> alert (123) </script>
Si la página es vulnerable, después de ingresar este código, aparecerá la siguiente ventana en la página:
Significará que nuestro código JavaScript se ha ejecutado y hemos encontrado una vulnerabilidad XSS.
Entonces, ingresamos el código y vemos la siguiente advertencia:
El formulario no nos permite buscar por tal valor, ya que el formulario está validado y quiere trabajar solo con letras y números. A primera vista, parece que el desarrollador tuvo todo en cuenta y protegió la página de XSS, pero esto no es del todo cierto.
¿Recuerda, justo arriba, notamos que el texto que ingresamos en el campo de búsqueda se muestra en la URL en el llamado parámetro GET? El nombre de este parámetro es "q", y el valor es lo que ingresamos en el campo de búsqueda. Esto se hace para que pueda copiar la URL junto con esta misma cadena de búsqueda y la próxima vez abra la página con los autores correctos de inmediato.
Por ejemplo, esta URL abrirá inmediatamente una página con solo los libros de Ray Bradbury: playground.learnqa.ru/demo/xss?q=Ray+Bradbury
A diferencia del formulario, el desarrollador no pudo realizar la validación de la URL; cualquier usuario puede ingresar cualquier URL en su navegador. lo que quiera, incluso con cualquier valor del parámetro GET. La tarea del desarrollador en este caso es no olvidar tener en cuenta todas las opciones y escribir el manejador correcto para el valor de este parámetro GET.
Comprobemos si nuestro desarrollador se olvidó de tenerlo todo en cuenta aquí. Intentemos sustituir el mismo código JavaScript en el parámetro "q" GET: https://playground.learnqa.ru/demo/xss?q= <script> alert (123) </script>
Después de hacer clic en esta URL, vemos que apareció una ventana en la página con el valor 123. ¿Pero por qué?
Es bastante simple. ¿Recuerda que cuando un sitio no puede encontrar los libros que necesita para una consulta de búsqueda determinada, muestra el texto de esta consulta en el texto de un error? Como, no encontré nada para la consulta "bla, bla". En lugar de este "bla, bla", ahora tenemos un código JavaScript con una alerta. El desarrollador escribió una validación para el campo de entrada y decidió que así era como protegía el sitio para que no se incluyera JavaScript en la consulta de búsqueda. Y no escapó al texto de error. Pudimos omitir la validación a través de la URL cambiando el valor de la consulta de búsqueda allí.
Por el bien de su interés, ahora podemos mostrar el valor de nuestra cookie de sesión, para esto, en lugar de <script> alert () </script>, necesita sustituir otro código en la URL: <script> alert (document.cookie) </script>
Te dejaré jugar con esto usted mismo. :)
Habiendo encontrado un error, debe comunicarse con los desarrolladores, ellos lo solucionarán.
Hay muchas formas de cerrar el error. Escapar del texto no es el único. También puede evitar que el propio JavaScript vea algunas cookies. Para ello, la cookie tiene un parámetro especial “solo http”. Si está configurado en TRUE, JavaScript no podrá descubrir que tal cookie se ha configurado y no podrá leerla y transferirla a un atacante incluso si puede encontrar XSS en su proyecto.
Todo esto es solo una lista pequeña, lejos de ser completa, de manipulaciones para prevenir vulnerabilidades XSS. Como se indicó anteriormente, si se detecta XSS durante la prueba, es mejor hablar con los programadores.
Si está interesado en saber más sobre las pruebas de seguridad, desea comprender mejor la estructura de la arquitectura cliente-servidor, comprender y perfeccionar las formas más efectivas de encontrar vulnerabilidades en una aplicación web real, venga a mi curso "Pruebas de seguridad". Toda la información que necesitas está en mi perfil.
Solo le espera una teoría útil y necesaria sin agua y una gran cantidad de ejemplos prácticos y tareas. Explorará muchas páginas web repletas de una variedad de vulnerabilidades. El trabajo final será un gran estudio de su proyecto de trabajo o de una de las aplicaciones web de gigantes como Google, Facebook, Twitter, etc.