| Artículos | 01 MAY 2007

Test de intrusión en una aplicación web

Tags: Histórico
Chema Alonso.
Durante los tres meses anteriores nos hemos centrado en el desarrollo de test de intrusión de sistemas en general, viendo pormenorizadamente tanto las herramientas como los procedimientos necesarios para obtener los mejores resultados. En esta ocasión vamos a abordar únicamente las aplicaciones web, ya que, por diseño, se trata de servicios de carácter público, accesibles para todo el mundo, lo que hace que sean uno de los principales focos de atracción para los hackers.

Cuando tratamos con un sistema nos encontramos ante un entorno en el que se están utilizando protocolos, arquitecturas y aplicativos comerciales o estandarizados, es decir, que podemos encontrarnos con entornos de servidores Apache o Internet Information Services, o un servidor DNS basado en Windows Server 2003, entre otros. En esos entornos, utilizar las herramientas de fingerprinting o los scanners de vulnerabilidades es lo más habitual, ya que están optimizadas para buscar vulnerabilidades y fallos de seguridad de software de uso público, pero, ¿qué sucede con las aplicaciones web desarrolladas por nuestro equipo de programación? ¿Serán capaces esas herramientas de detectar un fallo de seguridad en nuestro software? La respuesta es no, pero no por eso podemos descuidar este tipo de servicios, ya que, por ejemplo, podemos encontrarnos con un fallo de seguridad en un simple radio button que permita a un atacante tumbar nuestro servidor de bases de datos. En estos casos, los test de intrusiones de sistema anteriormente comentados no podrán ayudarnos, ya que, para ellos, nuestros sistemas se encontrarán perfectamente configurados y con los parches de seguridad al día.
En el presente artículo vamos a mostrar algunos de los errores más comunes que hemos encontrado durante el proceso de test de intrusión en aplicaciones web a lo largo de los últimos meses. Aunque algunas de ellas puedan sonar a ciencia ficción y leyenda urbana, lo cierto es que internet está plagado de aplicaciones web mal construidas que permiten, debido a fallos en la programación, acceder a los recursos más inhóspitos. Al igual que ocurría con los test de penetración de sistemas, vamos a comentar algunas de las herramientas que nos servirán de ayuda, pero en este caso hemos de tener en cuenta que, debido a que nos encontramos con software desarrollado a medida en la mayor parte de los casos, el trabajo debe ser más “artesano”.

Código Limpio
El primer método que utilizará cualquier usuario malintencionado para atacar un sistema es simplemente leer el código fuente programado por el desarrollador, ya que es el recurso principal que le permitirá conocer las vulnerabilidades más importantes. Por este motivo, es muy importante que el código de las páginas web que tenemos publicadas sean lo más limpios posibles y de el menor número de pistas acerca de los procesos más sensibles. Es recomendable que sólo haya funciones relativas a la interfaz de usuario, y nunca recomendaremos dejar comentarios o ficheros que no se vayan a utilizar en el servidor web. Éste es un detalle muy importante, ya que, de ahí se puede obtener mucha información sobre la estructura del sitio web al que nos enfrentamos. Además, a la hora de desarrollar una aplicación web hay que tener en cuenta que únicamente debe realizar las acciones para las que se ha diseñada ya que, de lo contrario, puede ser utilizada en nuestra contra. En este sentido hay que tener presente que todo lo que por defecto no está prohibido, está permitido.

Fichero Robots.txt y Estadísticas
Los buscadores de internet utilizan arañas que rastrean todos los dominios publicados en la Red de redes e indexan toda la información del sitio. Esto puede llevar a que se indexe información sensible que pueda ser descubierta a través de los motores de búsqueda de estas arañas. Es conveniente utilizar el fichero robots.txt para evitar que las arañas recojan información de nuestro sitio que pueda ser sensible. Funciona escribiendo las rutas que no queremos indexar, de tal forma que, cuando una araña encuentre este fichero, ignorará las rutas especificadas y no las indexará. Eso sí, también hay que tener en cuenta que si especificamos en este fichero rutas sensibles, como por ejemplo, /admin/, /basededatos/ o similar, de esta forma estaríamos dando información muy provechosa para el atacante, porque, con sólo leer ese fichero, encontraría las rutas de los servicios que precisamente queremos mantener en privado. Lo mismo sucede con las estadísticas; si éstas son públicas, cualquiera va a poder ver la estructura del sitio, y sería como tener el listado de directorios abierto. De hecho, esto es peor aún, porque las páginas que reciban parámetros mediante la modalidad get van a quedar reflejadas con sus parámetros, dejando al descubierto los nombres de las variables que usamos a nivel interno. Por lo tanto, es importante configurar de forma segura las estadísticas. Por último, tampoco es recomendable usar directorios ocultos, ficheros de configuración o bases de datos accesibles y predecibles, ya que la imaginación de un atacante no tiene límites.

Datos desde el Cliente
Todos los datos que vengan desde el cliente son totalmente susceptibles de ser manipulados. Hemos de tener en cuenta que están en la máquina del atacante, son suyos y él decide qué es lo que envía. Por lo tanto, si dejamos algo en manos del cliente, hemos de asumir que la información que recojamos es posible que venga ya manipulada, por él o por un atacante que controle al cliente. Tampoco es recomendable confiar en métodos de autenticación en Javascript, flash, ActiveX o Applet Java. Por desgracia, aunque parezca muy evidente, aún es muy común encontrar aplicaciones web protegidas por películas flash. En este sentido, si tenemos una tienda online, nunca debemos utilizar el precio que se te envía desde el cliente, ya que no seríamos los primeros en recibir precios manipulados, con la consiguiente pérdida de beneficios.
En la imagen 2 hemos incluido una captura en la que se aprecia la manipulación de datos con uno de los programas utilizados a tal efecto, Odysseus. Se trata de un proxy local que se utiliza para manipular los datos enviados desde el cliente a través de peticiones por Post o Get hacia internet. No obstante, además de Odysseus, existen otros como BurpSuite o Achilles, aunque en todos los casos el funcionamiento es similar. Actúa captando los datos que salen del navegador del cliente, cumpliendo todas las restricciones que se hayan puesto en javascript o cookies, entre otros. Posteriormente llegan al programa, que actúa como Proxy, y para los datos para que sean manipulados a placer. Una vez modificados se envía y obtenemos los resultados que nos interesan.
Los algoritmos matemáticos tampoco sirven para nada. En esos casos se pide una contraseña, a la que se somete a un “complejo” algoritmo, que a su vez generará un número. Si éste es correcto, se navega a la página destino (que generalmente no se puede ver porque no está en el código y depende de la contraseña). En caso contrario, se bloquea. Todos esos algoritmos comúnmente utilizados se rompen con ingeniería inversa, así que, o bien están ya vulnerados porque son algoritmos comerciales, o bien se pueden romper por ser uno propio, generalmente de menor calidad. Hay que tener en cuenta que con autenticaciones y proteccio

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información