HPP27 Seguridad en Aplicaciones Web

Artículo publicado en la revista @RROBA # 96 Suplemento “Hack Paso a Paso” #27 – Noviembre 2005

(Material Sin Editar)

Copyright © 2005 Hernán Marcelo Racciatti

http://www.hernanracciatti.com.ar

1

Seguridad en Aplicaciones Web Introducción Hoy día, no quedan dudas respecto de que Internet, ha significado un cambio rotundo en cuanto al modo en que millones de personas al rededor del mundo se comunican. En tal sentido, probablemente muchos de vosotros coincidan en el hecho de que esta bien llamada “revolución”, se deba en gran parte al crecimiento de uno de sus servicios más “vistosos”: la World Wide Web (WWW). Sin ser injustos por ejemplo, con servicios de la talla de la mensajería electrónica (Otro gran instrumento que junto a los servicios de WWW, ha sido uno de los grandes responsables respecto de la velocidad con que esta revolución se ha llevado a cabo), podemos decir sin temor a equivocarnos, que el fenómeno de la WWW ha contribuido enormemente, a acercar Internet a las masas. Si bien es cierto que en un principio, lo que hoy conocemos como WWW no era más que un conjunto de sitios sirviendo páginas estáticas, poco a poco este concepto ha ido evolucionando hasta convertir dicho contenido estático, en contenido dinámico capaz de ofrecer altos niveles de interactividad. Pero nada ocurre por casualidad, y aspectos tales como dinamismo e interactividad, y nuevas funcionalidades, requieren del desarrollo de aplicaciones capaces de cumplir con nuestras, cada vez más exigentes expectativas. Pero... espera un momento... hagamos un ejercicio mental... si se estima que hoy día existen cerca de 53 millones de sitios en la Web, muchos de los cuales probablemente se encuentren corriendo algún tipo de aplicación, y a esto agregamos el creciente desarrollo de aplicaciones de negocios, que bajo el slogan “Web Enabled”, se ejecutan internamente en millones de empresas como un componente fundamental de negocio, en sus Intranets corporativas, que probabilidad crees que tiene un atacante de encontrar alguna vulnerabilidad? ... eh de aquí el porque del presente artículo... Hablando correctamente... Contrariamente a lo que suele pensar el público en general, cuando hablamos de “Seguridad en Aplicaciones Web”, no estamos hablando de defectos o vulnerabilidades en sistemas operativos o servidores HTTP, no estamos hablando de problemas que puedan ser resueltos instalando el ultimo service pack del software de moda, que se encuentra corriendo en tus equipos, por el contrario, estamos hablando de vulnerabilidades en tu propio software, en las aplicaciones que tu has desarrollado o pedido a alguien que desarrolle por ti . Probablemente debido a la popularidad de los términos “Web” y “Aplicación”, y la relación existente entre estos y una cantidad de aspectos relativos a la seguridad en





2

Internet, es que con frecuencia suelen englobarse en la categoría de “Seguridad en Aplicaciones Web” una serie de puntos que poco tienen que ver con la definición formal de esta área. Puesto que a lo largo de este artículo trataremos temas específicos de la Seguridad en Aplicaciones Web, es importante que tengas claro a que nos estamos refiriendo. La Seguridad en Aplicaciones Web, se encuentra relacionada pura y exclusivamente con: la lógica, la escritura de código y el contenido de una aplicación web. Si bien esta claro, que toda aplicación web, requiere de un entorno conformado por elementos externos, tales como sistemas operativos, servidor web, servicios, etc. para poder cumplir su función, los inconvenientes o controles relativos a estos últimos, no deben ser considerados problemas propios de la aplicación web. Defectos y Vulnerabilidades: Características Diferenciales De la lectura de los párrafos anteriores, probablemente haya quedado bastante clara la diferencia entre asegurar un webserver y asegurar una aplicación web. Lo mismo sucede cuando hablamos de los defectos y vulnerabilidades. Contrariamente a lo que suele pasar por ejemplo, con las vulnerabilidades encontradas en sistemas operativos, las vulnerabilidades o debilidades propias de tu aplicación web nunca aparecerán registradas con una entrada CVE (Common Vulnerabilities and Exposures), la solución a tal vulnerabilidad no será provista con el ultimo Service Pack de Windows o como un parche al kernel de linux!! y lo que es aún peor... probablemente el único modo que tengas de conocer si realmente eres vulnerable... sea testeando tu propia aplicación. Como dato adicional, quizás sea bueno tener en cuenta que las vulnerabilidades que suelen ser encontradas en aplicaciones web, por lo general pueden ser explotadas en múltiples plataformas, a diferencia de lo que suele ocurrir con otro tipo de vulnerabilidades que son altamente dependientes no solo de la plataforma, sino también del nivel de parcheado de la misma. Otro aspecto importante detrás de los defectos y vulnerabilidades encontrados en aplicaciones web, es que las mismas a menudo suelen ser fáciles de explotar. De hecho, probablemente baste en la mayoría de los casos, con el conocimiento necesario y un pequeño set de herramientas tan sencillas e inocuas como el mismísimo browser que acostumbras a utilizar durante tus paseos por la WWW. Por otra parte, puesto que por lo general los ataques a aplicaciones web, suceden precisamente en la capa de aplicación, por puertos que necesariamente “deben” encontrarse habilitados (80/443) para que de hecho las cosas funcionen (Ya sabes... “permitir HTTP desde cualquier origen”), a menudo puede no ser nada fácil la tarea de monitorear ataques mediante un sistemas de detección de intrusos tradicional.





