All The Input Is Evil - By p0is0n-123

Trataremos básicamente los principales fallos de una aplicación web que permiten a un atacante "operar" con determinado fin y finalidad.

Hace no mucho asistí (vía streaming tampoco os volvais locos) a una charla de mi amigo @chemaalonso cuyo título era "All the input is evil", lo cual viene a explicar que todos los datos de entrada en la aplicación son malignos.

La charla fue bastante amena y estoy seguro de que a partir de ahora cuando programeis una aplicación os acordareis del título e intentareis sanitizar y controlar al máximo los parámetros de entrada (aunque siempre hay algún cafre que antepone la funcionalidad a la seguridad). }:))


All The Input Is Evil I


1. - Inyecciones SQL básicas.

Típico caso vulnerable: news.php?new=123



Sabemos (y el programador debe de saberlo) que el código anterior es vulnerable a sql injection. También si nos fijamos sabemos que siempre usamos un id numérico, ¿entonces?
Para mi el código anterior sanitizado sería:



En casos en donde el parámetro de entrada tiene que ser alfanumérico, debemos de hacerlo de la siguiente forma:




2. - Ataque XSS (Cross Site Scripting)

Otro típico caso es el buscador en donde se imprime la palabra que se introdujo en el textbox.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



Y aquí el código corregido sanitizando los parámetros de entrada:



¿Fácil no? Pues pegaros una sesión de No tienes permitido ver los links. Registrarse o Entrar a mi cuenta y vereis la cantidad de sitios que "pasan" de la seguridad.


Yo me voy a sentar esperando la segunda parte de esta entrada. }:)) Saludos!


All The Input Is Evil II

Segunda parte de esta entrega, esta vez poniendo solución a fallos relacionados con la inclusión de archivos ejecutables


1. - Inyecciones LFI & RFI (Local/Remote File Include).

Veamos el típico ejemplo de inclusión de archivos de forma dinámica convirtiendose en métodos inseguros.



En ochenta mil sitios van a decir que este código es vulnerable y hay que sanitizar la variable $file, yo digo que no. Lo que no hay es que realizar includes dinámicos directamente para no comprometer el servidor.

Sí, se podría sanitizar pero, ¿hasta que punto lo convertiríamos en un LFI? ¿Realmente es posible?
Claro que es posible filtrar los datos de entrada, pero es que no es necesario porque el mismo código se podría estructurar de otra forma más segura. Veamos:



Así y con un poco de código extra se pueden guardar los logs de los "hackers" que lo intentaron por esa vía y bloquear sus ips o hacer lo que se crea necesario.


2. - Inyecciones tipo SSI a partir de XSS (Server Side Includes).

Lo más típico, descubrir un fallo tipo XSS en un servidor Apache y probar si SSI está activado. Es sorprendente la cantidad de servidores que lo tienen activado y no lo usan, simplemente porque no saben que está ahí.

Llegados a este punto es fácil saber que de no existir el XSS  (All the input is evil - I de III) esto nunca llegaría a funcionar.

Así que para que repetir lo que ya sabemos, cuidado con las inyecciones tipo Cross Site Scripting porque son más de lo que parecen (nunca dijimos lo contrario).

Un poco de No tienes permitido ver los links. Registrarse o Entrar a mi cuenta sobre SSI };)


All The Input Is Evil III

Tercera y última parte de esta entrega, esta vez poniendo solución a fallos relacionados con la descarga de archivos y mostrando un simple buffer overflow.


1. - Arbitrary File Download (¿LFI?)

Veamos un simple ejemplo que debe de haber en más de mil páginas y que seguramente os habeis encontrado.




Todos vemos el fallo, pero no todos sabemos como solucionarlo.
He visto soluciones comprobando que el archivo contiene en la ruta /downloads/ y que se evade facilmente usando DT (Directory Transversal):

Así que el filtrado seguramente no es una buena opción.
¿Solución? Una muy chula para poder seguir usando el downloader de forma dinámica y no tener que modificar el código cada vez que subimos un archivo es usando una base de datos que almacene el hash original del archivo, su nombre y su ruta.

Así se accede mediante el hash y se hace una consulta a la base de datos (cuidado manazas de los sqli).



De esta forma evitamos que se pueda descargar cualquier cosa y solo se descargan los archivos que están en la base de datos.


2 . - Buffer Overflow

Están, existen, y son peligrosos. Vamos a ver una simple aplicación en ANSI C que es vulnerable.




La variable MyBuffer tiene espacio para 10 bytes, si copiamos más de 10 se producirá un Buffer Overflow. Para evitar esto tenemos tres opciones:

a) Comprobar que no llegan en el buffer de la función más de 10 bytes.
b) Copiar solo 10 bytes del buffer, lleguen los que lleguen.
c) Redimensionar el buffer en función de los datos que lleguen. Aunque esto podría ser un Heap Buffer Overflow.

Un ejemplo de como sería comprobando:



Ya sé que hay muchas vulnerabilidades en aplicaciones web y aplicaciones en general, pero está claro que esto es una simple entrega para solucionar algunos fallos muy comunes y de bastante riesgo.


No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
AUTOR: p0is0n-123

Excelente aporte bro!!
Muchisimas gracias!!