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 mas “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 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 qué 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 sistema de detección de intrusos tradicional.
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
Descarga el artículo completo para continuar leyendo:
Comentarios recientes