Una aplicación Web es un software de aplicación que es accesible utilizando un navegador Web o un agente de usuario HTTP/HTTPS. Los principales aspectos de una aplicación Web son: (1) Único directorio o fichero. Se agrupan en una única jerarquía de directorio o fichero: servlets, páginas JSP, ficheros HTML, imágenes, librerías de etiquetas, beans, utility classes, etc. (2) Utilización de un prefijo URL común.

El acceso al contenido de la aplicación Web siempre es a través de una URL que tiene un prefijo común, por ejemplo http://host/Prefijo-Aplicacion Web/file.html. (3) El descriptor de despliegue web.xml permite controlar muchos aspectos del comportamiento de la aplicación Web. (4) Separación-aislamiento. Cada aplicación Web tiene su propio: ServletContext, Class loader, Sessions, prefijo URL, estructura de directorio. La estructura de una aplicación Web consta de: (i) Contenido Web regular y JSP (HTML, hojas de estilo, imágenes, etc.). Directorio principal o un subdirectorio de éste. (ii) Servlets. WEB-INF/classes si el servlet esta desempaquetado. Un subdirectorio de este. (iii) Utility classes y unjarred beans. Mismo lugar que los servlets. (iv) Ficheros JAR. WEB-INF/lib. (v) Web.xml. (vi) Ficheros Tag library descriptor. (vii) Ficheros en WEB-INF no accesibles directamente a los clientes. Los dos objetivos de la seguridad Web son: (1) Proteger al navegador. Los usuarios deberían poder visitar cualquier sitio Web sin producirse daños como robo de información sin el permiso del usuario y que un sitio Web A no pueda comprometer la sesión de otro sitio Web B. (2) Proteger las aplicaciones Web. Las aplicaciones que se encuentran en la Web deberían tener las mismas propiedades de seguridad que se requieren para las aplicaciones autónomas.

Cuando una organización coloca una aplicación Web (por ejemplo, en un servidor Web Tomcat interactuando vía JDBC con un servidor de base de datos SQL) invita a que todo el mundo le envíe peticiones HTTP/HTTPS. Los ataques ocultos en estas peticiones se pueden saltar las funcionalidades convencionales de protección como firewalls, filtros, IPSs, AVs, etc. El código de cada aplicación Web se convierte en parte del perímetro de seguridad. Por tanto el número, tamaño y complejidad de las aplicaciones Web incrementan la exposición del perímetro de seguridad de toda organización. Los sitios Web pueden embeber contenido de muchas fuentes como Frames, Scripts, CSS, Objects (Flash), etc. El término Web 2.0 aparecido aproximadamente desde 2004 se asocia con aplicaciones Web que facilitan la compartición de información interactiva, la interoperabilidad, el diseño centrado en el usuario y la colaboración en la Web. Los sitios Web 2.0 son cada vez más interactivos permitiendo a las personas realizar mayor número de operaciones, más y más cooperativas. Los mashups, por ejemplo, permiten a los usuarios Web integrar fácilmente servicios en su sitio Web que fueron implementados por terceras partes. Uno de los elementos utilizados en la Web 2.0 es la técnica de programación denominada AJAX (Asynchronous JavaScript And XML). Por ejemplo Google Maps utiliza AJAX en aplicaciones Web de tratamiento con mapas. AJAX ayuda a conseguir sitios y páginas Web más atractivas pero también facilita a los adversarios modos para atacar servidores Web y explotar cada vez más sitios. Los sitios Web basados en AJAX presentan una “mayor superficie de ataque” debido a que tienen más interacciones con el navegador y pueden ejecutar JavaScript en el lado del cliente (PC, PDA, iPad, teléfono móvil, iPhone/Android, etc.). AJAX ha incrementado la posibilidad de riesgos del tipo XSS (Cross-Site-Scripting) que ocurren cuando el desarrollador del sitio no codifica adecuadamente las páginas. Un atacante puede explotar este tipo de vulnerabilidades para robar cuentas de usuario, lanzar fraudes de phishing de robo de información, descargar código malicioso en los equipos del usuario.

