54

Cross-Site Scripting
Katherine Ramos Pereira
Universidad Mayor de San Andrés
Facultad De Ciencias Puras Y Naturales
Carrera Informática
Análisis Y Diseño De Sistemas De Información
[email protected]

RESUMEN vulnerabilidad, se puede explotar el fallo para causar una acción

indebida en un servidor o en una aplicación.
El Cross-Site-Scripting es una vulnerabilidad que aprovecha la
falta de mecanismos de filtrado en los campos de entrada y Esta limitación se debe a que el código HTML se interpreta en el
permiten el ingreso y envió de datos sin validación alguna, que navegador de un usuario y no en el servidor. Así que si alguien
permite a una tercera parte inyectar en páginas web vistas por el inyecta código HTML en alguna aplicación web no podría hacer
usuario código Java Script o en otro lenguaje script similar daño alguno al servidor, ya que éste nunca interpreta el código
ejemplo. VBScriptpudiendo generar secuencias de comandos HTML, solo los navegadores. Por eso este ataque se determina:
maliciosas que impacten directamente en el sitio o en el equipo “ataque del lado del cliente”.
de un usuario.
El XSS se puede utilizar para hacer phishing, (robo de
Este tipo de vulnerabilidad se conoce en español con el nombre credenciales), troyanizar navegadores. Todo depende de la
de Secuencias de comandos en sitios cruzados. página.

Causa un impacto tanto a una aplicación web como a usuarios que 2. ATAQUES DE CROSS-SITE SCRIPTING (XSS)
de manera inconsciente activen dicha secuencia de comandos.
Los datos se incluyen en el contenido dinámico que se envía a un
Dicho código malicioso se compone de cadenas de datos cuyo usuario de la web sin ser validado por código malicioso.
contenido son scripts completos contenidos en enlaces o
El contenido malicioso enviado al navegador web a menudo toma
ejecutados desde formularios. la forma de un segmento de Java Script, pero también puede
incluir HTML, Flash o cualquier otro tipo de código que el
En caso de que sea ejecutado el mismo se ejecutara en el equipo navegador puede ejecutar. La variedad de los ataques basados en
del usuario con todos los privilegios permitidos por las políticas XSS es casi ilimitada, pero normalmente incluyen la transmisión
de seguridad configuradas en el navegador del usuario o del sitio de datos privados, como las galletas o cualquier otra información
visitado, pudiendo realizar acciones diversas como la captura de de sesiones a la atacante, la reorientación de la víctima a la página
cookies de usuario o la activación de servicios y componentes del web controlado por el atacante, o la realización de otras
operaciones maliciosos en la máquina del usuario en la apariencia
sistema operativo del usuario víctima.
del sitio vulnerable.
Palabras Clave Los ataques XSS generalmente se pueden clasificar en dos
Ataque, web, malicioso, usuario, seguridad,
categorías:
XSS, vulnerabilidad, aplicaciones, internet.
1. INTRODUCCION  Almacenados
El Cross Site Scripting (XSS) es una vulnerabilidad muy común  Reflejados.
hoy en día, se puede encontrar en la mayoría de las aplicaciones Hay una tercera, mucho menos conocido tipo de ataque XSS
web en Internet. llamada DOMXSS.

Este fallo compromete más que nada, la seguridad del usuario y Los ataques XSS almacenados
no la del servidor. Consiste en inyectar código HTML o Java
script en una aplicación web, con el fin de que el navegador de un Ataques almacenados son aquellos en los que el código inyectado
usuario ejecute el código inyectado al momento de ver la página se almacena de forma permanente en los servidores de destino,
alterada. como en una base de datos, en un foro de mensajes, registro de
visitantes, campo de comentarios, etc. La víctima recupera el
Comúnmente el XSS se utiliza para causar una acción indebida script malicioso en el servidor cuando se solicita al almacenado
en el navegador de un usuario, pero dependiendo de la información.
 55

