Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development

HTTP Conciso: El estado y seguridad de HTTP

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Web Architecture

Spanish (Español) translation by Jonathan Samines (you can also view the original English article)

En éste último capítulo veremos los aspectos de seguridad de HTTP, incluyendo como identificar usuarios, como la autenticación HTTP funciona, y por qué algunos escenarios requiren HTTPS (HTTP seguro). A lo largo del camino, también aprenderemos un poco sobre como gestionar el estado con HTTP.


La Web sin estado (y sin embargo con estado)

HTTP es protocolo sin estado, lo cual quiere decir que cada transacción solicitud-respuesta es independiente de cualquier transacción previa o futura. No hay nada en el protocolo HTTP que requiera que un servidor retenga la información sobre una solicitud HTTP. Todo lo que necesita hacer un servidor es generar una respuesta para cada solicitud. Cada solicitud llevará toda la información que un servidor necesita para crear la respuesta.

La naturaleza sin estado de HTTP es uno de los factores conductores en el éxito de la web. Los servicios en capas que vimos en el capítulo anterior, servicios como el almacenamiento en caché, son posibles (o al menos más sencillos) porque cada mensaje contiene toda la información requerida para procesar el mensaje. Los servidores proxy y los servidores web pueden inspeccionar, transformar y almacenar en caché los mensajes. Sin el almacenamiento en caché, la web no podría escalar para adaptarse a las demandas de Internet.

Sin embargo, la mayor parte de las aplicaciones y servicios web que construimos sobre HTTP dependen altamente del estado.

Una aplicación de banca querrá que un usuario inicie sesión antes de permitir al usuario ver los recursos relacionados a su cuenta. Como cada solicitud sin estado llega para un recurso privado, las aplicaciones quieren asegurarse que el usuario ya esté autenticado. Otro ejemplo es cuando el usuario quiere abrir una cuenta y llenar formularios en un asistente de tres páginas. La aplicación querrá asegurarse que la primera página del asistente sea completada antes de permitir al usuario enviar la segunda página.

Afortunadamente, hay muchas opciones para almacenar el estado en una aplicación web. Una solución es embeber el estado en los recursos que son transferidos al cliente, por lo que todo el estado requerido por la aplicación viajará de vuelta en la siguiente solicitud. Esta solución típicamente requiere algunos campos ocultos y funciona mejor con estado de vida corta (como el estado requerido para moverse a través de un asistente de tres páginas). Incorporar el estado en los recursos mantiene el estado dentro de los mensajes HTTP, así que es una solución altamente escalable, pero puede complicar la programación de la aplicación.

Otra opción es almacenar el estado en el servidor (o tras el servidor). Esta opción es requerida para el estado que tiene que estar activo por un largo tiempo. Digamos que el usuario envía un formulario para cambiar su dirección de correo. La dirección de correo siempre debe estar asociada con el usuario, así que la aplicación puede tomar una nueva dirección, validar la dirección y almacenar la dirección en una base de datos, un archivo, o llamar a un servicio web para que alguien más se encargue de almacenar la dirección.

Para el almacenamiento en el servidor, muchos frameworks de desarrollo web como ASP.NET también proporcionan acceso a una "sesión de usuario". La sesión puede vivir en memoria, o en una base de datos, pero un desarrollador puede almacenar información en la sesión y obtenerla en cada solicitud subsequente. La información almacenada en una sesión tiene el alcance de un usuario individual (en realidad, la sesión de exploración del usuario), y no está compartida entre múltiples usuarios.

El almacenamiento en sesión tiene un modelo de programación sencillo y es solo adecuado para un estado de corta-vida, porque eventualmente el servidor tiene que asumir que el usuario ha dejado el sitio o cerrado el explorador y el servidor descartará la sesión. El almacenamiento en sesión, si es almacenado en memoria, puede impactar negativamente la escalabilidad, porque las solicitudes subsequentes deben ir exactamente al mismo servidor dónde los datos de sesión residen. Algunos balanceadores de carga ayudan a soportar éste escenario implementando las "sesiones pegajosas".

Podrías estar preguntándote como un servidor puede dar seguimiento a un usuario para implementar el estado de sesión. Si dos solicitudes llegan a un servidor, ¿cómo sabe el servidor si éstas son dos solicitudes del mismo usuario, o si son dos usuarios diferentes cada uno haciendo una única solicitud?

En los primeros días de la web, el software de servidor podría haber diferenciado a los usuarios analizando la dirección IP de cada mensaje de solicitud. En estos días, sin embargo, muchos usuarios viven detrás de dispositivos utilizando la Traducción de Direcciones de Red (NAT por sus siglas en inglés), y por ésta y otras razones puedes tener múltiples usuarios efectivamente en la misma dirección IP. Una dirección IP no es una técnica confiable para diferenciar usuarios.

Afortunadamente hay técnicas más confiables.


Identificación y Cookies

Los sitios web que quieren dar seguimiento a los usuarios frecuentemente dependerán de las cookies. Las Cookies están definidas por RFC6265 (http://tools.ietf.org/html/rfc6265), y éste RFC es acertadamente titulado "Mecanismo de Manejo de Estado de HTTP". Cuando un usuario visita un sitio web por primera vez, el sitio puede darle al explorador del usuario una cookie utilizando una cabecera HTTP. El explorador entonces sabe que tiene que enviar la cookie en las cabeceras de cada solicitud adicional que envíe al sitio. Asumiendo que el sitio web haya colocado algún tipo de identificador único en la cookie, entonces el sitio puede dar seguimiento a un usuario cuando el o ella haga solicitudes, y diferenciar a un usuario de otro.

Antes de entrar en detalles de como lucen las cookies y cómo se comportan, es valioso hacer notar un par de limitaciones. Primero, las cookies pueden identificar usuarios en el sentido que tu cookie es diferente que mi cookie, pero las cookies no autentican a los usuarios Un usuario autenticado ha probado su identidad usualmente proporcionando credenciales como un usuario y una contraseña. Las cookies de las que hablamos hasta ahora solo nos proporcionan un identificador único para diferenciar un usuario de otro, y dar seguimiento a un usuario conforme las solicitudes son hechas al sitio.

Segundo, debido a que las cookies puede dar seguimiento a lo que un usuario está haciendo, vienen con problemas de seguridad en algunos círculos. Algunos usuarios deshabilitarán las cookies en sus exploradores, lo cual quiere decir que el explorador rechazará cualquier cookie que un servidor envíe en una respuesta. Las cookies deshabilitadas presentan un problema para los sitios que necesitan dar seguimiento a los usuarios, claro está, y las alternativas son molestas. Por ejemplo, una solución para las "sesiones sin cookies" es colocar el identificador del usuario en la URL. Las sesiones sin cookies requieren que cada URL que un sitio proporcione al usuario contenga el identificador apropiado, y las URLs se vuelven mucho más largas (lo cual es el por qué ésta técnica frecuentemente es llamada técnica de "URL pesada").


Configurando Cookies

Cuando un sitio web quiere darle a un usuario una cookie, utiliza la cabecera Set-Cookie en la respuesta HTTP.

Hay tres áreas de información en las cookies mostradas en éste ejemplo. Las tres áreas están delimitadas por punto y coma (;). Primero, hay uno o más pares de nombre-valor. Estos pares de nombre-valor están delimitados por el símbolo de dolar ($), y se parecen a como los parámetros del querystring están formados en una URL. En la cookie de ejemplo, el servidor quería almacenar el nombre y apellido del usuario en la cookie. La segunda y tercer área son el dominio y la ruta, respectivamente. Daremos vuelta más tarde para hablar sobre el dominio y la ruta.

Un sitio web puede poner cualquier información que guste en una cookie, aunque hay una limitación en tamaño de 4 KB. Sin embargo, muchos sitios web solo colocan un identificador único para un usuario, quizás un GUID. Un servidor nunca puede confiar en nada almacenado en el cliente a menos que esté criptográficamente asegurado. Si, es posible almacenar datos encriptados en una cookie, pero normalmente es más sencillo almacenar un ID.

Asumiendo que el explorador esté configurado para aceptar cookies, el explorador enviará la cookie al servidor en cada solicitud HTTP subsecuente.

Cuando el ID llega, el software servidor puede rápidamente buscar cualquier dato asociado al usuario en una estructura de datos en memoria, una base de datos o una caché distribuida. Puedes configurar la mayoría de los frameworks de aplicaciones web para manipular las cookies y automáticamente buscar el estado de la sesión. Por ejemplo, en ASP.NET, el objeto Session expone un API para una lectura y escritura sencilla del estado de sesión del usuario Como desarrolladores, nunca tendremos que preocuparnos sobre el envío de la cabecera Set-Cookie, o de leer las cookies entrantes para encontrar el estado de sesión asociado. Detrás de escenas, ASP.NET manejará la cookie de sesión.

Nuevamente, vale la pena apuntar que la información de firstName y lastName almacenada en el objeto de sesión no estará en la cookie. La cookie solo contiene el identificador de sesión. Los valores asociados con el identificador de sesión están seguros en el servidor. Por defecto, los datos de la sesión se almacenan en una estructura de datos en memoria y se mantienen vivos por 20 minutos. Cuando una cookie de sesión llega en una solicitud, ASP.NET asociará los datos de sesión correcta con el objeto Session después de encontrar los datos del usuario utilizando el ID almacenado en la cookie. Si no existe una cookie de entrada con un ID de sesión, ASP.NET creará una con la cabecera Set-Cookie.

Un problema de seguridad sobre los identificadores de sesión es como abren la posibilidad  para que alguien secuestre la sesión de otro usuario. Por ejemplo, si utilizamos una herramienta como Fiddler para registrar el tráfico HTTP, podría ver una cabecera Set-Cookie viniendo del servidor un con SessionID=12 dentro. Yo podría adivinar que algún otro usuario ya tiene un SessionID de 11, y crear una solicitud HTTP con ese ID solo para ver si puedo robar o ver el HTML creado para otro usuario. Para combatir éste problema, la mayoría de aplicaciones web utilizarán números grandes como identificadores (ASP.NET utiliza 120 bits de aleatoriedad). Una identificador de sesión de ASP.NET se vería como lo siguiente, lo cual hace más difícil adivinar como luciría el ID de sesión de alguien más.


Cookies HttpOnly

Otro problema de seguridad sobre las cookies es que tan vulnerables son a los ataques de cross site scripting (XSS). En un ataque XSS, un usuario malicioso inyecta código Javascript maligno en el sitio web de alguien más. Si el otro sitio web envía el script malicioso a sus usuarios, el script malicioso puede modificar, o inspeccionar o robar la información de una cookie (lo cual puede llevar al robo de la sesión, o algo peor).

Para enfrentar esta vulnerabilidad, Microsoft introdujo la bandera HttpOnly (vista en el último ejemplo de Set-Cookie). La bandera HttpOnly le indica al agente de usuario que no permita que código de script acceda a la cookie. La cookie existe solo para HTTP, para viajar en las cabeceras de cada mensaje de solicitud HTTP. Los exploradores que implementan HttpOnly no permitirán a Javascript leer o escribir en la cookie del cliente.


Tipos de Cookies

Las cookies que hemos visto hasta ahora son cookies de sesión. Las cookies de sesión existen para que una única sesión de usuario y son destruidas cuando el usuario cierra el explorador. Las cookies persistentes pueden vivir fuera de una única sesión del explorador y un agente de usuario almacenará las cookies en el disco. Puedes apagar una computadora y volver una semana más tarde a tu sitio favorito, y una cookie persistente aún estará allí para la primera solicitud.

La única diferencia entre las dos solicitudes que una cookie persistente necesita un valor de Expires.

Una cookie de sesión puede explícitamente agregar un atributo Discard a una cookie, pero sin el valor Expires, el agente de usuario deberá descartar la cookie en cualquier caso.


Rutas de Cookies y Dominios

Hasta ahora hemos dicho que una vez una cookie es establecida por un sitio web, la cookie viajará al sitio web con cada solicitud subsecuente (asumiendo que la cookie no ha expirado). Sin embargo, no todas las cookies viajan a cada sitio web. Las únicas cookies que un agente de usuario deberá enviar a un sitio son las cookies dadas al agente de usuario por el mismo sitio. No tendría sentido que las cookies de amazon.com estén en una solicitud HTTP para google.com. Este tipo de comportamiento podría solamente abrir problemas de privacidad y seguridad adicionales. Si estableces una cookie en una respuesta a una solicitud a www.server.com, la cookie resultante solo viajará en las solicitudes a www.server.com.

Una aplicación web también puede cambiar el alcance de una cookie para restringirla a un host o dominio específico, e incluso a la ruta de un recurso específico. La aplicación web controla el alcance utilizando los atributos de domain y path.

El atributo domain permite una cookie abarcar los subdominios. En otras palabras, si estableces una cookie al servidor www.server.com, el agente de usuario solo entregará la cookie a www.server.com. El dominio en el ejemplo anterior también permite a la cookie viajar a cualquier URL en el dominio server.com, incluyendo images.server.com, help.server.com y al servidor server.com. No puedes utilizar el atributo dominio para abarcar otros dominios, por lo que establecer el dominio a .microsoft.com en una respuesta al servidor .server.com no es legal y el agente de usuario debería rechazar la cookie.

El atributo path puede restringir una cookie a un path de un recurso específico. En el ejemplo anterior, la cookie solo viajará a un sitio server.com cuando una URL de la solicitud está aputando a /stuff, o una ubicación debajo de /stuff, como /stuff/images. Las configuraciones de ruta ayudan a organizar las cookies cuando múltiples equipos están construyendo aplicaciones web en diferentes rutas.


Desventajas de las Cookies

Las cookies permiten que los sitios web almacenen información en el cliente y la información viaje de vuelta a los sitios en las solicitudes subsecuentes. Los beneficios para el desarrollo web son enormes, porque las cookies nos permiten dar seguimiento a qué solicitudes pertenecen a que jugador. Pero, las cookies tienen algunos problemas los cuales ya hemos cubierto.

Las cookies han sido vulnerables a ataques XSS como mencionamos anteriormente, y también reciben publicidad mala cuando sitios (particularmente sitios de anuncios) utilizan cookies de terceros para dar seguimiento a los usuarios a través de internet. Las cookies de terceros son cookies que se obtienen/establecen de un dominio diferente que el de la barra de direcciones del explorador. Las cookies de terceros tienen esta posibilidad porque muchos sitios web, cuando envian un recurso de la página de vuelta al cliente, incluirá enlaces a los scripts o imágenes de otras URLs. Las solicitudes que van a otras URLs permiten a otros sitios establecer cookies.

Como un ejemplo, la página home en el servidor server.com puede incluir una etiqueta <script> con una fuente establecida a bigadvertising.com. Esto permite que el sitio bigadvertising.com entregue una cookie mientras el usuario está visualizando el contenido desde server.com. La cookie solo puede ir de vuelta a bigadvertising.com, pero si suficientes sitios web utilizan bigadvertising.com, entonces Big Advertising puede empezar a perfilar a usuarios individuales y los sitios que visitan. La mayoría de los exploradores web te permitirán deshabilitar cookies de terceros (pero están habilitadas por defecto).

Dos de las principales desventajas, sin embargo, son como interfieren con la captura y como transmiten datos en cada solicitud. Cualquier respuesta con una cabecera Set-Cookie no debería ser almacenada en caché, al menos no las cabeceras, debido a que esto puedo interferir con la identificación del usuario y crear problemas de seguridad. También, ten en mente que todo lo almacenado en una cookie es visible mientras viaja a través de la red (y en el caso de las cookies persistentes, mientras está sobre el sistema de archivos). Desde que sabemos que existen muchos dispositivos que pueden escuchar e interpretar el tráfico HTTP, una cookie nunca debe almacenar información sensible. Incluso los identificadores de sesión son riesgosos, porque si alguien puede interceptar el ID de usuario de otro, el o ella puede robar los datos de sesión del servidor.

Aún con todas éstas desventajas, las cookies no se van a ir a ningún lado. Algunas veces necesitamos que el estado viaje a través de HTTP, y las cookies ofrecen ésta capacidad, casi de forma transparente. Otra capacidad que algunas veces necesitamos es la habilidad de autenticar al usuario. Discutiremos las características de autenticación más adelante.


Autenticación

El proceso de autenticación fuerza a un usuario a probar su identidad ingresando un nombre de usuario y contraseña, o un correo y un PIN, o algún otro tipo de credenciales.

A nivel de red, la autenticación típicamente sigue un formato reto/respuesta. El cliente solicitará un recurso seguro, y el servidor retará al cliente para la autenticación. El cliente entonces necesita enviar otra solicitud e incluir as credenciales de autenticación para que el servidor las valide. Si las credenciales son correctas, la solicitud será existosa.

La extensibilidad de HTTP permite que HTTP soporte varios protocolos de autenticación. En esta sección, veremos brevemente los cinco principales: basic, digest, Windows, forms y OpenID. De estos cinco, solo dos son "oficiales" en la especificación HTTP- los protocolos de autenticación basic y digest. Veremos estos dos primero.


Autenticación Basic

Con la autenticación basic, el cliente solicitará un recurso primero con un mensaje HTTP normal.

Los servidores web te permiten configurar el acceso a archivos y directorios específicos. Puedes permitir el acceso a los usuarios anónimos, o restringir el acceso para que solo usuarios o grupos específicos puedan acceder al archivo o directorio. Para la anterior solicitud, imaginemos que el servidor está configurado para permitir que solo ciertos usuarios vean el recurso /html5/. En ese caso, el servidor lanzará un reto de autenticación.

El código de estado 401 le indica al cliente que la solicitud no está autorizada. La cabecera WWW-Authenticate le indica al cliente que pida las credenciales de usuario y lo intente de nuevo. El atributo realm le da al agente de usuario una cadena que puede utilizar como una descripción para el área protegida. Lo que sucede después depende del agente de usuario, pero la mayor parte de los exploradores pueden mostrar una interfaz para que el usuario ingrese las credenciales.

Figure 8: Authentication dialog
Dialogo de Autenticación

Con las credenciales en mano, el explorador puede enviar otra solicitud al servidor. Esta solicitud incluirá la cabecera Authorization.

El valor de la cabecera de autorización es el nombre y contraseña del usuario codificados en base64. La autenticación Basic es insegura por defecto, porque cualquiera con un decodificador base64 que puede ver el mensaje puede robar la contraseña del usuario. Por esta razón, la autenticación basic es raramente utilizada sin utilizar HTTP seguro, el cual veremos más adelante.

Le queda al servidor decodificar la cabecera de autorización y verificar el nombre de usuario y contraseña con el sistema operativo, o cualquiera que sea el sistema de manejo de credenciales que esté en el servidor. Si las credenciales coinciden, el servidor puede responder normalmente. Si las credenciales no coinciden, el servidor debería responder con un estado 401 nuevamente.


Autenticación Digest

La autenticación Digest es una mejora sobre la autenticación basic, porque no transmite las contraseñas de los usuarios en codificación base64 (lo cual es esencialmente transmitir la contraseña en texto plano). En su lugar, el cliente debe enviar un digest sobre la contraseña. El cliente calcula el digest utilizando el algoritmo de hash MD5 con un nonce el servidor proporciona durante el desafío de autenticación (un nonce es un número criptográfico utilizado para ayudar a prevenir los ataques de repetición).

El reto de respuesta digest es similar al reto de respuesta para la autenticación basic, pero con valores adicionales que vienen del servidor en la cabecera WWW-Authenticate para el uso en funciones criptográficas.

La autenticación Digest es mejor que la autenticacion basic cuando el HTTP seguro no está disponible, pero aún está lejos de ser perfecto. La autenticación Digest es aún vulnerable a ataques hombre-en-el-medio en el cual alguien está rastreando el tráfico de red.


Autenticación de Windows

La Autenticación Integrada de Windows no es un protocolo de autenticación estándar pero es popular entre productos y servidores Microsoft. Aunque la Autenticación de Windows sea soportada por muchos exploradores modernos (no solo Internet Explorer), no funciona bien en Internet o donde residen servidores Proxy. Lo encontrarás comúnmente en sitios web internos o de intranet dónde un servidor Microsoft Active Directory exista.

La Autenticacion de Windows depende de los protocolos de autenticación subyacentes soportados por Windows, incluyendo NTLM y Kerberos. Los pasos de reto/respuesta de la Autenticación de Windows son muy parecidos a lo que ya hemos visto, pero el servidor especificará NTLM o Negotiate en la cabecera WWW-Authenticate (Negotiate es un protocolo que permite al cliente seleccionar Kerberos o HTML).

La Autenticación de Windows tiene la ventaja de ser segura aún sin utilizar HTTP seguro, y por ser inobtrusiva para los usuarios de Internet Explorer. IE automáticamente autenticará al usuario cuando sea retado por un servidor, y lo hará utilizando las credenciales del usuario con las que el o ella se haya logueado en el sistema operativo Windows.


Autenticación de Formularios

La autenticación de formularios es la solución más popular para autenticar al usuario sobre Internet. La autenticación basada en formularios no es un protocolo de estándar y no utiliza las cabeceras WWW-Authenticate o Authorization. Sin embargo, muchos frameworks de aplicaciones web proporcionan algún soporte nativo para la autenticación basada en formularios.

Con la autenticación basada en formularios, una aplicación responderá a una solicitud para un recurso seguro hecho por un usuario anónimo redireccionando al usuario a la página de inicio de sesión. La redirección es una redirección temporal HTTP 302. Generalmente, la URL que el usuario está solicitando puede estar incluida en el query string de la ubicación de redirección por lo que una vez el usuario ha completado el inicio de sesión, la aplicación puede redirigir al usuario al recurso seguro que el o ella estuvieran intentando encontrar.

La página de inicio de sesión basada el formularios es un formulario HTML con inputs para que el usuario ingrese las credenciales. Cuando el cliente hace click en submit, los valores del formulario harán POST a un destino donde las aplicaciones necesitan tomar las credenciales y validarlas contra un registro en la base de datos o sistema operativo.

Nota que la autenticación basada en formularios trasmitirán las credenciales del usuario en texto plano, así que como la autenticación basic, la autenticación basada en formularios no es segura al menos que utilices HTTP seguro. En respuesta al mensaje POST con las credenciales (asumiendo que las credenciales son correctas), la aplicación típicamente redireccionará al usuario de vuelta al recurso seguro y también establecerá una cookie indicado que el usuario está autenticado.

Para ASP.NET, el ticket de autenticación (el valor de la cookie  .ASPXAUTH ) está encriptado y hasheado para prevenir su manipulación. Sin embargo, sin HTTP seguro la cookie es vulnerable de ser interceptada, por lo que el robo de sesión es todavía un problema potencial. Aún así, los formularios de autenticación continúan siendo populares porque permite a las aplicaciones un completo control sobre la experiencia de inicio de sesión y validación de las credenciales.


OpenID

Mientras que la autenticación basada en formularios da a la aplicación un control total sobre la autenticación, muchas aplicaciones no requieren éste tipo de nivel de control. Específicamente, las aplicaciones que no quieren gestionar y verificar los nombres de usuario y contraseñas (y los usuarios que no quieren tener diferentes usuarios y contraseñas para cada sitio web). OpenID es un estándar abierto para la autenticación descentralizada. Con OpenID, un usuario se registra con un proveedor de identidad OpenID, y el proveedor de identidad es el único sitio que necesita almacenar y validar las credenciales de usuario. Hay muchos proveedores de OpenID por ahí, incluyendo a Google, Yahoo y Versign.

Cuando una aplicación necesita autenticar a un usuario, funciona con el usuario y el proveedor de identidad del usuario. El usuario finalmente tiene que verificar su nombre de usuario y contraseña con el proveedor de identidad, pero la aplicación sabrá si la autenticación es exitosa gracias a la existencia de tokens y secrets criptograficos. Google tiene un overview del proceso en su página web de "Login Federado para las Cuentas de Usuario de Google" (https://developers.google.com/accounts/docs/OpenID).

Mientras que OpenID ofrece muchos beneficios potenciales comparado a otras formas de autenticación, ha afrontado una carencia de adopción debido a la complejidad en su implementación, depuración y en el mantenimiento de la danza de inicio de sesión de OpenID. Tenemos que esperar a que los toolkits y frameworks continúen evolucionando para hacer la solución de OpenID más sencilla.


HTTP Seguro

Anteriormente mencionamos como los mensajes HTTP textuales auto-descriptivos son una de las fortalezas de la web. Cualquiera puede leer un mensaje y entender que hay dentro. Pero, hay muchos mensajes para enviar sobre la web que no queremos que nadie más vea. Hemos discutido algunos de esos escenarios en éste libro. No queremos que nadie más en la red vea nuestras contraseñas, por ejemplo, pero tampoco queremos que vean nuestros números de tarjeta de crédito or números de cuentas bancarias. El HTTP seguro resuelve éste problema encriptando los mensajes antes de empezar a viajar a través de la red.

El HTTP seguro también es conocido como HTTPS (porque utiliza el esquema https en la URL en lugar del esquema http regular). El puerto por defecto para HTTP es 80, y el puerto por defecto para HTTPS es 443. El explorador se conectará al puerto apropiado dependiendo del esquema (a menos que tenga que utilizar un puerto explícito que esté presente en la URL). HTTPS funciona utilizando una capa de seguridad adicional en la pila de protocolos de red. La capa de seguridad existen entre las capas de HTTP y TCP, y hace uso de el protocolo de Capa de Transporte de Seguridad (TLS) or su predecesor conocido como Capa de Sockets Seguros (SSL).

Figure 9: Secure HTTP protocol layers
Capas de seguridad del protocolo HTTP

HTTPS require que un servidor tenga un certificado criptográfico. El certificado es enviado al cliente durante la configuración de la comunicación HTTPS. El certificado incluye el nombre de host del servidor, el agente de usuario puede utilizar el certificado para validar que está verdaderamente comunicándose con el servidor con el que  piensa que está comunicándose. La validación es hecha posible utilizando criptografía de claves públicas y la existencia de autoridades certificadores como Verisign, que firmarán y garantizarán la integridad del certificado. Los administradores tienen que comprar e instalar los certificados de las autoridades certificadoras.

Hay muchos detalles criptográficos que podríamos cubrir, pero desde la perspectiva del desarrollador, los cosas más importantes a saber sobre HTTPS son:

  • Todo el tráfico sobre HTTPS es encriptado en la solicitud y la respuesta, incluyendo los headers HTTP y el cuerpo del mensaje y también todo después del nombre del host en la URL. Esto quiere decir que la información del path y del query string están encriptados, así como las cookies. HTTPS previene el robo de sesión porque ningún fisgón puede inspeccionar un mensaje y robar la cookie.
  • El servidor es autenticado para el cliente gracias al certificado del servidor. Si estás comunicándote con mybigbank.com a través de HTTPS, puedes estar seguro que tus mensajes de verdad irán a mybigbank.com y no a alguien más quien detrás de un proxy en la red puede interceptar las solicitudes e interceptar el tráfico de respuesta desde mybigbank.com.
  • HTTPS no autentica al cliente. Las aplicaciones todavía necesitan implementar formularios de autenticación o alguno de los otros protocolos de autenticación mencionados anteriormente si necesitan conocer la identidad del usuario. HTTPS hace a la autenticación basada en formularios y a la autenticación basic más seguro debido a que toda la información está encriptada. Existe la posibilidad de usar certificados del cliente con HTTPS, y los certificados del cliente podrían autenticar al cliente en la forma más segura posible. Sin embargo, los certificados del cliente generalmente no son utilizados en la internet abierta debido a que no muchos usuarios comprarán e instalarán un certificado personal. Las corporaciones podrían requerir certificados del cliente para que los empleados accedan a los servidores corporativos, pero en éste caso la corporación puede actuar como una autoridad de certificación y asignar certificados a los empleados que ellos mismos creen y manejen.

HTTPS tiene algunos problemas y la mayor parte de ellos están relacionados al rendimiento. HTTPS es computacionalmente caro, y grandes sitios frecuentemente utilizan hardware especializado (aceleradores SSL) para extraer la carga del cálculo criptográfico de los servidores web. El tráfico HTTPS también es imposible de cachear en una caché pública, pero los agentes de usuario podrían mantener las respuestas HTTPS en su caché privada. Finalmente, las conexiones HTTPS son costosas de configurar y requieren un handshake adicional entre el cliente y el servidor para intercambiar las claves criptográficas y asegurarse que todos están comunicándose con el protocolo de seguridad apropiado. Las conexiones persistentes pueden ayudar a amortizar éste costo.

Al final, si necesitas comunicaciones seguras probablemente pagarás las penalidades de rendimiento.


¿En dónde estamos?

In éste articulo hemos visto las cookies, autenticación y HTTP seguro. Si has completo la sesión entera, espero que hayas encontrado alguna información valiosa que te ayudará mientras escribes, mantienes y depuras aplicaciones web.

¡Sé el primero en conocer las nuevas traducciones–sigue @tutsplus_es en Twitter!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.