1. El test de la Viagra (o el software barato)

Este seguro que ya lo conocéis, es tan sencillo como buscar en Google en el site de vuestra web por “cheap viagra” o “cheap software” para ver si vuestra web está jodida por la viagra como la de Apple o por el software piata como la de la Nasa. Si esto aparece, es que hay un buen bug en el sitio web que alguien ha aprovechado.

Figura: 1 Viagra En La Web De Apple

2. Ficheros con usuarios en los metadatos

Podéis hacer un análisis de los metadatos de todos los documentos podéis utilizar FOCA, pero si queréis hacer una prueba rápida, basta con que miréis en Google los famosos ficheros PDF que tienen en el título la ruta al perfil del usuario, como hicimos con los espías. Esto implicaría que al ENS no le hacen mucho caso - y que no nos han comprado aún Metashield Protector }:) -

Figura: 2 Usuarios del ejercito Americano

 Nota: Si quieres mirar metadatos en ficheros en concreto, los Excel suelen ser los que más metadatos suelen contener.

3. La prueba de robots.txt

El domingo pasado os publiqué un ejemplo de lo que NO se debe hacer con un robots.txt, pero lo ideal es buscar los directorios que aparecen en ellos a ver si tienen alguna “sopresa” como un panel de administración, o una aplicación “escondida”.

Figura: 3 interesante Robots.txt de oracle.com

4. Listado de directorios abiertos

A veces los árboles no nos dejan ver el bosque, y lo más fácil es pedir el listado de directorios y obtener todos los ficheros allí almacenados. Para ello, basta con que busques las carpetas en las URL de la web y compruebes si te muestra la lista de ficheros. Esto no debería pasar nunca.

Figura 4: Listado de directorios abierto en EAJ-PNV.com

5. SQL Injection de libro en aplicaciones ASP o CFM con la comilla

El lenguaje ASP fue lanzado en 1996 mientras que el SQL Injection se descubrió en 1998, por lo que los ficheros ASP no traen una protección extra para los ataques de comilla. Para ello, busca en tu sitio ficheros asp con parámetros y añade al valor del parámetro algo como ‘asdf y mira a ver si canta algún error de aplicación o de ODBC. Si esto pasa, la web es vulnerable. Esta prueba puede realizarse de la misma marea con ficheros ColdFusion que también nacieron antes que el SQL Injection.

Figura 5: Búsqueda de aplicaciones ASP con parámetros

Figura 6: Ejemplo típico de error ODBC

6. Blind SQL Injection de Libro en ficheros PHP

En PHP añadieron las magic quotes, que hacen que se escapen las comillas, evitando los ataques con comillas. Sin embargo, nada protegen contra los ataques Blind SQL Injection en parámetros numéricos. Para hacer una prueba sencilla, busca en tu sitio ficheros PHP con parámetros numéricos y haz dos peticiones, una inyectando and 1=1 y otra inyectando and 1=2. Si los resultados son distintos, ese sitio es más que probable vulnerable a BSQLi. Una vez descubierto el Blind SQL Injection, ya le puedes dar caña a las tools.

Figura 7: Búsqueda de PHPs con parámetros numéricos. Hay que inyectar and 1=1 y and 1=2

Todas estas pruebas no son definitivas, y aunque la web de tu empresa las pase todas debería seguir haciéndose un test de intrusión de forma periódica pero, por el contrario, si alguna de ellas da resultado positivo, indica un fallo de seguridad y lo que es más gordo, una “preocupación” por la seguridad de la web “relajada”.


Contenido E Imagenes por: El maligno de Chema Alonso.
Post Original: http://goo.gl/2YTgk