3

Un resumen de lo mencionado, podría ser que la seguridad perimetral habitualmente implementada, suele no ser una medida efectiva cuando nuestro objetivo es el de proteger nuestras aplicaciones web de su explotación. Antes de comenzar... Bien... seguramente estarás ansioso por comenzar con la parte práctica, para ser sincero también yo, por tanto solo me llevará unas líneas transmitirte aquellos recursos a los cuales imperiosamente deberás acceder si tu intención para con el testing de aplicaciones web es seria. Como seguramente sabrás, la magia detrás de gran parte del intercambio de información a través de Internet, se encuentra relacionado con un sencillo pero apasionante protocolo denominado HTTP (TCP/80). El concepto detrás de este protocolo es simple, las conversaciones entre las partes cliente y servidor, se llevan a cabo utilizando un set de instrucciones conocidos como “métodos” (GET, HEAD, POST, etc.), a partir de los cuales es posible establecer diferentes tipos de “requerimientos”, los cuales a su vez son respondidos con “mensajes”. Si como parte de nuestras tareas de evaluación de la seguridad, vamos a interactuar con servidores HTTP y aplicaciones WEB, suena lógico que conozcas la forma en la que una conversación debe ser establecida, no crees? Ahora bien, la explicación de este apasionante protocolo, se encuentra obviamente fuera del alcance del presente artículo, aunque desde ya, su entendimiento resultará de vital importancia para quienes estén deseosos de conocer que es lo que realmente sucede entre bambalinas. Para quienes gusten, el mejor comienzo sin dudas será la cuidada lectura de los siguientes RFCs: http://www.faqs.org/rfcs/rfc1945.html http://www.faqs.org/rfcs/rfc2616.html http://www.faqs.org/rfcs/rfc2660.html http://www.w3.org/Protocols Laboratorio de Pruebas Como siempre digo, al igual que el Hacking, el testeo de seguridad es algo práctico. Puesto que como seguramente habrás aprendido, muchas de las técnicas relacionadas con las prácticas de testeo, pueden ser consideradas ilegales si son realizadas sin el consentimiento por escrito del cliente o propietario del servicio/aplicación a evaluar (sin mencionar la falta a la ética profesional que esto significa!), esta vez se me ha ocurrido proponerte la utilización de un magnifico entorno de pruebas, de nombre “WebGoat”, que habiendo sido desarrollado por la gente del proyecto OWASP (The Open Web





4

