ADMINISTRACION DE REDES
SECUENCIA DE COMANDOS EN SITIOS
CRUZADOS(XSS)
DIEGO ALEXANDER MADRID DUQUE
GABRIEL ANDRES AGUIRRE JARAMILLO
INSTITUTO TECNOLOGICO METROPOLITANO
ITM
XSS: Esta vulnerabilidad puede estar presente en 2
formas:
 Directa (Persistente): este tipo de XSS comúnmente
filtrado, y consiste en embeber código HTML peligroso
en sitios que lo permitan; incluyendo así etiquetas
como <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. Funciona localizando puntos débiles en
la programación de los filtros de HTML si es que existen,
para publicar contenido (como blogs, foros, etc.).


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 podría
ejecutar código malicioso.
Ejemplos:
Una posibilidad es usar atributos que permiten ejecutar código.
<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:
<div fu="alert('Hola mundo');" STYLE="background-image: url
(javascript:eval(this.fu))">
XSS Indirecto (reflejado), supongamos que
un sitio web tiene la siguiente forma:
http://www.example.com/home.asp?fram
e=menu.asp y que al acceder se creará
un documento HTML enlazando con un
frame a menu.asp.
 En este ejemplo, ¿qué pasaría si se pone
como URL del frame un código java script?:
java
script:while(1)alert("Este
mensaje
saldrá indefinidamente");

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 tan
siquiera necesitar su 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.


Una página como la siguiente:
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
java script, 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'.
javascript:void
prompt("Introduce
la
cookie:",document.cookie).replace(/[^;]+/g,function(_)
{document. cookie=_;});
En cuanto a las formas más comunes de
efectuar ataques XSS, encontramos:

SQL Injection
Se puede utilizar esta técnica cuando se
prevee que un campo dentro de una
página interviene dentro de alguna
consulta en la base de datos. A modo
de ejemplo, si suponemos un escenario
con una página de login, por ejemplo,
gmail.com; es lógico pensar que
cuando ponemos nuestro nombre de
usuario (“usuario”) y contraseña
(“contraseña”), el servidor tendrá que
preguntar a la base de datos:
SELECT identificador
FROM usuarios
WHERE username = 'usuario'
AND password = 'contraseña’
En este escenario si no se comprueba que
el nombre de usuario y la contraseña no
sean sentencias SQL se podría escribir
como contraseña password’ OR ‘x’='x’, con
lo que la consulta a la base de datos sería:
SELECT identificador
FROM usuarios
WHERE username = 'usuario'
AND password = 'password' OR 'x'='x'
Al igual que ocurre en el
ataque anterior, se puede
utilizar la inyección de código
HTML cuando se prevee que
el dato que se introduce en
algún campo de un formulario
o parámetro de la web será
mostrado
en
la
página
resultado.
A
modo
de
ejemplo, la forma más básica
de comprobar si un buscador
es susceptible a XSS por
inyección
de
HTML
es
introducir en la casilla del
buscador:
<strong>test</strong>
Si el buscador muestra en la página de
resultados algo así como:
Resultados para <strong>test</strong>,
no es probable que sea susceptible a
este tipo de ataques, si por el contrario
muestra resultados para test , es muy
probable que el servidor sea susceptible
a este tipo de ataques.
Básicamente, el
ataque consiste en
eliminar restricciones
impuestas por la
programación de una
página web, siempre y
cuando estas
restricciones se lleven
a cabo en el cliente.
Es decir, se llevan a
cabo en nuestro
navegador.

Dentro de la formas de explotar esta
vulnerabilidad se pueden encontrar dos
tipos. Se puede modificar en “tiempo
real” una página web, para por ejemplo
sobrescribir una función de validación y
siempre de un resultado positivo. O por
otro lado, se puede capturar una
petición válida al servidor, modificarla a
nuestro gusto y volverla a enviar.
De esta forma el ejemplo anterior quedaría:
SELECT identificador
FROM usuarios
WHERE username = ? AND password = ?
Ahora sólo quedaría decir qué es cada uno de los
parámetros, lo importante es que en esta operación se dice
de qué tipo son los mismos, por lo que por ejemplo introducir
un número cuando se espera una cadena daría error. En
Java por poner un ejemplo, se realizaría con:
preparedStatementObject.setString(1,"usuario");
preparedStatementObject.setString(2, "contraseña");
›
›
›
HTTPS no evita XSS. HTTPS es un
protocolo que asegurará que la
conexión entre el servidor y el
cliente es segura, pero no
asegura nada de los datos
intercambiados.
Filtrado de código HTML que se
permite
introducir
por
los
usuarios. Esto es especialmente
problemático en componentes
encargados de los comentarios
en un blog o foro.
Se puede utilizar un pre-filtrado
en código cliente (que será
ejecutado en el navegador del
usuario),
pero
sólo
como
medida
adicional
de
prevención.
› Evitar utilizar sólo parámetros que viajan con la
página para autenticar un usuario. El ejemplo más
típico es que aunque exista un parámetro
&ID=[cadena de caracteres], eso sólo debe ser
utilizado como media adicional
› En ocasiones sería recomendable comprobar el
campo REFERER de la petición HTTP para saber de
dónde viene una petición, pero también hay que
tener en cuenta que es un campo opcional.
› Evitar filtrar por codificaciones, este ejemplo quizá
parezca bastante absurdo, pero se dan casos donde
por ejemplo se filtra un tag que contenga javascript,
pero no se filtra jav[caracter x09]ascript y a
efectos prácticos es lo mismo.

Bases de datos
Evitar que se puedan
ejecutar más de una
sentencia SQL en un
mismo comando.
Utilización de Prepared
Statements: ¿Y eso qué es?
Básicamente el término
prepared statement hace
referencia a un tipo de
consultas SQL que no se
ejecutan
concatenando
cadenas de caracteres. El
funcionamiento es primero
construir el esqueleto de la
sentencia SQL y luego
decir qué parámetros van
en cada punto.
Descargar

Secuencias de comandos en sitios cruzados (XSS)