En el OWASP-IG-001 recopilaremos información de la aplicación Web que queremos atacar, nos haremos un mapa de la misma y sabremos que estructura tiene. Todo esto se puede hacer a través de Web Spiders o Crawlers o con la ayuda del archivo de robots que muchos sitios Web tienen, y que no es más que un archivo de configuración que indica a los robots lo que “en teoría” no tienen que indexar, también habla con los User Agent para indicar si pueden o no mostrar
User-agent: *
Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /editor/
Disallow: /help/
Disallow: /images/
Disallow: /includes/
Disallow: /language/
Disallow: /mambots/
Disallow: /media/
Disallow: /modules/
Disallow: /templates/
Disallow: /installation/
¿Protege esto en el acceso a carpetas internas? No, no es una solución de control de acceso ni provee autenticación ni autorización, tal como indican en www.robotstxt.org se podría crear una carpeta ieja.org/norobots/ y dentro de ella poner todas las sub-carpetas y archivos que no queremos sean visitados o indexados, pero ni siquiera eso sería una solución valida, los robots.txt no están para proveer control de acceso por lo que habrá que configurar el servidor http correctamente protegiendo el acceso a carpetas y archivos y añadiendo una solución de control de acceso.
Para realizar un mapa de la aplicación que queremos asaltar existen gran variedad de herramientas, algunas de ellas ya las hemos visto, como es el caso del Paros Proxy que, configurado como Proxy puede interceptar
Tanto esta herramienta como el WebScarab de OWASP tienen muchas funciones adicionales pero tiempo al tiempo, hoy no es el día ;-) Aunque creo que WebScarab no os la he presentado. En el proyecto OWASP no solo ofrecen una metodología de Test de Intrusión en Aplicaciones Web, también ofrecen herramientas de ayuda para su metodología. WebScarab hace una cosa que Paros no hace, también recopila enlaces a Webs externas, en esta en particular hay muchas:
La forma de hacerlo es la misma, configuramos el listener para que capture el tráfico y desde “Spider”, comenzamos a recopilar. Cuando tengamos los resultados es probable que sean distintos del anterior Spider, así que habrá que cruzarlos. Pero no solo de herramientas pre-fabricadas vive el hombre, si recordáis hace unos meses me fabriqué un Spider con unas pocas líneas en Perl para buscar todas las fotos que hicieron en una atracción de Terra Mítica en un día, muy similar al que hizo Lobosoft en C#. Por otro lado en PenTester.es hicieron una mucho más elaborada que mostraba todas las URL de un particular dominio objetivo, se llamaba TargetSearch y nos será muy util para siguientes entradas (estrechamente relacionadas con esta).
¿Qué cuales son las vulnerabilidades que exlotamos haciendo esto? Pues a priori y salvo excepciones, ninguna. Claro está, a veces hay administradores despistados que dejan la carpeta de administración visible a todo el mundo, o aplicaciones mal diseñadas con lapsus en su desarrollo, como fue el caso de los router Zyxel que no protegían
http://[Ip Router]/rpFWUpload.html
y permitían resetear el router fácilmente. Esta primera fase no suele reportar vulnerabilidades, pero si lo hace nos podemos dar una idea del ambiente “descuidado” que tenemos delante.
Buen fin de semana ;-)
1 comentarios:
Un tema muy interesante que ya conocía, pero a mi lo que me interesa es saber cómo protegerme de Webspiders que se usan offline para bajarse el contenido de una página web a golpe de click sin dar visitas y generar publicidad y demás beneficios que reportan las visitas a una web, tipo WebCopier o TeleportPro. Básicamente esto son chorradas que se almacenan en la caché de tu ordenador al navegar por la web y que luego puedes copiar, pero al menos visitas, incitas y haces difrutar al usuario y al propietario que es de lo que se trata, no como los planetas que son gente sin escrúpulos que se lucran del trabajo de los demás. He visto que tu blog es blogger y por ello me interesa tu post, básicamente los que tienen php tienen el asunto solucionando con el .htacces rescribiendo las reglas de las variables que toman, dejan o hacen sesiones con los datos y en general la configuración del php. Como en blogger no hay php y el javascript no es seguro, el uso del robot.txt no sirve de nada y metas tampoco, busco un código del lado del servidor o algo para solucionar esto en xml, porque blogger ni te deja solucionar la mudificación del robot.txt generado automáticamente. ¿Sabes cómo hacerlo?.
Saludos y Gracias.
Publicar un comentario