Application Security Project), representa una gran oportunidad para quienes se encuentren deseosos de dar sus primeros pasos en lo que a testing de aplicaciones web se refiere. Tal como se menciona en su sitio oficial, “WebGoat” es una completa aplicación web, desarrollada en J2EE, y diseñada específicamente con el objeto de que la misma sirva de plataforma de pruebas y enseñanza respecto de las vulnerabilidades que suelen ser encontradas en el mundo real. A través de diferentes lecciones, el usuario tiene la oportunidad de entender y explotar una vulnerabilidad real. A su vez, el sistema provee al usuario de una serie de pistas, permitiendo el autoaprendizaje. Pero pongamos manos a la obra... comenzaremos por descargar e instalar “WebGoat” en nuestro entorno de pruebas. Dirigiremos nuestro browser hacia la siguiente URL: http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61824 Una vez allí, mi recomendación es que descarguen el archivo de nombre, “WebGoat_StandAlone_with_JDK1.5.zip”, puesto que de este modo evitarán lidiar con la instalación del software requerido por la aplicación en forma separada (Java, Apache Tomcat, etc.). Al momento de descargar la aplicación, puede que la misma les resulte algo pesada (41 Mb aproximadamente) pero créanme... les hará pasar un momento divertido. Antes de continuar, déjame aclarar que debido a que “WebGoat” ha sido desarrollado en JAVA, no deberemos preocuparnos por su portabilidad (Existen instaladores para Linux y Windows, además de la posibilidad de descargar el .war e instalarlo en tu “Servidor de Aplicaciones”). Bien, una vez descargado el archivo comprimido, y suponiendo que Windows haya sido tu elección, tan solo deberás descomprimir el ZIP en una carpeta, teniendo en cuenta que el espacio ocupado por la aplicación en su conjunto, ronda los 100 MB. Ingresando dentro de la mencionada carpeta, encontraras un archivo de nombre “webgoat.bat”, el cual deberás ejecutar. Luego de unos instantes, y si todo ha salido como lo esperamos, tendremos corriendo en nuestro equipo de pruebas, un pequeño servidor web sirviendo la aplicación “WebGoat”. Para comprobarlo, solo bastará con que dirijas tu browser a la siguiente URL: http://localhost/WebGoat/attack Allí se te solicitara un usuario y una contraseña. Por defecto, podrás completar ambos valores con la misma palabra: “webgoat”. Perfecto... llegado este punto, deberías estar viendo en pantalla, algo similar a lo dispuesto en la Figura 1.





5

Figura 1 Las Herramientas Correctas... Aunque probablemente lo hayamos mencionado muchas veces antes, nunca esta de más recalcar el hecho de que gran parte del éxito de un ataque al momento de testear nuestras propias aplicaciones, se encuentra relacionado no solo con el conocimiento de los protocolos y las técnicas involucradas, sino también con la correcta selección del set de herramientas a utilizar. De todos modos y para ser franco... una de los principales atractivos detrás del testing de aplicaciones web, radica en la posibilidad de llevar a cabo el mismo, con tan solo un par de herramientas entre las que se cuentan básicamente un browser y un proxy capaz de exponer los paquetes HTTP en crudo. No obstante, y a fin de agilizar la tarea del encargado del testing, varias son las herramientas que hoy día nos permiten optimizar el tiempo dedicado a tal menester. En el presente artículo, nos encargaremos principalmente de comentar el propósito de algunas de las herramientas frecuentemente utilizadas, acompañando las mismas con algún ejercicio para el cual nos valdremos del entorno de pruebas instalado en el punto anterior. Como siempre... Netcat





6

Si llevas un tiempo en la administración de redes o la evaluación de seguridad, probablemente no te sientas asombrado al ver netcat relacionado con un artículo de seguridad en aplicaciones web. No por nada Netcat se ha ganado el apodo de “Navaja Suiza”. Sus funciones y utilidades se cuentan por cientos. Puesto que probablemente suela ser una herramienta que utilices a menudo, no profundizaremos sobre ella. No obstante, sería bueno recordar que una de las funciones principales de Netcat, es aquella que le permite entablar diálogos con distintos protocolos, y HTTP es uno de ellos! Ok, seguramente dirás que son muchas las herramientas que hacen esto, y probablemente tengas razón, la diferencia es que Netcat realmente lo hace con mucha “crudeza”, lo cual la hace sumamente interesante cuando todo lo que queremos es hablar HTTP al nivel mas crudo. Bien, probablemente no tengas problemas para hallar e instalar netcat en tu equipo de pruebas, por tanto pasemos directamente a ver el modo mediante el cual podremos interactuar con un servidor HTTP: D:\Tools\nc --v 127.0.0.1 80 localhost [127.0.0.1] 80 (http) open HEAD / HTTP/1.0 [cr] [cr] HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Date: Mon, 18 Jul 2005 13:02:49 GMT Connection: close sent 17, rcvd 146: NOTSOCK Nota: Recuerda que una vez escrito el comando ha ser ejecutado, deberás enviar dos retornos de carro o “Enter” a fin de completar el proceso de conexión y obtener un resultado valido. Bien, no hay mucho que explicar aquí verdad??, lo que intentamos hacer, es realizar una conexión al puerto 80 (donde en mi caso, escucha el servidor web instalado por WebGoat) y luego pasar en la misma línea una petición mediante el método HEAD de HTTP, el cual nos informa del software servidor que se encuentra corriendo en el host objetivo (Recuerda que esta información puede no ser fiable en ciertas circunstancias. Para más información, puedes revisar el artículo “HTTP Fingerprintig”, mas adelante en esta misma edición). Ahora bien, es cierto que Netcat sigue siendo imbatible en muchos aspectos, no obstante, es importante que conozcas que la verdadera “Navaja Suiza” para el testeador