Actualmente se observa un creciente nivel de riesgo en relación a que las aplicaciones se encuentran bajo ataques. Según el NIST el 95% de las vulnerabilidades se encuentran en el software. Según Gartner, el 75% de los ataques se encuentran en el nivel de aplicación. Según White Hat Security siete de cada diez sitios Web presentan vulnerabilidades serias. Según Forrester el 62% de las organizaciones han experimentado una brecha de seguridad en los pasados doce meses. Según Cenzic con datos procedentes del NIST (con su NVD, Nacional Vulnerability Database del NIST), MITRE, SANS, US-CERT y OSVDB señala una tendencia de crecimiento de vulnerabilidades de aplicaciones Web respecto al porcentaje total, así en el segundo cuatrimestre del 2008 se midió un 73%, en el tercer cuatrimestre del 2008 se midió un 80% y en los cuatrimestres tercero y cuarto del 2009 se midió un 82%. Según IBM la tendencia de vulnerabilidades en aplicaciones Web ha pasado de una cuenta acumulativa de 2.000 en el 2004 a unas 15.000 en 2008. Según Gartner en el 2010 el 60% de las organizaciones TIC podrían ya incluir la detección de vulnerabilidades de seguridad como una parte integral de sus procesos SDLC (Software Development Life Cycle). Según el informe “Website Security Statics Report” de Tom Brennan del 2010, el porcentaje de sitios Web que han tenido al menos una vulnerabilidad son: ASP (74%), ASPX (73%), Cold Fusion (86%), Struts (77%), JSP (80%), PHP (80%), Perl (88%), así mismo el porcentaje de sitios Web que tienen al menos una vulnerabilidad son: ASP (57%), ASPX (58%), Cold Fusion (54%), Struts (56%), JSP (59%), PHP (63%), Perl (75%).

Según Texas CISO de febrero de 2010 las tendencias de ataques para el 2010 son: (i) Malware, gusanos, y troyanos. Difundidos por correo electrónico, mensajería instantánea, sitios Web infectados o maliciosos. (ii) Botnets y zombis. Mejoran sus capacidades de cifrado y ocultación y son más difíciles de detectar. (iii) Scareware. Consiste en software de seguridad gratuito falso contaminado con malware. (iv) Ataques en el software del lado del cliente. Como navegadores (Safari, Mozilla Firefox, Google Chrome, Opera, Netscape, IE (Internet Explorer), Webkit, etc.), media-players, lectores de PDF, etc. (v) Ataques de chantaje. Ataques DDoS, malware que  exige dinero y uno no accede le cifra el disco duro haciéndolo no operativo. (vi) Ataques a Redes Sociales. La confianza de los usuarios en amigos online posibilita que estas Redes sean un objetivo prioritario para los atacantes no sólo las RRSS de ocio sino también las profesionales. (vii) Cloud Computing. Crece su uso lo que lo convierte en otro objetivo la máxima prioridad para atacantes. (viii) Aplicaciones Web. Se sabe que se desarrollan con controles de seguridad inapropiados. (ix) Recortes de presupuestos. Es un gran problema para el personal de seguridad y un “chollo” para los ciber-criminales.

Tipos de componentes y estructura Web.

