Seguridad de una aplicación web

Tarsis.net, 11 de diciembre de 2013

Las aplicaciones web (web apps) tienen requerimientos de seguridad diferentes de las aplicaciones de puesto de trabajo (stand-alone) o cliente-servidor, derivadas de que son aplicaciones pensadas para vivir en una red abierta, no en una red u ordenador privados. En este post hablaremos de las consideraciones de seguridad imprescindibles en una de estas aplicaciones. No trataremos de otro tipo de comprobaciones de calidad (funcionales, usabilidad o rendimiento, por ejemplo).

Aplicaciones web empresariales Contacte con nosotros.

Comunicándonos con una aplicación web

Una aplicación web, gracias al protocolo HTTP, dispone de tres vías para comunicarse con el usuario: los métodos del protocolo GET, POST y las cookies. Las interacciones entre el usuario y la aplicación vendrán por una de esas tres vías, que deben ser cuidadosamente comprobadas para evitar que usuarios maliciosos puedan causar daños en la propia aplicación, en sus datos o en el propio sistema que los alberga. Cualquier persona que desarrolle un servicio web debe tener siempre en mente que los datos provinientes de esos métodos (input de usuario) es inseguro, y tratar esos datos en consecuencia.

El método GET

Una aplicación web puede permitir que el usuario la utilice pasándole información vía la dirección (URL) de la propia página. Veamos un ejemplo:

http://www.dominio.com/index.php?user=12345&session=4b7177f1277c0cc0

En esta dirección web pueden verse los parámetros ‘user’ y ‘session’ con sus valores, viajando en la propia dirección de la página. La página hará uso de ellos en la forma en que se haya establecido, pero el caso es que esos valores forman parte de la invocación de la página y pueden ser alterados simplemente modificándolos en la barra de dirección del navegador. ¿Qué ocurre con nuestra aplicación si un usuario cambia en la URL el valor de ‘user’ por ‘54321’?

El método POST

Cada vez que rellenamos un formulario, lo más probable es que los datos incluidos en éste sean enviados al servidor utilizando otro método diferente, llamado POST, que permite el envío de mayor volumen de información que GET y que permite también que se añadan determinados datos adicionales por parte de la página. Estos formulario suelen contener información personal (por ejemplo los formularios de contacto) o nos permiten hacer uso de alguna capacidad del servicio (por ejemplo publicar información en nuestra página web). La entrada de datos a través de formularios debe ser mirada con lupa por el desarrollador de una web app, dado que es un punto de entrada preferido por muchos de los delincuentes informáticos. ¿Qué ocurre si el usuario malicioso inserta código ejecutable por el servidor en uno de esos campos de formulario?

Cookies

Una de las características más destacadas del protocolo HTTP es que no reconoce estados (es stateless), es decir, cada petición que le hacemos a un servidor es perfectamente independiente e indistinguible de cualquier otra, y no se guarda información sobre peticiones anteriores. Sin embargo muchas aplicaciones requieren mantener determinada información a lo largo de una sesión de usuario (por ejemplo se necesita saber que un usuario ha hecho login en una aplicación para permitirle el acceso mientras dure la sesión). Las cookies son un mecanismo por el que el servidor envía pequeñas informaciones textuales a nuestro navegador para que sean almacenadas en nuestro ordenador, y que nuestro navegador envía de vuelta al servidor en cada conexión subsiguiente. De esta forma el servidor puede reconocer a nuestro navegador durante un cierto tiempo en el futuro y tratarlo de una forma o de otra en función de esas informaciones. ¿Qué ocurre si un usuario malicioso es capaz de robar la cookie que nos autentica en un determinado servidor?

Lo que el servidor esconde

Muchos servidores web están incorrectamente configurados para mostrar el contenido de directorios que carecen de una página web maestra (index) o bien para mostrar el contenido de ficheros cuyo tipo desconocen. Bajo estas condiciones es fácil para un usuario malicioso explorar el servidor en busca de ficheros conteniendo usuarios y claves para acceder a bases de datos, averiguar cuál es la estructura de la información y planear un ataque que permita la extracción de datos o la instalación de malware o contenidos ajenos a nuestro servicio. Aunque la configuración del servidor no es necesariamente de la competencia de quien desarrolla y despliega una aplicación, todos los servidores web disponen de una configuración particular por carpeta. Si nos ocupamos de una aplicación instalada en una carpeta, esa configuración por carpeta es un terreno fronterizo entre la administración de sistemas y el desarrollo de apliaciones y el responsable de la aplicación no puede vivir ajeno a cómo esté hecha. Un tema aparte, pero relacionado, es la conveniencia del uso de SSL/TLS — es decir, de un servidor web seguro, con un certificado digital emitido por una autoridad de certificación reconocida — en aquellas aplicaciones que transporten datos sensibles o personales. La instalación de una aplicación en un servidor web seguro (HTTPS) encripta las comunicaciones entre el navegador y el servidor, impidiendo que terceras partes, que puedan tener acceso al tráfico IP, puedan inspeccionar su contenido. Otra parte importante es el mantenimiento seguro de las contraseñas de usuarios. Si nuestro servicio incluye algún tipo de autenticación mediante pares usuario/clave, el almacenamiento de esas contraseñas debe hacerse de forma encriptada (normalmente mediante el uso de un algoritmo de hash). De lo contrario puede ocurrirnos como recientemente a Adobe, cuyo servicio fue asaltado y sus bases de datos con usuarios (38 millones), direcciones de correo electrónico y claves en claro fueron robadas y más tarde publicadas, abriendo la posibilidad a que se tomara el control de esos usuarios en el servidor de Adobe, pero también en otros servicios donde los usuarios poco disciplinados mantuvieran la misma clave. Y, para terminar, es siempre muy importante mantener un buen sistema de backup que nos permita reconstruir los datos del servicio en cualquier circunstancia de catástrofe. Este punto, que siempre se menciona de forma rutinaria, suele ser en el que más fallan muchas organizaciones que, aún conociendo la necesidad, no actúan de acuerdo a la importancia del asunto.

Buen desarrollo y buen mantenimiento

Muchas de las aplicaciones actuales utilizan un motor de bases de datos, y esas bases de datos pueden contener información muy valiosa para los delincuentes informáticos, tales como información personal o bases de datos de clientes. Cada agujero de seguridad que tenga nuestra aplicación web es un potencial punto de acceso a esos datos. No comprobar adecuadamente una aplicación web es una invitación a que alguien pueda hacerse con todos esos datos. Para complicar más las cosas, hay millones de ordenadores zombies, pertenecientes a botnets, que están escaneando continuamente sitios web para detectar automáticamente sus vulnerabilidades y comunicarlos al centro de control (C&C) de la red de delincuentes. Como colofón, el desarrollo, instalación y mantenimiento de una aplicación web no es un asunto trivial. Aquí hemos tocado sólo aspectos relativos a la seguridad de la aplicación, aunque hay muchos otros aspectos que deben ser tomados en cuenta para que el servicio sea realmente funcional y estable. Una organización debe plantearse siempre dedicar los recursos necesarios para asegurar que sus servicios Internet disponen de las garantías necesarias para evitarse problemas que afectan a su negocio y a su imagen.