7

de aplicaciones web, sin lugar a dudas se llama “Curl”. Curl es una fantástica herramienta de línea de comandos, capaz de trabajar entre otros con los siguientes protocolos: FTP, Gopher, http, https, ldap y telnet. Llegar a dominar “Curl” puede tomarte algún tiempo básicamente porque no existe nada relacionado con el “dialogo” que “Curl” no pueda resolver!! “Curl” probablemente sea tema de un próximo artículo, aunque si te encuentras ansioso, hacia el final del artículo encontraras un enlace desde donde podrás descargar y comenzar a realizar tus pruebas con esta fantástica herramienta. Me gusta... me lo llevo La auditoría de aplicaciones web, a menudo conlleva el análisis de código y la verificación manual de ciertos aspectos para los cuales suele ser provechoso contar con una copia local del website objetivo. Documentar la estructura de la aplicación, la composición de sus directorios o la simple inspección de cada parte de ella, es una tarea fundamental al momento de realizar una auditoria de este tipo. En tal sentido, probablemente hayas escuchado alguna vez hablar de diferentes herramientas que nos permiten con mayor o menor grado de eficiencia, realizar dicha tarea. Wget, Teleport, etc. son solo alguna de ellas. En tal sentido, me gustaría recomendarles una herramienta que he venido usando desde hace algún tiempo cuando me encuentro trabajando bajo Windows (Aunque su versión original para Linux/Unix/BSD obviamente no deja de ser una excelente opción). De nombre “WinHTTrack” (OpenSource, GPL), este website copier nos brinda la posibilidad de sencillamente descargar un completo sitio existente en Internet, a nuestro disco duro de modo tal de obtener un mirror, el cual puede ser revisado off-line con el detalle necesario. Descargar e instalar WinHTTrack, es sumamente sencillo. Una vez en tu equipo, deberás ejecutar el asistente, seguir sus recomendaciones y comenzar a utilizarlo. Una vez dentro de la aplicación, podremos tomarnos el tiempo necesario para conocer la gran cantidad de opciones que nos brinda (Compresión, Conexiones Múltiples, Java y Flash parsing, etc.) De momento nos limitaremos tan solo a realizar un mirror de nuestro entorno de pruebas. Para ello, seguiremos los siguientes pasos:

1. Una vez dentro de WinHTTrack, seleccionaremos un nombre para nuestro proyecto (“Hack Paso a Paso” en mi caso), así como el path donde se albergara la copia (Digamos... d:\TEMP\WebsiteImage). 2. Deberemos completar la información relativa a la URL del site objetivo, para lo cual haremos click sobre el botón “Añadir” y escribiremos “localhost/WebGoat/attack”. En esta misma pantalla ingresaremos el conjunto de información correspondiente a usuario y contraseña (Login/Pass), que como recordaras es “webgoat”. 3. Por ultimo, haremos click sobre el botón “Finalizar” y esperaremos a que la copia se complete (Figura 2).





8

