[Hack web parte.2] filtros & pagina owned

Continuando esta serie de post, publico la segunda y ultima parte.
Si recordamos la ultima sección del post anterior, mostré el primer filtro. Este correspondía a la cantidad de caracteres que se pueden introducir. Si bien éste filtro controla que no haya errores con la base de datos, también evita la inyección de código, es decir el exploit. Aun así quedo demostrado lo fácil que es saltarlo.

Habiendo dejado vulnerable los campos del form, es cuestión de comprobar si existe algún otro filtro que evite que el exploit o código sea interpretado como código dentro de la pagina.
Para esto, la idea es introducir una serie de caracteres especiales normalmente conocido como Locator.

Existen muchos códigos locator y combinaciones, dependiendo del lenguaje etc. En el ejemplo anterior se utiliza una serie de caracteres propio de lenguajes scripting, para ver si existe una vulnerabilidad cross-site scripting y de inyeccion html simple, digo simple porque existen formas avanzadas de inyección como códigos hexadecimales etc.
Otros locator utilizan los mensajes de alert() para poder saber que caracteres se filtran o no, pero yo solo voy a analizar la salida.

Como se muestra, algunos caracteres aparecen en el mensaje, esto es por que están correctamente filtrados, salvo las etiquetas. Este es un error grave que muchos diseñadores inexpertos pasan por alto.
Alojando la imagen en un servidor externo, con </td></br> se cierra el tag y se hace un salto de linea (en este caso es una tabla, pero sino, se cierra con un simple ">), lo demas es diseño html y se inyecta el exploit a la pagina.



Así se vería la pagina después de haber realizado el Defacing (defacear o cambiar el estilo de la pagina). Por lo general los defacing se realizan como protesta contra entidades y a mi parecer se podría definir como un graffiti virtual, en ataques permanentes.
Hay cosas mas complejas partiendo de esta, en este caso se trata de cross-site scripting reflejado pero aun así se puede causar un redireccionamiento a otra web, crear código malicioso para transmitir un malware (virus, troyano etc), robar cookies, sesiones, pishing etc.
Por lo tanto, como webmaster hay que revisar siempre las vulneravilidades o bugs que puedan llegar a presentarce en las paginas. El caso anterior se previene fácilmente con funciones en php htmlspecialchars() , strip_tags(), htmlentities() que evalúan la carga de caracteres, los famosos magic quote que relacionan los caracteres especiales a una variable que comienza con un ampersand , ejemplo &quot seria comillas dobles.

En fin, en otras oportunidades voy a explicar mas sobre las distintas vulneravilidades y técnicas.
Aclaración: Esto no es un tutorial. Gonzac Studios no se hace responsable por el mal uso de este material. Todas las pruebas se realizaron a paginas web dinámicas, actualmente estas no están defaceadas.
Las pruebas se pueden realizar alojando una web de prueba en algun servidor,
con un servlet en java junto a un servidor apache tomcat o algo similar. Recuerda que toda actividad queda almacenada en un log del servidor junto con tus datos. Siempre que encuentres una vulnerabilidad, puedes avisar al webmaster que estará agradecido. (Ética Hacker ;) )

Comentarios

Entradas populares