ADMINISTRACION DE REDES SECUENCIA DE COMANDOS EN SITIOS CRUZADOS(XSS)

1. ADMINISTRACION DE REDES SECUENCIA DE COMANDOS EN SITIOS CRUZADOS(XSS) DIEGO ALEXANDER MADRID DUQUE GABRIEL ANDRES AGUIRRE JARAMILLO INSTITUTO TECNOLOGICO METROPOLITANO ITM

2. Secuencias de comandos en sitios cruzados (XSS) . El XSS es básicamente el intentar explotar vulnerabilidades habitualmente en entornos web mediante la inyección de código. El término inyección de código, hace referencia al intentar hacer ejecutar un código ajeno dentro de otro programa. . XSS, del inglésCross-SiteScripting 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

3. Secuencias de comandos en sitios cruzados (XSS) • 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.).

4. Secuencias de comandos en sitios cruzados (XSS) • 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('Holamundo');" STYLE="background-image: url (javascript:eval(this.fu))">

5. Secuencias de comandos en sitios cruzados (XSS) • XSS Indirecto (reflejado), supongamos que un sitio web tiene la siguiente forma: http://www.example.com/home.asp?frame=menu.asp y que al acceder se creará un documento HTML enlazando con un framea 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");

6. Secuencias de comandos en sitios cruzados (XSS) • 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.

7. Secuencias de comandos en sitios cruzados (XSS) • 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=_;});

8. Secuencia de comandos en sitios cruzados (XSS) En cuanto a las formas más comunes de efectuar ataques XSS, encontramos: • SQL InjectionSe 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’

9. SQL Injection 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'

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

11. HTML Injection: 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.

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

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

14. Eliminación de restricciones 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");

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

16. Servidores o Aplicaciones Web • 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]ascripty a efectos prácticos es lo mismo.

17. 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 PreparedStatements: ¿Y eso qué es? Básicamente el término preparedstatement 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.

18. A CONTINUACION LA PRUEBA, PASO A PASO

19. DEMOSTRACION 1

20. Código para atacar

21. Página ya atacada

22. DEMOSTRACION 2

23. Código para atacar

24. Página a atacar

25. Página ya atacada