Conociendo HTTP

HTTP es un proceso acordado para interactuar y comunicarse con una aplicación web. Es un protocolo completamente en texto plano, por lo cual no se asume la existencia de seguridad o privacidad cuando se utiliza HTTP. Actualmente HTTP es un protocolo sin estado, de tal manera cada petición del cliente y respuesta de la aplicación web, es un evento nuevo e independiente, sin conocimiento previo de ninguna petición. Sin embargo es crítico la aplicación mantenga un seguimiento de las peticiones del cliente, de tal manera sea factible completar transacciones de varios pasos, como una compra en línea , donde se añaden artículos a un carro de compras, seleccionar el método de pago, e ingresar información del pago.

HTTP sin la utilización de las Cookies requeriría volver a iniciar sesión durante cada uno de los pasos. Esto simplemente no es realista, por lo cual se creó el concepto de sesión, donde la aplicación web realiza un seguimiento de las peticiones después de iniciar sesión. Aunque las sesiones son una excelente manera de incrementar la facilidad de uso de una aplicación web, también proporcionan otro vector de ataque para las aplicaciones web. HTTP no se creó originalmente para manejar este tipo de transacciones web, requiriendo un alto grado de seguridad y privacidad. Se pueden inspeccionar todos los profundos detalles de como opera HTTP, con herramientas como Wireshark o un Proxy HTTP local.

La utilización de HTTP seguro (HTTPS) hace poco por detener los ataques. HTTPS se logra cuando HTTP se superpone sobre el protocolo SSL (Secure Socket Layer) /TLS (Transport Layer Security), lo cual añade SSL/TLS a las peticiones y respuestas HTTP normales. Es más adecuado para garantizar los ataques de hombre en el medio, o ataques de interceptación no sean exitosos; asegura una “llamada privada” entre el navegador web y la aplicación web, opuesto a tener una conversación en una sala llena de gente, donde cualquiera puede escuchar los secretos. Sin embargo, desde la perspectiva del “Hacking”, HTTPS sólo significa se realizará la comunicación con la aplicación web a través de un canal de comunicación cifrado, para convertirlo en una conversación privada. El cifrado bidireccional de HTTPS no evitará los ataques sean procesador por la aplicación web.

Ciclos HTTP

Una de las operaciones fundamentalmente más importantes en cada aplicación web es el ciclo de peticiones hechas por los navegadores de los clientes, y las respuestas devueltas por el servidor web. Es una premisa muy sencilla, la cual ocurre muchas veces al día. Un navegador web envía una petición con parámetros (variables) manejando las entradas del usuario, y el servidor web envía una respuesta, la cual es dirigida por la petición enviada. La aplicación web puede actuar basándose en los valores de los parámetros, por lo cual son los primeros objetivos para los atacantes, insertando valores maliciosos en los parámetros para explotar la aplicación web y el servidor web.

Cabeceras HTTP Relevantes

Cada ciclo HTTP también incluye cabeceras en las peticiones del cliente y las respuestas del servidor, los cuales transmiten detalles sobre la petición y respuesta. Existen muchas de estas cabeceras, pero algunas son las más relevantes para el tema del Hacking.

Las cabeceras más relevantes son aquellas ajustadas por el servidor y enviadas al navegador del cliente como parte del ciclo de respuesta.

  • Set-Cookie: Esta cabecera comúnmente proporciona el identificador de sesión (Cookie) hacia el cliente, para asegurar se mantiene la sesión actual del usuario. Si un atacante malicioso puede robar una sesión de usuario (aprovechándose de diversos ataques), estos puede suplantar la identidad del usuario explotado dentro de la aplicación web.
  • Content-Lenght: Esta valor de la cabecera es la longitud del cuerpo de la respuesta en bytes. Esta cabecera es útil para los atacantes maliciosos porque se puede mirar por la variación en el número de bytes de la respuesta, para ayudar a descifrar la respuesta de la aplicación hacia la entrada. Esto es especialmente aplicable cuando se realizan ataques por fuerza bruta (adivinar repetidamente).
  • Location: Esta cabecera es utilizada cuando una aplicación redirecciona a un usuario hacia una nueva página. Esto es útil para un atacante malicioso porque puede ser utilizada para ayudar a identificar páginas las cuales únicamente son permitidas después de una autenticación exitosa hacia la aplicación web.