Los principales componentes estructurales Web son: (i) Los clientes/navegadores. (ii) Los servidores. Se ejecutan sobre hardware sofisticado con procesadores multi-núcleo. (iii) Las cachés. Posibilita implementaciones interesantes y reducir las esperas. (iv) Internet. Es la infraestructura global de red que facilita la transferencia de datos bajo la pila de protocolos TCP/IP. Los principales componentes semánticos Web son: (a) El protocolo HTTP (Hyper Text Transfer Protocol). HTTP es un protocolo simple, sin estados, petición/respuesta, no cifra los datos, del nivel de aplicación en la pila de protocolos TCP/IP entre navegador y servidor y si se integra con SSL/TLS forma el HTTPS. Algunos mensajes de petición HTTP son: GET, el cliente pide al servidor un documento especificado mediante un URL; PUT, envía un documento del servidor al cliente; HEAD, recupera información acerca del documento especificado por el URL, no el propio documento; OPTIONS, recupera información sobre opciones disponibles; POST, envía el cliente información al servidor, por ejemplo anotación; DELETE, elimina un documento especificado por un URL; TRACE, hace eco de la petición entrante; CONNECT, para uso por cachés. El primer tipo de mensajes HTTP son las peticiones, el navegador del cliente construye y envía mensajes como: la petición HTTP típica es: GET http://www.labrs.com/index.html HTTP/1.0. El segundo tipo de mensajes es el de respuesta, los servidores Web construyen y envían mensajes de respuesta, una respuesta típica HTTP es: HTTP/1.0 301 Moved Permanently Location http://www.rs.com/lab/index.html. El navegador Web en el lado del cliente se comunica con uno o más servidores. El navegador hace una petición y el servidor responde con una respuesta. Para mantener el estado entre peticiones, el servidor genera un token de sesión, este identificador se pasa entre el navegador y el servidor con cada petición/respuesta. Una cookie es un fragmento de datos que puede ser pasado con la petición/respuesta, por ejemplo como cookie de seguimiento para averiguar los gustos de cada usuario. 

Las versiones de HTTP son: (i) HTTP 1.0 (RFC 1945). Es un protocolo de parada y espera. Utiliza una conexión TCP separada para cada fichero. El establecimiento y liberación de la conexión ocurre para cada fichero. Se caracteriza por un uso ineficiente de paquetes. El servidor debe mantener muchas conexiones durante el TIME_WAIT. Los clientes hacen peticiones al puerto 80 de los servidores Web, utilizan DNS para resolver el nombre del servidor en dirección IP. Los clientes hacen conexión TCP separada para cada URL. Algunos navegadores abren múltiples conexiones TCP (Netscape cuatro por defecto). El servidor devuelve la página HTML. Existen muchos tipos de servidores con una variedad de implementaciones. El servidor Apache es el más utilizado, disponible gratuitamente. El navegador interpreta la página y pide objetos embebidos. (ii) HTTP 1.1 (RFC 2068). Presenta mayor rendimiento, utiliza conexiones persistentes, pipelining, opciones de caché y soporta compresión. Las conexiones persistentes utilizan la misma conexión TCP para transferir múltiples ficheros. Reduce el tráfico de paquetes de forma significativa y puede o no incrementar el rendimiento desde la perspectiva del cliente si la carga en el servidor aumenta. El pipelining consiste en empaquetar tantos datos en un paquete como sea posible. Requiere campo(s) de longitud dentro de la cabecera HTTP. Puede o no reducir el tráfico de paquetes o incrementar el rendimiento. En este caso la estructura de la página es crítica. (b) Los lenguajes como HTML (Hyper Text Markup Language) y XML (eXtensible Markup Language). HTML es un subconjunto de SGML (Standardized General Markup Language) facilita un entorno con enlaces embebidos a otros documentos y aplicaciones. Los documentos HTML utilizan elementos para identificar secciones de texto de diferente propósito o visualizar características, por ejemplo letra en negrilla. Los elementos de marcaje no los ve el usuario cuando se visualiza la página. Los documentos son presentados por navegadores. No todos los documentos de la Web son HTML y los desarrolladores utilizan editores WYSIWYG para generar HTML. (c) Mecanismo de nombres con URIs (Uniform Resource Identifiers).