Figura 2 Si todo ha salido como esperábamos, a partir de este momento contaremos con un espejo del site objetivo, al cual podremos acceder localmente, lo cual nos permitirá conocer en forma exacta la estructura de la aplicación auditada, encontrar archivos no expuestos vía link, archivos de backup, o ejecutar herramientas tales como alguna de las tantas versiones de “grep” para Windows, con el objeto de lanzar diferentes tipos de búsquedas de strings con el objeto de identificar aspectos de la aplicación que requieran nuestra atención (Campos “HIDEN”, palabras “password”/”database”/”connect”, direcciones de correo embebidas dentro del codigo “@”, etc.) Por ultimo, solo mencionaremos que a fin de hacernos la vida un tanto mas sencilla al momento de trabajar con diferentes copias, WinHTTrack genera un índice (index.html) dentro del directorio temporal donde hemos decidido almacenar nuestros proyectos, de modo tal que el acceso sea sencillo incluso con decenas de mirrors. Proxies y mas proxies… Hay algo que es seguro, si intentas verificar la seguridad de tu aplicación web, tarde o temprano necesitaras de un proxie local!! Puesto que el tema de proxies se ha tocado en reiteradas oportunidades en este suplemento, solo recordaremos que el propósito de los mismos es precisamente el de interceptar las peticiones del cliente, antes de que estas viajen al servidor objetivo, a fin de que las mismas puedan ser inspeccionadas o modificadas.





9

Aunque resulte difícil de creer, miles de sitios hoy día basan parte de su esquema de seguridad en rutinas javascript, que pueden ser superadas fácilmente, con tan solo utilizar un Proxy local y eliminar las mismas (Si se ejecutan del lado del cliente). Del mismo modo, restricciones en cuanto a la extensión del input por parte del usuario en formularios, frecuentemente puede ser superado, sencillamente realizando modificaciones posteriores al requerimiento hecho por la aplicación web, pero antes que estas lleguen al servidor. Un ejemplo de esto podría ser el campo de una aplicación que siendo susceptible a SQL Injection, posee una validación del lado del cliente, mediante la cual tan solo se nos permite insertar dos caracteres. Lo que a simple vista podría ser un problema desde el punto de vista de la ejecución de las técnicas de SQL Injection que nos encargamos de explicar en números anteriores, no seria problema si pudiéramos interceptar el trafico http antes de partir de nuestro equipo, insertáramos la sentencia a inyectar (evitando el código que restringía esta posibilidad desde la aplicación) y finalmente enviáramos este requerimiento al host objetivo. Achilles Achilles sin lugar a dudas merece un lugar en nuestro set de herramientas. Aunque descontinuado desde hace algunos años, y a pesar de ser uno de los primeros en su tipo, hoy día continua siendo la opción elegida por muchos. Su utilización es sumamente sencilla y su ejecución casi no requiere recurso alguno. Achilles tan solo requiere para funcionar, la modificación del seteo Proxy de nuestro browser. En Internet Explorer por ejemplo, logramos esto fácilmente, ingresando a: “Herramientas”/”Opciones de Internet”/”Conexiones”/”Configuraciones de LAN” y activando el checkbox bajo la leyenda “Utilizar un servidor…”. Puesto que Achilles trabaja por defecto con el port 5000, los valores a ingresar deberían ser precisamente “Localhost” o “127.0.0.1” para la dirección y “5000” para el puerto. (Figura 3) Hecho esto, estaremos en condiciones de ingresar a Achilles, activar las opciones “Intercept Mode ON”, “Intercept Client Data”, “Intercept Server Data (text)” y clickear sobre el botón de “Play” (Start Proxy). A partir de este momento, si vamos a nuestro browser e intentamos acceder a cualquier sitio, seremos capaces de observar el requerimiento en crudo en achilles. Una vez allí, podremos decidir si lo enviamos o lo modificamos previamente (Figura 4). Simpático no es cierto? Paros / WebScarab Paros Proxy es la herramienta que recomendare desde aquí, para que puedas llevar a cabo las prácticas propuestas en “WebGoat”… si lo se… se que desde OWASP se promociona la utilización de una herramienta llamada “WebScarab” para dicho menester, pero lo cierto es que a pesar de que “WebScarab” es una herramienta esencial en muchos sentidos, aun sigo prefiriendo la versatilidad, velocidad y funciones añadidas de Paros cuando de Proxy se trata… cuestión de gustos… tu sabes… es bueno poder elegir. Obviamente… “WebScarab” es una herramienta que puedes y DEBES investigar por tu cuenta, sin lugar a dudas hallaras productivo el tiempo que pases con ella.





10