Ejemplo de un ataque XSS almacenado. El siguiente segmento de código JSP lee un ID de

empleado, eid, de una solicitud HTTP y lo muestra al usuario.
El siguiente segmento de código JSP consulta una <% String eid = request.getParameter ("eid"); %>
base de datos para un empleado con un ID dado y se imprime el ...
nombre del empleado correspondiente. Employee ID: <%= eid %>
<%...
Statement stmt = conn.createStatement (); El código de este ejemplo funciona correctamente si eid contiene
ResultSetrs = stmt.executeQuery ("select * from texto alfanumérico único estándar. Si eid tiene un valor que
emp where id="+eid); incluye meta-caracteres o código fuente, el código será ejecutado
if (rs != null) { por el navegador web, ya que muestra la respuesta HTTP.
rs.next (); Inicialmente esto podría no parecer gran parte de una
String name = rs.getString ("name"); vulnerabilidad. Después de todo, ¿por qué alguien escriba un
%> URL que causa el código malicioso se ejecute en su propio
ordenador? El verdadero peligro es que un atacante crear el URL
EmployeeName: <%= name %> malicioso, a continuación, utilizar el correo electrónico o trucos
de ingeniería social para engañar a las víctimas para que visite un
Este código funciona correctamente cuando los valores de enlace a la URL. Cuando las víctimas haga clic en el vínculo, sin
nombre son bien educados, pero no hace nada para evitar abusos, saberlo, reflejan el contenido malicioso mediante la aplicación
web vulnerable a sus propios equipos. Este mecanismo de
si no lo son. Una vez más, este código puede parecer menos
explotación de las aplicaciones web vulnerables es conocido
peligroso porque el valor del nombre se lee de una base de datos, como XSS reflejados.
cuyo contenido aparentemente son gestionados por la aplicación.
Sin embargo, si el valor del nombre se origina a partir de datos
suministrados por el usuario, a continuación, la base de datos 3. CONSECUENCIAS DEL ATAQUE XSS
puede ser un conducto para el contenido malicioso. Sin la
validación de entrada correcta en todos los datos almacenados en La consecuencia de un ataque XSS es el mismo,
la base de datos, un atacante puede ejecutar comandos maliciosos independientemente de si se almacena o refleja (o basado en
en el navegador web del usuario. Este tipo de explotación, DOM). La diferencia está en la forma en la carga útil que llega al
conocido como XSS almacenados, es particularmente insidioso servidor. No se deje engañar en pensar que es "sólo lectura" o
porque la indirección causada por el almacén de datos hace que "brochureware", el sitio no es vulnerable a graves ataques XSS
sea más difícil identificarla amenaza y aumenta la posibilidad de reflejados. XSS pueden causar una variedad de problemas para el
que el ataque afectará a múltiples usuarios. XSS tiene su inicio en usuario final, que varían en severidad desde una molestia a un
el formulario con los sitios web que ofrecen un "libro de visitas" compromiso completo de la cuenta. Los ataques XSS más graves
a los visitantes. Los atacantes podrían incluir Java Script en su implican la divulgación de cookie de sesión del usuario, lo que
entrada en el libro, y todos los visitantes posteriores a la página permite a un atacante secuestrar la sesión del usuario y hacerse
de libro de visitas que se ejecute el código malicioso. cargo de la cuenta. Otros ataques dañinos incluyen la divulgación
de los archivos de los usuarios finales, la instalación de programas
de caballo de Troya, redirigir al usuario a otra página o sitio web,
o modificar la presentación de los contenidos. Una vulnerabilidad
Los ataques XSS reflejados XSS que permite a un atacante modificar un comunicado de
prensa o noticia podría afectar la cotización de la empresa o
Ataques reflejados son aquellos en los que el código inyectado se
disminuir la confianza del consumidor. Una vulnerabilidad XSS
refleja en el servidor web, por ejemplo, en un mensaje de error,
en un sitio farmacéutica podría permitir a un atacante modificar
resultado de la búsqueda, o cualquier otra respuesta que incluye
información de dosificación que resulta en una sobredosis. Cómo
algunos o todos de la entrada se envía al servidor como parte de
determinar si es vulnerable
la solicitud. Ataques reflejados se entregan a las víctimas a través
de otra ruta, tal como en un mensaje de correo electrónico, o en Las fallas de XSS pueden ser difíciles de identificar y retirar de
algún otro servidor web. Cuando un usuario es engañado para una aplicación web. La mejor manera de encontrar defectos es
hacer clic en un enlace malicioso o enviar un formulario realizar una revisión de seguridad del código y la búsqueda de
especialmente diseñado, el código inyectado viaja al servidor web todos los lugares en los que la entrada de una petición HTTP
vulnerable, lo que refleja el ataque al navegador del usuario. El podría hacer su camino en la salida HTML.
navegador ejecuta el código, ya que provenía de un servidor de
"confianza".

El ejemplo más común se puede encontrar en los sitios web de

anuncios de a bordo que proporcionan funcionalidad list-style de
correo basado en web.
 56

4. ¿CÓMO PROTEGERSE? A través de un ataque XSS, se puede secuestrar cuentas, cambiar

configuraciones de los usuarios, acceder a partes restringidas del
Las defensas primarias contra XSS sitio, modificar el contenido del sitio, etc. Las fallas de XSS
pueden ser difíciles de identificar y retirar de una aplicación web.
Se describen en el XSS Prevención OWASP (el proyecto de Es por eso que el proyecto OWASP usa componentes de
seguridad para evitar un ataque malicioso.
seguridad de aplicaciones web de código abierto). Además, es
crucial que desactivar la compatibilidad con HTTP TRACE en
8. REFERENCIAS
todos los servidores web. Un atacante puede robar datos de las
cookies a través de Java script. Este ataque se monta cuando un
1. [1] Cross-site Scripting (XSS). Autor: fortify software
usuario publica un script malicioso en un foro así que cuando otro
Disponible en:
usuario hace clic en el enlace, una llamada de seguimiento HTTP
https://www.owasp.org/index.php/Cross-
asincrónico se activa, que recoge información de las cookies del
site_Scripting_%28XSS%29
usuario desde el servidor, y luego lo envía a otro servidor
2. [2] Cross-site scripting Autor: Sirdarckcat
malicioso que recoge la información de las cookies para que el
Disponible en: http://es.wikipedia.org/wiki/Cross-
atacante puede montar una sesión de secuestrar ataque. Esto se
site_scripting
mitiga fácilmente retirando el apoyo a HTTPTRACE en todos los
servidores web. 3. [3]Tutorial básico cross site scripting
Autor: Adrian Disponible en:
5. COMPONENTES DE SEGURIDAD http://www.shellshocklabs.com/search/?q=cross+site+scripting

El proyecto OWASP ESAPI ha producido un conjunto de

4. [4] Tutorial de cross site scripting [XSS]+como atacar
componentes de seguridad reutilizables en varios idiomas,
ejemplos. Autor: ICEnetX Disponible en:
incluyendo la validación y escapar de las rutinas para evitar la
http://www.taringa.net/posts/ebookstutoriales/2306
manipulación de parámetros y la inyección de ataques XSS.
553/Tutorial-de-cross-site-scripting-XSS-como-
Además, la aplicación de entrenamiento proyecto WebGoat
atacar-ejemplos.html
OWASP tiene lecciones de Cross-Site Scripting y codificación de
datos.
[5]XSS Capítulo 1: Introducción a Cross Site Scripting. Autor:
zhynar_X Disponible en: http://wiki.elhacker.net/bugs-y-
7. CONCLUSION
exploits/nivel-web/xss
Las vulnerabilidades de XSS abarcaban cualquier ataque que
permita ejecutar código de "scripting".