Los recursos Web necesitan nombres/identificadores es decir URIs. El recurso puede residir en cualquier parte de Internet. Los URIs son un concepto abstracto: un puntero a un recurso al que los métodos de petición pueden aplicarse para generar respuestas potencialmente diferentes; el URI enlaza con aplicaciones genéricas (http, ftp, telnet, etc.). Un método de petición es por ejemplo buscar o cambiar el objeto. La instancia de URL: http://www.abc.com/index.html incluye protocolo (http://, ftp://, telnet://, mailto:Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.), servidor y recurso. La URL http;//seclab.net:80/class?name=ITK5#doc6 incluye: protocolo HTTP, nombre del host seclab.net, puerto 80, path class, query ?name=ITK5 y fragmento doc6. La forma más popular de URI es el URL (Uniform Resorce Locator), existen diferencias, ver RFC 2396. Un URL es un URI que además de identificar un recurso, proporciona los medios para localizar el recurso describiendo su mecanismo de acceso primario. Un URN identifica un servicio genérico, no un recurso específico: urn:servicio:sos.policia. La estructura Web se especifica de forma básica: (i) Los clientes utilizan la aplicación navegador Web para enviar URIs vía HTTP/HTTPS a servidores solicitando una página Web. (ii) Las páginas Web se construyen utilizando HTML, XML, etc. y constan de texto, gráficos, sonido, videos, ficheros embebidos. (iii) Los servidores o cachés responden con la página Web pedida o con un mensaje de error. (iv) El navegador del cliente presenta la página Web devuelta por el servidor. La página Web se escribe utilizando HTML/XML, se visualiza texto, gráficos, sonidos, videos en el navegador y también se escriben datos. Todo el sistema opera bajo protocolos de TCP/IP como IP, TCP, DNS, etc. En los comienzos de la Web, los sitios Web estaban formados por páginas Web estáticas. Obviamente el contenido estático impide que las aplicaciones interactúen con el usuario. Para saltar esta limitación los fabricantes de servidores Web permitieron que programas externos se ejecutaran implementando el mecanismo CGI (Common Gateway Interface). Esto posibilitó que la entrada del usuario se envíe a un programa externo o script, se procese y luego el resultado se devuelva al usuario. CGI es el antecesor de todos frameworks de aplicaciones Web, lenguajes de script y servicios Web utilizados hoy en día. Algunas tecnologías utilizadas por las aplicaciones Web son CGI, filtros, scripting, frameworks de aplicaciones Web como J2EE de Sun, PHP, ASP.NET, JSP, Javascript, Java, HTML. Algunos lenguajes de scripting del lado del cliente son DHTML (HTML, XHTML, HTMLx.o), JavaScript, Java (Applets), VBScript, Flash, ActiveX, XML/XSL, CSS (Client-Side Scripting). Se desarrollan aplicaciones Web utilizando PHP, CSS, AJAX, JavaScript, Apache, SQL, JSON, Ruby. Eclipse es un entorno de desarrollo de aplicaciones Web, open-source, gratuito que soporta Java y otros lenguajes, posibilita la estructura de despliegue automática, ver http://www.eclipse.org/downloads/. Se integra con Tomcat, ver http://www.coreservlets.com/Apache-Tomcat-Tutorial/eclipse.html/.

Sistema de modelización de amenazas STRIDE/DREAD para aplicaciones Web
El sistema de modelización de amenazas STRIDE/DREAD se basa en: (1) STRIDE que identifica de las siguientes categorías de amenazas: (i) Spoofing identity. La falsificación de identidad es un riesgo clave en aplicaciones que tienen muchos usuarios pero utilizan un único contexto de ejecución a nivel de aplicación y base de datos. Los usuarios no deben poder actuar como cualquier otro usuario o convertirse en ese usuario. (ii) Tampering with data. Los usuarios pueden cambiar cualquier dato entregado a ellos y pueden por tanto cambiar la validación del lado del cliente, datos GET y POST, cookies, cabeceras HTTP, etc. La aplicación no debería enviar datos al usuario, tales que las tasas de interés o períodos que son obtenibles dentro de la propia aplicación.