Figura 3 Como se encuentra implícito en su nombre, Paros Proxy tiene una función principal bien definida, interceptar trafico http entre el cliente y el Server, y esta definición incluye entre otros, aspectos tales como: cookies, form fields, etc. Pero Paros no es solo un Proxy, es un verdadero set de herramientas para el testeador web. Desarrollado principalmente en java y bajo un concepto modular mediante el cual es posible la adición de diferentes plugins entre los que se encuentran (en la instalación por defecto de su última versión, 3.2.3 al momento de escribir este articulo): spider, scanner, filtros, encoded/decoded varios, etc, Paros se convierte en un recurso esencial para nuestra tarea. Paros Proxy puede ser descargado de la página del proyecto: http://sourceforge.net/project/showfiles.php?group_id=84378 Si escoges la versión a ejecutar sobre Windows, deberás descargar el ejecutable del instalador que pesa algo así como 1.5.Mb. Una vez hecho esto y con la facilidad que Windows nos tiene acostumbrado, solo será cuestión de algunos “siguientes” antes de que la aplicación se encuentre lista para ser utilizada en nuestro sistema.





11

Figura 4 Pero… un momento recuerdas nuestra aplicación de pruebas? que tal si probamos la eficiencia de Paros con el? Ok.. entonces te diré lo que haremos, por empezar deberás acceder a WebGoat (Recuerda que si no tienes levantado el servidor, deberás ejecutar “webgoat.bat”, llevar tu browser hasta http://localhost/WebGoat/attack e ingresar el valor “webgoat” como usuario y contraseña) y una vez allí seleccionar en el menú que se encuentra a la izquierda, el ejercicio “Hidden Field Tampering” dentro de la sección “Unvalidated Parameters”. Si has seguido estos sencillos pasos, deberás encontrarte en este momento con una pantalla similar a la mostrada en la Figura 5. Bien, antes de continuar te explicare cual es el objetivo de este ejercicio. A menudo suele suceder que desarrolladores inexpertos, utilizan campos ocultos en sus formularios, con el objeto de realizar el tracking, administrar variables de login o manipular precios. Dada la facilidad con la que esta acción puede ser llevada a cabo, con frecuencia encontraras este tipo de casos en tus auditorias. Precisamente, esta lección de “WebGoat”, apunta a que aprendas el modo en el que puede ser explotado un campo oculto a fin de obtener un producto a un precio distinto que el que se sugiere en el shopping virtual. A fin de realizar esta sencilla explotación comenzaremos por, al igual que hicimos al momento de presentar Achilles, configurar las opciones Proxy de nuestro browser. Esta vez siguiendo la configuración por defecto de Paros, cambiaremos los valores actuales por los siguientes:





12

Dirección: localhost Puerto: 8080

Figura 5 Hecho esto, volvemos a recargar la página web y por si acaso te hubieras perdido en el camino, te recuerdo que la URL del ejercicio que utilizaremos a efectos de presentar Paros es: http://localhost/WebGoat/attack?Screen=16 (How to Exploit Hidden Fields) Bien… como veras la situación es que se nos propone realizar la compra (Purchase) de una unidad del producto “46 inch HDTV (model KTV-551)” por un importe total de 4999.99. Para comprender un poco mejor que es lo que sucede en background cuando accionamos el botón de compra (Purchase), seguiremos el siguiente procedimiento:

1. Puesto que en pasos anteriores configuraste tu browser para que interactúe con Paros, lo primero que haremos es verificar que esto este funcionando. A tal efecto, haremos clic sobre el botón “Purchase”, para luego dirigirnos a Paros y ver que es lo que ha sucedido.

2. Una vez en Paros, veras como en la sección inferior de su pantalla principal (History), se observa el POST realizado por la aplicación. Para ver su contenido, no tendrás más que seleccionar esta línea con un clic y el mismo se mostrara sobre el sector superior derecho (Request Tab).

3. Como puedes observar, la ventana “Request” en Paros, se encuentra a su vez dividida en dos partes, la superior contiene información general respecto del





13

post y la inferior, los valores que se están enviando al servidor: QTY=1&Price=4999.99, los cuales corresponden a la cantidad ordenada y el precio del producto!!

Ahora que conocemos el modo de operar de esta aplicación, veamos como deberíamos utilizar Paros Proxy, para cambiar el precio antes de que el POST original sea enviado al servidor. Para eso deberás:

1. Acceder nuevamente a “WebGoat”, apretar la tecla Backspace de tu ordenador a fin de volver un paso hacia atrás en la aplicación.

2. Volver a Paros y configurarlo para que en vez de actuar como en el paso anterior (digamos como … mmm… un Proxy transparente si se me permite la expresión..) trapee/intercepte nuestra solicitud y nos permita cambiarla. Para esto será suficiente con acceder en la esquina superior derecha, al TAB mencionado en la interfaz de Paros sencillamente como “Trap” y activar el checkbox “Trap Request”.

3. Ahora, accederemos nuevamente a “WebGoat” y ejecutaremos otra vez el botón “Purchase”, solo que esta vez, estaremos interceptando el requerimiento a través de Paros, tal como se muestra en la Figura 6.

4. Una vez hecho esto, bastara con editar el precio (Price) llevándolo de $4999.99 a… mmm… digamos… $9.99 … parece justo no? y presionar el botón “Continue”.

5. Por ultimo, volviendo a “WebGoat” podremos observar que se informa de un cargo en nuestra tarjeta de crédito de $9.99 (Figura 7). Lección Concluida!

Bien, como habrás podido observar, la utilización de aplicaciones Proxy tal como Achilles, Paros, WebScarab o cualquiera de ellos brindan una excelente oportunidad de conocer que es lo que sucede por debajo de una aplicación Web. Obviamente el aprovechamiento de campos ocultos, es tan solo una debilidad más que puede ser explotada con poco esfuerzo. Si sientes interés, ahora que has realizado tus primeros pasos con aplicaciones Proxys, probablemente puedas avanzar con el resto de los ejercicios propuestos por “WebGoat” por tus propios medios. La herramienta indispensable: El Browser Pocas herramientas son tan importantes para quien desea introducirse en la evaluación de seguridad de aplicaciones web, como el Browser. Habrás notado a lo largo de este artículo, que se ha mencionado lo importante de conocer el modo en que la aplicación se comporta. Lo cierto, es que no importa cuantas herramientas automáticas de detección de vulnerabilidades se empleen en la tarea, ninguna podrá suplir la ausencia de un explorador y la mente de la persona encargada del testing.





14

Figura 6

Figura 7 Por tal motivo, debes ser cuidadoso con la elección del browser a utilizar en tus tareas de testing. En mi caso en particular, recomiendo instales Firefox (Si es que no lo has





15

hecho aun) y verifiques por ti mismo el valor agregado que este puede traer a tus evaluaciones de seguridad. Como seguramente sabrás, Firefox es parte del proyecto Mozilla, y el principal contendiente de Internet Explorer. Algunas de las ventajas de Firefox, se encuentran relacionadas con su velocidad, una concepción modular y abierta a desarrolladores a fin de que su funcionalidad pueda ser extendida con relativa facilidad. En mi opinión, esta ultima característica es la que convierte a Firefox en La Elección al momento de elegir un browser como herramienta de evaluación de la seguridad, puesto que no solo puedes descargar “Extensiones” con alguna funcionalidad adicional que requieras para tus pruebas o que facilite tu labor, sino que incluso puedes desarrollar las propias. A solo efecto de ejemplificar lo mencionado, pasare a comentar en forma arbitraria, tan solo dos plugins que no deberían faltar en tu instalación de Firefox. La instalación de los mismos es sencilla, una vez descargado e instalado Firefox, el cual encontraras en el siguiente enlace: http://www.mozilla.org/products/firefox tan solo deberás encontrar las extensiones deseadas (https://addons.mozilla.org/extensions/?application=firefox) y chiquear sobre su vinculo a fin de que las mismas sean instaladas! IE View La utilidad de este addon es sumamente sencilla, pero nos permitirá ahorrar tiempo en algunas circunstancias. En contadas ocasiones, puede pasar que una de las paginas que estamos evaluando, se encuentre desarrollada para ser visualizada con alguna “preferencia” mediante IE. Este pequeño addon, agrega un sencillo ítem al menú conceptual (Ver esta pagina en IE), mediante el cual rápidamente podremos visualizar una pagina en IE. Web Developer WebDeveloper (Figura 8), es uno de esos addons que debes tener. Su funcionalidad, realmente sorprende y nombrar todo lo que es capaz de hacer llevaría un articulo tan largo como el que tienes entre manos. Edición de formularios, validación de código, acceso rápido a diferentes funcionalidades del propio browser, eliminación de cookies de sesión, información detallada de los links que conforman la pagina visualizada, y otras tantas opciones, hacen de este plugin una herramienta interesante al momento de realizar una evaluación de seguridad. SwitchProxy Tool Que puedo decir de SwitchProxy Tool (Figura 9), un addon sencillo y pequeño que llega como caído del cielo para automatizar y llenar de practicidad, una tarea tan tediosa para quienes solemos lidiar en nuestros test de seguridad con diferentes aplicaciones de Proxy local, como el cambio de sus valores asociados en nuestro browser. Una vez instalado este complemento, se agregara un botón a nuestra barra de tareas, a partir del cual una vez cargada y configuradas las diferentes configuraciones de proxyes, se nos permitirá rápidamente cambiar de uno a otro con solo presionar un botón





16

Figura 8

Figura 9 Conclusión A lo largo del presente articulo, tuvimos oportunidad de mencionar las herramientas básicas que suelen ser utilizadas al momento de encarar la evaluación de seguridad de





17

aplicaciones web. Vimos la forma en la que podemos utilizar netcat para interactuar a nivel http con el webserver, hicimos referencia a la importancia de la utilización de proxys locales a fin de interceptar, eventualmente modificar y volver a enviar peticiones con valores cambiados al servidor, mostramos el modo en que una copia local del website o la aplicación objetivo puede ayudar en la búsqueda de vulnerabilidades o factores de interés a través del código mismo de la aplicación y por ultimo mencionamos algunos complementos que una vez instalados en nuestro browser (Puntualmente hablamos de Firefox) son capaces de agilizar nuestro trabajo. Obviamente, lo visto hasta aquí es tan solo la punta de un ovillo que deberás comenzar desmembrar si tu intención es conocer mas, acerca de esta magnifica actividad. Muchos conceptos y herramientas han quedado fuera del alcance de este artículo. Herramientas automatizadas de búsqueda de vulnerabilidades (Whisker, Wikto, Nikto, WebScarab, N-Stealth, Pazcan, WebInspect, AppDetective, etc.) diferentes tipos de ataques (Ataques a la autenticación, la autorización, las cookies, Cracking, Brute Force, SQL Injection, Code Injection, Error Handling, Cross-Site Scripting, Parameter Buffer Overflow, etc.) y practicas tales como la auditoria de código o el empleo de aplicaciones tales como “stunnel” para aprovechar todas nuestras herramientas inclusive en aquellos casos donde el site objetivo se encuentra configurado para trabajar con SSL (Secure Socket Layer), son solo algunos de los aspectos por donde puedes continuar tu aprendizaje. De cualquier modo, y a pesar de lo mencionado, Internet esta lleno de recursos de los cuales podrás aprovecharte al momento de continuar tu aprendizaje. No pierdas de vista proyectos como “WebGoat” de OWASP, así como otros de similares características tal es el caso de “Hackme Bank” o “Hakme Books” de Foundstone y “Webmaven” de Maven Security. Por ultimo, pero no por ello menos importante, no podemos dejar de lado antes de dar por concluido este articulo, la importancia de conocer al menos los aspectos básicos del desarrollo de pequeños scripts o aplicaciones en lenguajes tales como Perl o Python, puesto que debido a sus características particulares, estos suelen ser una herramienta fundamental al momento de automatizar test que de otro modo serian complicados o tediosos de reproducir manualmente. Dicho esto, solo me resta desearte suerte en tu aprendizaje. Los entornos de prueba son un ámbito excelente al momento de romper mientras se aprende, sin tener que pagar las consecuencias… aprovéchalos… y mantente dentro de la ley, sin lugar a dudas… al final de cuenta te reportara mas ganancias ;) . Hernán Marcelo Racciatti http://www.hernanracciatti.com.ar





18

Referencias y Lecturas Complementarias http://www.faqs.org/rfcs/rfc1945.html http://www.faqs.org/rfcs/rfc2616.html http://www.faqs.org/rfcs/rfc2660.html http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61824 http://www.w3.org/Protocols http://www.cve.mitre.org http://www.owasp.org http://www.webappsec.org http://www.vulnwatch.org/netcat/nc111nt.zip http://curl.haxx.se http://www.httrack.com http://gnuwin32.sourceforge.net/packages/grep.htm http://www.wingrep.com http://www.parosproxy.org http://sourceforge.net/project/showfiles.php?group_id=84378 https://addons.mozila.org http://www.mozilla.org/products/firefox https://addons.mozilla.org/extensions/?application=firefox http://www.foundstone.com http://sourceforge.net/projects/webmaven

Documents

HPP27 Seguridad en Aplicaciones Web