Seguridad 101: secuencias de comandos entre sitios



Las secuencias de comandos entre sitios han existido por más tiempo que la mayoría de los profesionales de seguridad en el trabajo. ¿Por qué sigue siendo un problema cuando lo sabemos desde hace tanto tiempo?

En seguridad cibernética, la atención se concentra en lo nuevo: los exploits de día cero, por ejemplo, son una gran noticia y un gran negocio. Pero las viejas amenazas aún pueden causar grandes problemas a las organizaciones, incluso cuando las amenazas son lo suficientemente viejas como para tomar un trago legalmente para celebrar sus victorias.

Las secuencias de comandos entre sitios, o XSS, fueron las primeras descrito por los ingenieros de Microsoft el 16 de enero de 2000. En 2007, se consideraba el exploit más común para las aplicaciones basadas en la web. Y en 2020 sigue siendo una de las técnicas de explotación más comunes y peligrosas. Entonces, ¿qué es exactamente XSS y por qué sigue siendo algo de lo que nos preocupamos hoy?

Conceptos básicos de XSS

Cuando un usuario escribe una URL, espera que su navegador solicite datos de un servidor, que luego se enviarán de vuelta al navegador y se mostrarán en la pantalla del usuario. A fines de la década de 1990, los piratas informáticos descubrieron que podían usar Javascript para hacer que un sitio internet se cargara en un marco en un segundo sitio world-wide-web sin notificación visible. El primer sitio web (ilícito) puede capturar datos de una forma legítima identical, robar credenciales, lanzar ataques y hacer todo tipo de otras cosas. Debido a que el ataque utilizó un par de sitios internet y se lanzó con un script, la técnica se conoció como scripting entre sitios.

Los sitios net modernos se han vuelto cada vez más complejos, y el proceso para hacer que una página world-wide-web (o aplicación) aparezca en un navegador se ha vuelto más complicado. Si cada parte del código entregado a un usuario ha sido cuidadosamente examinado y aprobado por el propietario del servidor, ese proceso complejo puede ser seguro y confiable, pero hay varias formas en que un pirata informático puede doblegar el proceso en su beneficio.

Problemas en el DOM

Antes de continuar, hay un término a introducir: DOM. En este contexto, DOM es el acrónimo de Doc Object Design, y es una forma breve de hablar sobre la totalidad de la aplicación world-wide-web o el sitio que se representa en el navegador de un usuario. El DOM es importante porque incluye todos los scripts, objetos y referencias que se utilizan para crear la página world-wide-web que aparece en el navegador de un usuario. También es parte del nombre de un tipo de XSS.

Todos los tipos de XSS dependen de la capacidad de los atacantes para cambiar el código legítimo, en el servidor, en la computadora del usuario o en tránsito entre los dos. Con eso en mente, veamos los tres tipos de XSS.

Tipo 1 – Este tipo, también conocido como XSS persistente o almacenado, es posible cuando el usuario almacena datos en un servidor y luego puede recuperar esos datos con poca interferencia. Piense en los comentarios de la comunidad de weblogs, foros de mensajes y similares. Si la información devuelta al usuario no se examina por razones de seguridad, un atacante puede inyectar scripts en los campos y hacer que se ejecuten sin previo aviso al usuario. Este tipo de XSS generalmente implica cambios ilícitos en el código fuente de la página net y requiere acceso al servidor net.

Tipo 2 – XSS no persistente o reflejado es posible cuando la entrada del usuario se refleja de inmediato al usuario sin validación y sin almacenamiento en el servidor. Este tipo de ataque XSS puede tener lugar por completo dentro del navegador, sin involucrar al servidor legítimo hasta el momento de ofrecer datos para la toma. Todo lo relacionado con el ataque puede ocurrir en el cliente, y los resultados son datos ilícitos solicitados al servidor.

Tipo – Este fue el último tipo de XSS definido y también se llama XSS basado en DOM. Este es un tipo de ataque que, como el Tipo 2, puede lanzarse completamente dentro del navegador, pero en este caso la carga útil maliciosa puede no solicitar datos puede ser un script que provoca acciones en un servidor de terceros. Este tipo de ataque a menudo depende de URL mal formadas para su funcionamiento, a veces solicita que se inicie un script malicioso en un servidor que el usuario no conoce y nunca ve.

Solo para hacer las cosas más complicadas, estos tres tipos de ataque se pueden mezclar y combinar en una sola campaña, con diferentes tipos de XSS utilizados en diferentes etapas de una campaña compleja. La clave para todos ellos es que un tercero debe cambiar el código en el servidor, o dentro del entorno del navegador, sin permiso.

Decir no a XSS

Entonces, ¿qué debe hacer un desarrollador (o equipo de seguridad) sobre XSS? La regla más importante y más básica es esta: nunca permita que se inserten o cambien datos donde no haya una buena razón para ello. Eso suena straightforward, pero hay una serie de reglas diferentes que se deben seguir para que funcione.

Una de las primeras reglas es asegurarse de que cualquiera de los personajes que puede iniciar una sesión de secuencias de comandos (cosas como &, <, >, «, &#39y /) están designados por, y deben ser, sus entidades hexadecimales en lugar de los caracteres ASCII que ve aquí.

A continuación, asegúrese de que se escapen todos los parámetros y las llamadas de secuencia de comandos, entre comillas. Las especificaciones permitirán variables y etiquetas sin las comillas, pero al hacerlo deja la puerta abierta a los hackers XSS.

Finalmente, inspeccione regularmente el código en su sitio internet para detectar cambios ilícitos o no aprobados. El manage de versiones y el monitoreo de código de Solit contribuirán en gran medida a eliminar XSS en su sitio.

La razón básica por la que XSS todavía existe es que los desarrolladores todavía están bajo presión de tiempo y los hackers aún lo saben. Tómese el tiempo para optar por un código seguro y obligará a los atacantes a usar herramientas más nuevas y más caras para llegar a sus datos.

Contenido relacionado:

Curtis Franklin Jr. es editor sénior en Dark Reading through. En este puesto, se centra en la cobertura de productos y tecnología para la publicación. Además, trabaja en programación de audio y movie para Dark Reading y contribuye a actividades en Interop ITX, Black Hat, INsecurity y … Ver biografía completa

Lectura recomendada:

Más strategies





Enlace a la noticia first