Cross-Site Scripting: amenazas a las aplicaciones web
introducir
La salida HTML utilizada para crear el front-end de una aplicación web generalmente contiene algún código ejecutable del lado del cliente. Este código se ejecuta en el lado del cliente para ayudar a mejorar el rendimiento y realizar validaciones comunes en el lado del cliente. Otro uso para este código podría ser mostrar una «imagen caliente», que es una imagen al pasar el mouse sobre el lado del cliente.
Para lograr esto, hay muchas tecnologías populares disponibles, como JavaScript, VBScript, secuencias de comandos ECMA (Asociación Europea de Fabricantes de Computadoras). Todos estos scripts se ejecutan en el navegador del usuario final y brindan contenido dinámico al sitio.Podemos especificar código de secuencia de comandos para estar en línea o usar src documento(
pregunta
El problema es la mezcla de datos y código.Podemos decir que HTML son datos para el navegador, y cuando el navegador procesa estos datos, produce un hermoso HTML, pero y luego la etiqueta de título en lugar de mostrar:
tu búsqueda Devuelve los siguientes resultados:
ejecutará el script y un cuadro de mensaje Hola aparecerá allí. Ahora, si un usuario malintencionado envía una URL (que es fácil de obtener aquí porque esta página usa el método GET) a alguna víctima, este cuadro de mensaje aparecerá en su navegador.
Tipos de ataques de secuencias de comandos entre sitios
Un usuario puede ver los datos enviados por otro usuario de dos formas. Puede ver estos datos inmediatamente (sesión de chat) o más tarde (archivo). Entonces, según los hechos anteriores, podemos decir que XSS se puede dividir en dos categorías:
- ataque continuo
- ataque no sostenido
ataque continuo
En un ataque sostenido, un usuario malicioso proporcionaría información a alguna parte de la aplicación, que luego se proporcionaría al público oa otros usuarios. Las formas comunes de una aplicación de este tipo pueden ser un sitio de citas, un sitio que pide a los usuarios que proporcionen comentarios abiertos, un sitio que pide a los usuarios que completen un libro de visitas. Probablemente por libertad, la aplicación ignora el peligro de los ataques XSS, lo que permite al usuario colocar HTML para que el usuario final pueda embellecer su entrada colocando etiquetas. Un usuario malintencionado puede aprovechar esta libertad y poner un script del lado del cliente en la respuesta que da. Después de que el usuario malintencionado guarda la entrada, la información que proporciona se convierte en parte de la base de datos y cualquier usuario que vea esta información después puede convertirse en una víctima.
ataque no sostenido
En estos ataques, los datos ingresados por el usuario malicioso se presentan directamente al usuario. No implica almacenamiento persistente intermedio. Este ataque generalmente ocurre en forma de una URL mal formada que se envía a la víctima. Puede haber aplicaciones como el chat basado en HTML donde los usuarios pueden colocar datos HTML. Sin embargo, es seguro usar un cuadro de texto para mostrar el chat HTML de salida, porque el cuadro de texto solo mostrará el contenido del script, no ejecutará el script.
¿Qué hizo un atacante con un ataque de secuencias de comandos entre sitios?
secuestro de sesión
Antes de entrar en los detalles de lo que puede hacer un atacante, echemos un vistazo a cómo funciona la red.
WWW se basa en el protocolo HTTP. La solicitud HTTP consta principalmente de dos partes: el encabezado del mensaje y el cuerpo del mensaje. Consulte el RFC para HTTP para obtener una descripción de estas secciones. El encabezado contiene información general, como el nombre del software del cliente, la referencia, la ruta del script de ejecución, etc., mientras que el cuerpo consta de nombre a valor para los controles en el formulario. (Un formulario puede ser una forma HTML de realizar una solicitud normal a una dirección web específica). HTTP es un protocolo sin estado. Esto significa que el servidor no puede distinguir entre los dos clientes. Para superar este problema y dejar que el servidor determine el cliente X del cliente Y, usamos el concepto de sesiones en el servidor Web. Las sesiones se basan en un ID llamado ID de sesión. Entonces, cada vez que el cliente envía su identificación de sesión al servidor para que el servidor pueda identificarlos. Esta identificación es única para cada cliente, y esta identificación también tiene un límite de tiempo. Esto significa que esta identificación solo es válida por un período de tiempo determinado. Entonces, para devolver esta ID al servidor, el cliente puede ponerla como parte de la solicitud o puede ponerla en el encabezado de la solicitud. Si el ID de sesión está en la solicitud, no se basa en el uso de cookies. Si el ID de sesión forma parte del encabezado, se basa en el uso de cookies. ** Las cookies pueden contener cualquier dato, como la lógica de la aplicación, y se utilizan para mantener el estado entre páginas en protocolos HTTP que de otro modo no tendrían estado.
Entonces, el punto que quiero decir aquí es que si el usuario A tiene la cookie que el servidor envió al usuario B, y el usuario A usa esa cookie, entonces para el servidor, él es el usuario B y no el usuario A. Los atacantes intentan aprovechar esto para lograr una arquitectura sin estado mediante el uso de ataques XSS para el robo de cookies. Una vez que el atacante ha obtenido la cookie, es solo cuestión de tiempo antes de que la cookie se envíe al servidor web y falsifique la identidad de otros usuarios.Para obtener cookies mediante un ataque de secuencias de comandos, el atacante debe crear un formulario especial para pasar de un lado a otro document.cookie a su sitio web.
intoxicación por galletas
Algunos sitios web pueden usar cookies para presentar una apariencia personalizada a los usuarios. Pueden almacenar preferencias de usuario y otra información relacionada con el usuario en cookies. Sin embargo, si un sitio web de este tipo es vulnerable a un ataque XSS, el atacante puede usar la cookie para manipular los datos de forma silenciosa, y luego el usuario final puede experimentar algunos problemas la próxima vez que use la cookie. aqui otra vez, document.cookie Se utiliza para manipular valores de cookies existentes con algunos scripts. Sin embargo, este ataque es posible si la aplicación escribe a ciegas el valor de la cookie en el flujo de salida.
URL con formato incorrecto
Usando un ataque XSS, un atacante inteligente puede engañar al usuario final para que obtenga un número de tarjeta de crédito. Para hacer esto, un atacante puede explotar el 'a href' agregue una etiqueta a su secuencia de comandos vulnerable, este enlace puede llevar al usuario de su sitio al sitio del atacante, donde puede mostrar una pantalla similar a un sitio de suplantación de identidad y solicitar una donación o calificaciones de actualización de membresía. El monto puede ser tan bajo como $1 porque el objetivo principal del atacante no es el monto sino el número de la tarjeta de crédito. Los ataques de phishing son uno de esos ataques.
cuadro
Un atacante puede usar un IFRAME Establezca el alto y el ancho al 100 % de la etiqueta y los usuarios finales verán la página del atacante en lugar de la suya. Entonces, para el usuario final, sería su sitio porque podría ver su dirección en la barra de direcciones, pero el atacante en realidad está jugando con él.
Ataque de DOS
DOS significa ataque de denegación de servicio. Para realizar un ataque de DOS en una página específica de un sitio, un atacante puede escribir un script que se ejecutará en un intervalo de tiempo específico, digamos 20 milisegundos, y luego ejecutar el código. En este caso, un simple cuadro de mensaje será suficiente. Si bien este no es un ataque mortal, aún puede frustrar a los clientes que visitan su sitio de comercio electrónico. Mostrar reseñas de compradores aquí puede ser una trampa.
La lista de ataques es continua e incluso puede provocar el robo de datos de archivos locales del sistema. Los troyanos se pueden descargar al cliente sin siquiera hacer clic en ningún enlace.
Prevenir ataques de secuencias de comandos
Inyección de secuencias de comandos y ValidateRequest de ASP.NET = etiqueta de página 'verdadera': ValidationRequest = true Normalmente, la entrada no segura del cliente se verifica y cualquier etiqueta HTML se suprime de forma predeterminada.Sin embargo, cuando escribí esto, no verificó las etiquetas HTML pasadas como <%00 tag here>. P.ej <%00 font>. hazlo false Esta es una buena idea si desea que el cliente complete la entrada HTML. Sin embargo, debe verificar minuciosamente la entrada de cualquier etiqueta de secuencia de comandos.
Usar expresiones regulares: usar expresiones regulares para verificar la entrada del cliente es una buena idea, pero los atacantes pueden pasar datos en forma codificada en lugar de texto sin formato.
Usando servidor.HTMLEncode (.NET): Si bien esta es una característica de .NET, muchas tecnologías web modernas brindan una funcionalidad similar. Puede usar estas funciones para mostrar la entrada de un usuario a otro. Estas funciones convierten el marcado HTML en formato codificado. Por lo tanto, el script no se ejecuta, sino que se representa en la página.Así que básicamente aquí me refiero a codificar la entrada < and > señal.
usa comillas dobles: si usa la entrada del usuario para generar enlaces en lugar de representar texto sin formato, puede encerrar la entrada entre comillas dobles y mostrársela al usuario. P.ej, . Este método se utiliza en scripts del lado del cliente como carácter de escape para comillas simples en lugar de comillas dobles.
** También debe tener en cuenta los problemas de codificación, ya que los atacantes pueden codificar cadenas vulnerables y es posible que sus precauciones no las detecten.
Ejemplo sobre XSS
Para simplificar, supongamos que un fragmento de código de una aplicación ASP es vulnerable a los ataques XSS. <% Response.Write (“Your search on’” + Request.Querystring(“SearchString”) + “returned following results:” ) %>Todos los siguientes ejemplos tratan este código como código básico, debe pasar el código JavaScript como un valor a SearchString valor del parámetro. Aquí utilizo ASP como ejemplo, pero las vulnerabilidades entre sitios son comunes a la mayoría de las tecnologías web, así como a los archivos de script compilados (.chm). El punto es que cualquier aplicación que mezcle datos HTML con código de script e ignore la entrada del usuario es vulnerable a XSS. Veamos cómo un ataque explotaría la variable de cadena de consulta anterior.
También tenga en cuenta que las cadenas de consulta son solo una de las formas. Aquí, la entrada puede provenir de una cookie o base de datos, no de una cadena de consulta, lo que puede causar problemas si la entrada contiene una cadena de explotación. El ejemplo que se muestra arriba es un tipo de ataque no persistente. Sin embargo, si no es una cadena de consulta, sino una entrada de una cookie o base de datos, es un secuestro de sesión de ataque persistente. Para secuestrar la sesión, el atacante necesita obtener la cookie de la víctima. Entonces necesita crear un formulario y enviarlo a su sitio. Este formulario contendrá el valor de la cookie, dado que el atacante conoce el funcionamiento de su sitio, sabe qué cookie es para qué sitio.
El script anterior publicará el valor de la cookie en el sitio del atacante, y el atacante puede entonces formar una solicitud y agregar el valor de la cookie a la solicitud y obtener acceso al sitio.La secuencia de comandos anterior se puede ejecutar en varios eventos, como la carga de la página, el mouseover, el clic del mouse para enviar el formulario, o un atacante simplemente puede usar setTimeout Cómo hacer una publicación de formulario.
intoxicación por galletas: El envenenamiento de cookies se ocupa de corromper los valores de las cookies y algunas partes de la aplicación dependen de las cookies para configurar response.writeEn nuestro ejemplo, supongamos que se usa una cookie para almacenar el valor de la última búsqueda del usuario junto con la fecha y hora. El envenenamiento por cookies generalmente implica el análisis fuera de línea de un sitio por parte de un atacante. Es decir, el atacante primero visitará el sitio, luego analizará las diversas cookies descargadas y luego atacará.
Aquí, el atacante actualiza el valor de la última búsqueda. href apunta a su sitio web. Allí, podrá solicitar al usuario que "inicie sesión nuevamente para reclamar su premio". La cookie aquí está envenenada y el usuario se verá afectado cada vez que visite el sitio, a menos que elimine su caché de cookies, verá este mensaje. Entonces, inicialmente, el atacante puede atraerlo con $ 5 y luego pedirle que pague $ 50 por algún excelente producto que le ofrece su sitio.
cuadro: IFRAME es una etiqueta HTML, que ni siquiera requiere una etiqueta de secuencia de comandos para mostrarse.Este IFRAME Un elemento define un marco en línea, que puede contener objetos externos, incluidos otros documentos HTML. Entonces, un atacante simplemente escribiría la siguiente declaración: