113 - Utilizar Cookies seguras en el desarrollo aplicaciones web - 17/07/2011


Autor: Lic. Cristian F. Borghello

www.segu-info.com.ar


Introducción

El tema de las Cookies quizás sea el tema más trillado y "bien conocido" por quien desarrolla aplicaciones web ya que son las que permiten recordar datos previos ingresados por el usuario (ej. nombre de usuario), respetar sus gustos (ej. colores de la interfaz) y controlar distintas acciones de la aplicación.

Pero aquí quizás radica el mayor problema de las mismas: al ser un tema sencillo de comprender y manipular, se ignoran la mayor parte de los errores que se pueden cometer y las vulnerabilidades que se pueden generar con el uso de las mismas.

Este artículo analiza las distintas opciones disponibles para generar cookies seguras sólo para dominios válidos, elegir qué información almacenar en las mismas y protegerlas de distintos tipos de ataques.


Antes que nada: ¿Qué son la cookies?

El protocolo HTTP fue diseñado para no ser orientado a conexiones ni mantener el estado de las mismas (stateless) por lo que los desarrolladores y las aplicaciones deben generar algún tipo de dato para mantener la conexión del usuario activa durante el tiempo que dure la sesión.
Una cookie está definida por un par de datos (nombre = valor) que se almacena en el cliente y que permite dicho control.

Cuando el servidor establece una conexión con el cliente envía una cabecera "Set-Cookie" con el par de valores mencionado y otras opciones que el desarrollador puede incluir y que, entre otras cosas, definirán distintos grados de seguridad para la cookie y la sesión.

Por ejemplo a continuación se muestra parte de una cabecera establecida cuando se ingresa a Segu-Info:

HTTP/1.1 200 OK
Set-Cookie: id=22ad8fc32d010042; path=/; domain=.segu-info.com.ar
Content-Encoding: gzip
Content-Type: text/html;charset=UTF-8
Content-Length: 7075
Date: Sun, 17 Jul 2011 13:53:04 GMT

Nota: existen muchas formas de visualizar/modificar las cookies desde la línea de comandos o con el uso de aplicaciones. Inicialmente es recomendable el uso de Live HTTP Headers, una extensión para Firefox.


Cliente vs servidor

Teniendo en que cuenta que el protocolo HTTP no cifra ningún tipo de información, con el procedimiento descripto se presentan algunos problemas:

Esto significa que se deberá analizar apropiadamente qué información transmitir y almacenar en las cookies y posteriormente protegerlas de forma adecuada.

Además, cuando se establece una conexión de un usuario, se genera una cookie de "SessionId", que no es distinta de cualquier otra cookie y por lo tanto debe administrarse desde el servidor de forma apropiada: el verdadero poder de las sesiones radica en su validación del lado del servidor, no del cliente.


Cómo proteger las cookies

Como en cualquier proceso de seguridad lo primero que se debe hacer es delimitar el entorno y para ello en las cookies se puede definir para qué dominio o subdominio serán válidas. Este procedimiento ofrece las ventajas de delimitar apropiadamente el uso de cada cookie y la imposibilidad de usar la misma en aplicaciones distintas.

Al crear la cookies, el analista y el desarrollador deberán establecer:

Por supuesto, dependiendo del nivel de criticidad de la aplicación, las respuestas serán distintas: no es lo mismo proteger una sesión de home-banking a través de SSL que un sitio de acceso general.


Definición de una cookie

El formato para definir una cookie es el siguiente:

setcookie (Nombre,Valor, Expiración, Ruta, Dominio, Secure, HTTP-Only)

setcookie ('Usuario', 'Segu-Info', 0, '/foro', 'www.segu-info.com.ar', true, false )

En este caso se establece una cookie llamada "Usuario" con el valor "Segu-Info", que no caduca y que sólo es válida para el dominio "www.segu-info.com.ar" y el directorio "/foro". Si el dominio se define como "dominio.com" será valido para cualquier subdominio del mismo pero si se define "blog.dominio.com", sólo será válido para el mismo. Por otro lado, si no se define, la ruta por defecto es "/".

La anteúltima variable indica que la cookie sólo será transmitida sobre un canal cifrado SSL.

La última HTTP-Only es una protección adicional que indica la forma en que podrá ser accedida (lectura/escritura) por el lenguaje de script y resulta efectiva para proteger la aplicación contra ataques de Cross-site Scripting (XSS).

Es importante destacar que si bien es recomendable su uso para agregar una capa de seguridad adicional, algunos navegadores aún no reconocen totalmente "HTTP-Only" o simplemente la ignoran y que también existen alternativas para evitarlas a través del uso de TRACE XMLHttpRequests.


Procedimiento para asegurar las cookies

En base a lo descripto, se pueden realizar las siguientes recomendaciones para mantener las cookies seguras.

  1. Crear sólo las cookies necesarias para la aplicación y directorio correspondiente
  2. Limitar la información almacenada en las cookies a lo estrictamente necesario y bajo ningún punto de vista almacenar información sensible (contraseñas, IDs, tarjetas de crédito, etc.)
  3. Utilizar "HTTP-Only" para evitar el uso de ataques y scripts genéricos de XSS
  4. En caso de aplicaciones e información sensible es preferible enviar las cookies sólo a través de canales cifrados. Si la aplicación ya se ejecuta sobre HTTPS, el costo de hacer esto es casi nulo: agregar "Secure = True" al momento de crear la cookie
  5. Al igual que cualquier otro dato de entrada, validar del lado de servidor toda la información recibida en las cookies, ya que la misma pudo haber sido manipulada por el cliente

Conclusiones

Mucha información es transmitida y almacenada en las cookies y su uso es sumamente común en cualquier aplicación. Lamentablemente pocos desarrolladores conocen o aplican las buenas prácticas de seguridad sobre las mismas e incluso sitios como Google, Twitter y Facebook hace poco tiempo comenzaron a utilizarlas sobre canales cifrados.

Como hemos visto, asegurar una cookie no tiene ningún secreto siempre y cuando exista la decisión de hacer uso de esas técnicas y se haya realizado un análisis concienzudo de qué tipo de información almacenar en las mismas.



Buenos Aires, 17 de julio de 2011



Actualidad

Virus-Antivirus