Las cabeceras relevantes las cuales son enviadas por el navegador del cliente como parte de una petición web son:

  • Cookie: Esta cabecera envía la Cookie (o varias Cookies) devuelta hacia el servidor para mantener la sesión del usuario. Este valor de la cabecera Cookie siempre debe coincidir con el valor de la cabecera “Set-Cookie” la cual fue entregada por el servidor. Esta cabecera es útil para un atacante maliciosos porque puede proporcionar una sesión válida con la aplicación web, la cual puede ser utilizada en ataques contra otros usuarios de la aplicación. Otras Cookies no soy tan atractivas, como la Cookie la cual define el lenguaje deseado.
  • Referer: Esta cabecera lista la página web en la cual previamente estuvo el usuario cuando la siguiente petición fue realizada. Se puede pensar en esta cabecera como un almacén para “la última página visitada”. Esto es de ayuda para un atacante malicioso porque este valor puede ser fácilmente cambiado. Por lo tanto, si la aplicación web confía en esta cabecera para un tema de seguridad, puede ser fácilmente evadido con un valor falsificado.

Códigos de Estado HTTP Relevantes

Como las respuestas del servidor web son recibidas por el navegador web, se incluyen códigos de estado para señalar cual es el tipo de respuesta. Existen más de 50 códigos de respuestas HTTP numéricos agrupados en cinco familias, los cuales proporcionan tipos similares de códigos de estado. Conocer la representación de cada tipo de familia de respuesta, permite obtener una comprensión de como la entrada fue procesada por la aplicación web.

  • 100: Estas respuestas son puramente informativas desde el servidor web, y usualmente significan están próximas respuestas adicionales desde el servidor web. Estas son raramente vistas en las respuesta de los servidores web modernos, y son usualmente son seguidas después con otro tipo de respuesta.
  • 200: Estas respuestas señalan la petición del cliente fue exitosamente aceptada y procesada por el servidor web, además la respuesta ha sido enviada devuelta al navegador del cliente. El código de estado más común es el “200 OK”.
  • 300: Estas respuestas son utilizadas para señalar redirección cuando respuestas adicionales deben ser enviadas hacia el cliente. La implementación más común de esto es para redireccionar al navegador de un usuario, hacia una página segura después de autenticarse exitosamente en la aplicación web. Esto podría ser un “302 Redirect” para enviar otra respuesta la cual podría ser un “200 OK”.
  • 400: Estas respuestas son utilizadas para señalar un error en la petición desde el cliente. Esto significa el usuario a enviado una petición la cual no puede ser procesada por la aplicación web. Algunos de estos códigos de estado son “401 unauthorized”, “403 Forbidden”, o “404 Not Found”.
  • 500: Estas respuestas son utilizadas para señalar un error en el lado del servidor. El código de estado más común utilizados en esta familia son ”500 Internal Server Error” y “503 Service Unavailable”.

Fuentes:

https://www.w3.org/Protocols/rfc2616/rfc2616.html
https://tools.ietf.org/html/rfc5246
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Sobre el Autor


Alonso Eduardo Caballero Quezada - ReYDeS
Instructor y Consultor en Hacking Ético, Forense Digital & GNU/Linux
Correo Electrónico: ReYDeS@gmail.com
Twitter: @Alonso_ReYDeS
LinkedIn: pe.linkedin.com/in/alonsocaballeroquezada
Facebook: https://www.facebook.com/alonsoreydes
Resumen de mi CV: http://www.reydes.com/d/?q=node/1