ADMINISTRACION DE REDES

SECUNECIA DE COMANDOS EN SITIOS CRUZADOS(XSS)

DIEGO ALEXANDER MADRID DUQUEGABRIEL ANDRES AGUIRRE JARAMILLO

INSTITUTO TECNOLOGICO METROPOLITANOITM

Secuencia de comandos en sitios cruzados (XSS)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 identificadorFROM usuariosWHERE username = 'usuario'AND password = 'contraseña’

Secuencia de comandos en sitios cruzados (XSS)

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 identificadorFROM usuariosWHERE username = 'usuario'AND password = 'password' OR 'x'='x'

HTML Injection

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>

Secuencia de comandos en sitios cruzados (XSS)

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.

Eliminación de restricciones 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.

XSS, Cómo evitarlo? 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.

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");

Servidores o Aplicaciones Web

› 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.

A CONTINUACION LA PRUEBA, PASO A PASO

DEMOSTRACION 1

Código para atacar

Página ya atacada

DEMOSTRACION 2

Código para atacar

Página a atacar

Página ya atacada