La aplicación debe comprobar con cuidado cualquier dato recibido del usuario para identificar si es cuerdo y aplicable. (iii) Repudiation. Los usuarios pueden disputar transacciones si existe insuficiente capacidad de seguimiento/trazabilidad y de auditoría de la actividad del usuario. Por ejemplo, si un usuario dice “no transfiero dinero a esta cuenta externa” y no se puede realizar un seguimiento de sus actividades desde el principio hasta el fin de la aplicación, es extremadamente probable que la transacción tendrá que anularse. Las aplicaciones deberían tener controles de repudio adecuados como logs de acceso Web, registros de auditoría en cada nivel y un contexto de usuario desde arriba hacia abajo. Preferiblemente la aplicación debería ejecutarse como el usuario, pero esto a menudo no es posible con muchos frameworks. (iv) Information Disclosure. Los usuarios no se fían de presentar detalles privados a un sistema. Si es posible para un atacante revelar detalles del usuario, anónimamente o como un usuario autorizado existirá un período de pérdida de repudio. Las aplicaciones deben incluir controles fuertes para prevenir alteración de identificación del usuario, particularmente cuando utilizan una única cuenta para ejecutar la aplicación entera. El navegador del usuario puede fugar información. No todos los navegadores implementan correctamente las políticas de no caché pedidas por las cabeceras HTTP. Cada aplicación tiene una responsabilidad para minimizar la cantidad de información almacenada por un navegador, en el caso que fugue información y puede utilizarlo un atacante par aprender más acerca del usuario o incluso llegar a convertirse en ese usuario. (v) Denial of Service. Las aplicaciones deberían ser conscientes de que pueden ser objeto de un ataque de denegación de servicios. Para aplicaciones autenticadas, recursos caros como grandes ficheros, cálculos complejos, búsquedas de gran resistencia o queries largas deberían reservarse para usuarios autorizados, no usuarios anónimos. Para aplicaciones que no tienen este lujo, cada faceta de la aplicación debe ser implementada para realizar tan poco trabajo como sea posible, utilizar queries de base de datos rápidas (o no) y no exponer grandes ficheros o proporcionar links únicos por usuario para prevenir un ataque de denegación de servicios simple. (vi) Elevation of Privilege. Si una aplicación proporciona roles de usuario y administrador, es vital asegurarse que el usuario no pueda elevarse a roles de privilegio mayores. En concreto, no proporcionar los links de usuario no es suficiente, todas las acciones deben controlarse por una matriz de autorización para asegurar que sólo los roles correctos puedan acceder a la funcionalidad con privilegios. (2) DREAD. Se utiliza para calcular el valor de riesgo que es la media aritmética de cinco elementos: Riesgo (DREAD) = (Daño + Reproductibili-dad + Explotabilidad + Usuarios afectados + Descubribilidad) / 5. Consta de: (i) Damage Potential. Mide la cantidad de daño causado si una amenaza se realiza. El valor cero significa ninguno, el valor cinco significa que los datos del usuario individual se han visto afectados o comprometidos y valor diez significa los datos de todo el sistema. (ii) Reproducibility. Mide la facilidad de que se reproduzca esta amenaza. El valor cero significa muy difícil o imposible incluso para los administradores de la aplicación. El valor cinco significa si se requiere una o dos fases, puede necesitarse ser un usuario autorizado. El valor diez significa tener sólo un navegador, barra de dirección sin logged on. (iii) Explotability. Mide qué se necesita para explotar esta amenaza. El valor cero significa disponer de herramientas de ataque a medida, avanzadas, destreza en redes y programación avanzada, el valor cinco significa que exista malware o se realice utilizando herramientas de ataque normales y el valor diez significa tener sólo un navegador. (iv) Affected Users. Mide cuantos usuarios se verán afectados por esta amenaza. El valor cero significa ninguno, el valor cinco significa algunos usuarios pero no todos y el valor diez significa todos los usuarios. (v) Discoverability. Mide la facilidad para descubrir esta amenaza. El valor cero significa muy difícil o imposible, requiere acceso al sistema o fuente, el  valor cinco significa que se puede detectar de averiguar u observar las trazas de red, el valor nueve significa que tener detalles de fallos como este son del dominio público y pueden descubrirse utilizando motores de busqueda de alto rendimiento como Google, Yahoo, etc. y el valor diez significa que esta en la barra de dirección o en un formulario.  

Vulnerabilidades comunes en Web. Medidas proactivas de seguridad
Existen diversas fuentes que nos permiten conocer las vulnerabilidades, amenazas y riesgos a la seguridad a nivel Web: (i) OWASP (Open Web Application Security Project) genera cada año un documento denominado “Top 10 de amenazas/riesgos mitigables”, para ello se basa en los datos en bruto procedentes del CVE de MITRE. (ii) SANS genera cada año un documento denominado “SANS Top 20 Internet Security Attack Targets”. (iii) eEye Digital Security. (iv) Zero-Day Tracker. (v) US-CERT, actualiza la información cada semana. Una de las vulnerabilidades de los navegadores (o browsers) Web como IE, Safari, etc. consiste en que realicen de forma automática acciones tendentes a limitar el impacto de inconsistencias de páginas Web, por ejemplo si una página Web pierde la etiqueta de fin, el navegador visualiza la página de forma adecuada o puede ejecutar Javascript aunque se divida esta palabra en dos líneas en una etiqueta, en una indicando java y en otra especificando script. Este hecho lo aprovechan los atacantes para hacer que un sitio/página Web opere de forma no deseada. En torno a la seguridad de aplicaciones Web existen errores extendidos por ejemplo el que dice que SSL/TLS protege un sitio Web, o que los firewall convencionales protegen las aplicaciones Web o que los IDS/IPS protegen los servidores Web y de base de datos. La seguridad de aplicaciones Web no se puede tratar sólo con antivirus, exploradores de vulnerabilidades, firewall/DMZ, IDS/IPS, gestión de parches/cumplimientos, seguridad del servidor sino que además se deben incluir otras salvaguardas como análisis estático (algunos fabricantes de herramientas de análisis estático son Veracode, Fortify, Coverity, KlocWork, OunceLabs) y análisis dinámico (algunos fabricantes de herramientas de análisis dinámico son IBM con RationalAppscan, HP con WebInspect, Ntobjectives con NTOSpider, Cenzic con Hailstorm, Whitehat Security), firewall de aplicación Web/XML, revisión-análisis de código, protección integral del SDLC, formación para desarrolladores.

Los enfoques reactivos frente a las brechas de seguridad son insuficientes y conducen a un ciclo sin fin de crisis que suelen conducir en el desastre total. Por tanto actualmente son esenciales medidas de protección proactivas como: (i) Test de seguridad integrado en el ciclo de vida desde desarrollo software también denominado SDLC (Software Development Life Cycle). (ii) Re-comprobación y re-certificación si existen cambios significativos en el sistema o el entorno de aplicaciones Web. (iii) Revisar la arquitectura y analizar las posibles zonas de desprotección (de gap). (iv) Implantar seguridad integrada y defensa en profundidad. (v) Utilizar firewalls XML para los servicios Web, capaces mitigar amenazas como SQL Injection, ataques a entidad externa, payload recursivo, envenenamiento del Schema, Denegación de servicios, buffer overflow, etc. utilizando verificación WSDL, validación del Schema XML, routing basado en contenido XML, etc.

Consideraciones finales
Nuestro grupo de investigación lleva trabajado más de veinte años en el área de la síntesis y análisis de la seguridad en el contexto de las aplicaciones Web.
Este artículo se enmarca en las actividades desarrolladas dentro del proyecto LEFIS-APTICE (financiado por Socrates. European Commission).

Autor: Prof. Dr. Javier Areitio Bertolín – E.Mail: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. Catedrático de la Facultad de Ingeniería. Director del Grupo de Investigación  Redes y Sistemas. Universidad de Deusto .

Bibliografía
-    Areitio, J. “Seguridad de la Información: Redes, Informática y Sistemas de Información”. Cengage Learning-Paraninfo. 2010.
-    Areitio, J. “Nuevos enfoques en el análisis de sistemas de detección-prevención y gestión de ataques-intrusiones”. Revista Conectrónica. Nº 123. Enero 2009.
-    Fry, C. and Nystrom, M. “Security Monitoring. Proven Methods for Incident Detection on Enterprise 200.

Más información o presupuesto