El protocolo HTTPS

En este capítulo aprenderás qué es El protocolo HTTPS, por qué existe y cómo protege las comunicaciones web. Verás de forma práctica cómo SSL/TLS cifra y autentica el tráfico HTTP, en qué situaciones es imprescindible (login, pagos, banca, etc.), y cómo se relaciona con la gestión de sesiones y cookies en aplicaciones web.

Esto es útil y necesario en tu carrera como pentester porque te permite distinguir entre problemas que se solucionan con cifrado de transporte y aquellos que son vulnerabilidades de la aplicación misma. Saber cómo funciona HTTPS y cómo se gestionan las sesiones te ayudará a: detectar configuraciones TLS débiles, comprobar problemas de manejo de sesiones, entender vectores de ataque como fijación o robo de sesión, y diseñar pruebas más efectivas y seguras.

Este conocimiento es fundamental para tu carrera como hacker ético, ya que te permitirá:

Entender cómo se establece una conexión segura y dónde pueden existir vulnerabilidades.
Identificar ataques posibles en conexiones HTTP inseguras.
Reconocer la importancia del cifrado y la autenticación para proteger la información de los usuarios.
Realizar auditorías web más precisas, diferenciando entre errores de configuración, certificados caducados o implementaciones inseguras de TLS.

Como hacker, no solo debes saber cómo romper sistemas, sino también cómo se defienden. Y HTTPS es una de las primeras líneas de defensa en la seguridad web.

HTTPS

Ahora que comprende cómo funciona HTTP, exploremos cómo se asegura/protege. De forma predeterminada, las solicitudes HTTP se envían en texto sin cifrar y pueden ser interceptadas o manipuladas fácilmente por un atacante en el camino a su destino.

Además, HTTP no proporciona una autenticación sólida entre las dos partes que se comunican. HTTPS (Protocolo Seguro de Transferencia de Hipertexto) es una versión segura del protocolo HTTP, que se utiliza para transmitir datos entre el navegador web de un usuario y un sitio web o aplicación web.

HTTPS proporciona una capa adicional de seguridad al cifrar los datos transmitidos a través de Internet, haciéndolos más seguros y protegiéndolos del acceso no autorizado y la interceptación.
HTTPS también se conoce comúnmente como HTTP seguro.
HTTPS es la forma preferida de usar y configurar HTTP e implica ejecutar HTTP sobre SSL/TLS.
SSL (Capa de sockets seguros) y TLS (Seguridad de la capa de transporte) son protocolos criptográficos que se utilizan para proporcionar una comunicación segura a través de una red informática, más comúnmente Internet.
Son esenciales para establecer una conexión segura y cifrada entre el navegador web o la aplicación de un usuario y un servidor web

Esta técnica de capas proporciona confidencialidad, protección de la integridad y autenticación al protocolo HTTP.

HTTP VS HTTPS

La imagen muestra de forma clara la diferencia entre los protocolos HTTP y HTTPS, destacando la importancia de la seguridad en las comunicaciones web. En la parte izquierda se presenta HTTP, que funciona sin cifrado (es decir, sin SSL). Bajo este esquema, la información que se transmite entre el navegador del usuario y el servidor web viaja en texto plano, lo que permite que cualquier atacante pueda interceptarla o modificarla. Esto abre la puerta a ataques como la falsificación de mensajes (Message Forgery), el robo de datos (Data Theft) y la escucha no autorizada (Eavesdropping). Por esa razón, se etiqueta como “Not Secure”, y se enfatiza que datos sensibles, como contraseñas o identificadores de usuario, son visibles para cualquiera que intercepte la conexión.

En contraste, el lado derecho muestra HTTPS, que utiliza cifrado SSL (Secure Sockets Layer) o su versión moderna, TLS. Este cifrado garantiza que la información transmitida entre el usuario y el servidor esté protegida, haciendo imposible que sea leída o modificada por terceros. Por ello, las mismas amenazas que afectaban a HTTP son bloqueadas: la falsificación, el robo de datos y la escucha. Aquí, el estado de la conexión se marca como “Secured”, destacando que los datos viajan encriptados.

En resumen, la imagen resalta visualmente que mientras HTTP expone la información al público, HTTPS la protege, garantizando la confidencialidad e integridad de los datos en las comunicaciones web. Es un concepto esencial para comprender la seguridad en entornos de hacking ético y pentesting, ya que la diferencia entre ambos protocolos determina las posibles vulnerabilidades de una aplicación o sitio web.

Comunicación segura entre un navegador y un servidor web mediante HTTPS

Esta imagen ilustra de manera clara cómo funciona una comunicación segura entre un navegador y un servidor web mediante HTTPS. Cuando un usuario accede a un sitio web, el navegador envía una solicitud HTTP al servidor. En este caso, la comunicación viaja a través del protocolo HTTPS, que combina HTTP (el protocolo estándar de transferencia de hipertexto) con SSL/TLS, el componente responsable de cifrar los datos y asegurar la conexión. El proceso comienza cuando el navegador realiza una solicitud, como por ejemplo:

GET / HTTP/1.1

Esta solicitud se transmite mediante HTTPS, estableciendo primero una conexión TCP. Durante esta conexión se produce un handshake TLS, un intercambio criptográfico que permite al cliente y al servidor autenticarse y acordar las claves de cifrado que se usarán en la sesión. Gracias a esto, toda la información que se envíe posteriormente —como contraseñas, datos personales o cookies— viajará cifrada y no podrá ser leída por un atacante que intercepte el tráfico. Una vez establecida la conexión segura, el servidor web procesa la solicitud y responde con un mensaje como:

200 OK

Indica que la solicitud fue exitosa. Todo este intercambio se realiza dentro del túnel cifrado proporcionado por SSL/TLS, garantizando la confidencialidad, integridad y autenticidad de los datos.

En resumen, la imagen representa la estructura esencial de una sesión HTTPS: una capa de transporte segura (TLS) sobre TCP, que protege el tráfico HTTP y asegura que la comunicación entre el navegador y el servidor web no pueda ser interceptada ni manipulada.

Ventajas de HTTPS

Cifrado de datos en tránsito: uno de los principales beneficios de HTTPS es el cifrado de datos durante la transmisión. Cuando los datos se envían a través de una conexión HTTPS, se cifran mediante algoritmos criptográficos sólidos. Esto garantiza que incluso si un atacante intercepta los datos mientras están en tránsito, no podrá descifrarlos ni leer su contenido. Protección contra escuchas clandestinas: HTTPS evita que terceros no autorizados escuchen los datos intercambiados entre el navegador del usuario y el servidor web. Esto es particularmente crucial cuando los usuarios introducen información confidencial, como credenciales de inicio de sesión, números de tarjetas de crédito o datos personales.

La imagen muestra de forma muy simple y visual cómo funciona el proceso de establecimiento de una conexión segura mediante TLS, el protocolo que protege las comunicaciones en HTTPS. A la izquierda aparece el navegador (browser), y a la derecha el servidor, que interactúan en una especie de “conversación”.

El navegador inicia la comunicación diciendo que quiere conectarse al sitio “examplecat.com”. El servidor responde enviando una prueba de identidad, normalmente un certificado digital, que demuestra que realmente es examplecat.com. El navegador verifica esa información y confirma que la historia “tiene sentido” (es decir, que el certificado es válido y confiable).

Una vez que la identidad está verificada, ambos comienzan un proceso de intercambio de claves (key exchange). Este intercambio les permite acordar de manera segura una clave de cifrado compartida, que en el ejemplo se representa como una cadena aleatoria “A$29FXYZ…”. A partir de ese momento, toda la información enviada entre el navegador y el servidor estará cifrada con esa clave, impidiendo que terceros puedan leerla o modificarla.

En el recuadro final se explica que este protocolo de comunicación segura se llama TLS (Transport Layer Security), antes conocido como SSL (Secure Sockets Layer), y que puede utilizarse sobre cualquier conexión TCP. En resumen, la imagen describe de forma sencilla el handshake TLS, el proceso que permite establecer una conexión web segura y cifrada, garantizando autenticidad, confidencialidad e integridad en las comunicaciones.

¿Cuándo es necesario HTTPS?

Cuando navegamos, normalmente enviamos y recibimos información mediante el protocolo HTTP, lo que puede llevar a cualquier persona a espiar la conversación entre nuestro equipo y el servidor web. Muchas veces necesitamos intercambiar información sensible que necesita estar protegida y evitar el acceso no autorizado.

La imagen compara de manera visual y sencilla la diferencia entre una conexión HTTP sin cifrado y una conexión HTTPS protegida con SSL. En la parte izquierda se representa el escenario de HTTP, donde no existe ninguna capa de seguridad entre el usuario (cliente) y el servidor. En este caso, los datos viajan en texto plano, lo que los deja expuestos a ataques como la falsificación de mensajes (Message Forgery), el robo de información (Data Theft) y la escucha o espionaje de datos (Eavesdropping). Las flechas muestran cómo estos ataques pueden interceptar fácilmente la comunicación, ya que no hay ninguna protección que los detenga.

En la parte derecha se muestra HTTPS, donde se utiliza una conexión cifrada mediante SSL (o su sucesor TLS). Aquí, un gran paraguas verde con la palabra SSL simboliza la capa de seguridad que protege la comunicación entre el visitante y el servidor. Gracias a esta protección, los mismos ataques que eran posibles en HTTP quedan bloqueados o desviados, ya que la información que viaja por la red está cifrada y autenticada.

La idea principal que transmite la imagen es que implementar un certificado SSL, incluso uno económico, fortalece significativamente la seguridad de un sitio web. De esta forma, los datos del usuario se mantienen privados y se evita que atacantes intercepten o manipulen la comunicación entre el navegador y el servidor.

Protocolo HTTPS utilizado en los siguientes escenarios:

Sitios web bancarios
Pasarela de pago
Sitios web de compras
Todas las páginas de inicio de sesión
Aplicaciones de correo electrónico

La imagen ilustra de forma muy simple el primer paso en el establecimiento de una conexión segura mediante HTTPS o TLS. A la izquierda se encuentra el navegador (browser), que solicita acceder al sitio examplecat.com, y a la derecha el servidor, que responde proporcionando una prueba de identidad. Esa “prueba” es lo que se conoce como un certificado digital.

El certificado actúa como una credencial que confirma que el servidor realmente pertenece al dominio que dice representar. Este documento es emitido por una autoridad certificadora (CA), una entidad de confianza que verifica previamente la legitimidad del sitio.

En términos prácticos, cuando el navegador recibe el certificado, lo valida comprobando que esté firmado por una CA reconocida y que no haya sido alterado o caducado. Si todo es correcto, el navegador puede confiar en que está comunicándose con el servidor legítimo y no con un impostor.

Este proceso es fundamental en la seguridad web, ya que evita ataques de suplantación (como los “man-in-the-middle”) y permite que la conexión continúe de forma cifrada. En resumen, el dibujo representa el momento en que el servidor demuestra su identidad, un paso esencial para establecer una comunicación segura entre el usuario y el sitio web.

Funcionamiento básico de HTTPS

Se requieren claves públicas y certificados firmados para el servidor en el protocolo HTTPS.
Solicitudes de clientes para la página https://
Cuando se utiliza una conexión https, el servidor responde a la conexión inicial ofreciendo una lista de métodos de cifrado que admite el servidor web.
En respuesta, el cliente selecciona un método de conexión y el cliente y el servidor intercambian certificados para autenticar sus identidades.
Una vez hecho esto, tanto el servidor web como el cliente intercambian la información cifrada después de asegurarse de que ambos utilizan la misma clave y se cierra la conexión.
Para alojar conexiones https, un servidor debe tener un certificado de clave pública, que incorpora información de clave con una verificación de la identidad del propietario de la clave.
Casi todos los certificados son verificados por un tercero para que los clientes tengan la seguridad de que la clave siempre está segura.

La imagen explica paso a paso cómo se establece una conexión segura mediante HTTPS y cómo ocurre el intercambio de claves dentro del protocolo TLS/SSL. El proceso se muestra con flechas entre el navegador (cliente) y el servidor, destacando las fases más importantes del cifrado y la verificación.

Primero, el navegador solicita una página segura utilizando https://. En respuesta, el servidor web envía su clave pública junto con su certificado digital, el cual sirve para demostrar su identidad. Luego, el navegador valida ese certificado, comprobando que no esté caducado ni revocado y que haya sido emitido por una autoridad de certificación confiable.

Una vez verificada la autenticidad, el navegador genera una clave simétrica (una clave secreta que usará para cifrar los datos) y la envía al servidor cifrada con la clave pública que recibió anteriormente. Solo el servidor puede descifrarla, ya que posee la clave privada correspondiente. De esta manera, ambos extremos comparten una clave simétrica segura sin que nadie más pueda conocerla.

Después de este intercambio, la comunicación se vuelve completamente cifrada. El servidor utiliza la clave simétrica para enviar la página encriptada, y el navegador la descifra para mostrarla al usuario. Este mecanismo combina criptografía asimétrica y simétrica: la primera se usa para el intercambio seguro de claves, y la segunda para proteger el flujo de datos. En resumen, la imagen representa el proceso que permite que HTTPS garantice confidencialidad, autenticidad e integridad en las comunicaciones entre el usuario y el servidor.

Consideraciones de seguridad de HTTPS

HTTPS no protege contra fallos en las aplicaciones web. Varios ataques a aplicaciones web seguirán funcionando independientemente del uso de SSL/TLS. (Ataques como XSS y SQLi seguirán funcionando). La capa de cifrado añadida solo protege los datos intercambiados entre el cliente y el servidor y detiene los ataques contra la propia aplicación web.

La imagen ilustra de forma clara cómo los datos viajan a través de Internet cuando un usuario se conecta a un sitio web sin protección, mostrando todos los puntos donde la información puede ser interceptada o espiada.

En la parte izquierda se observa a un usuario conectado a una red Wi-Fi, enviando datos hacia un sitio web (site.com). Esos datos incluyen información sensible como usuario, contraseña, ubicación y otros datos personales. Sin embargo, justo al lado aparece un hacker que intercepta la conexión inalámbrica, representado con una línea azul discontinua que simboliza la escucha o eavesdropping. Esto refleja lo fácil que puede ser robar información en redes públicas o sin cifrar.

La conexión continúa pasando por el ISP (proveedor de servicios de Internet), quien también puede acceder a los datos si la conexión no está cifrada. Más adelante, los mismos datos son visibles para múltiples entidades, como la NSA, administradores del sistema (sysadmin), abogados o incluso la policía, todos representados recibiendo la misma información del sitio. Cada uno de ellos tiene una burbuja de texto que indica que poseen los datos del usuario, evidenciando cómo la información puede circular o ser compartida sin control.

En la parte inferior, la leyenda aclara el significado de las líneas: el color rojo indica la conexión a Internet, el azul representa la interceptación o espionaje, y la línea punteada negra el compartir de datos entre entidades.

En conjunto, la imagen muestra la falta de privacidad que existe cuando los datos no viajan cifrados, especialmente en conexiones HTTP o redes Wi-Fi abiertas. Sirve para entender por qué el uso de HTTPS y cifrado TLS es esencial: protege la información del usuario frente a ataques de interceptación, espionaje y vigilancia, garantizando que solo el sitio web de destino pueda leer los datos transmitidos.

Sesiones web

Una sesión web es una secuencia de transacciones de solicitud y respuesta HTTP entre un cliente web y un servidor. Estas transacciones incluyen tareas de pre autenticación, el proceso de autenticación, la administración de sesiones, el control de acceso y la finalización de la sesión. Numerosas aplicaciones web realizan un seguimiento de la información sobre cada usuario durante la duración de una transacción web. Varias aplicaciones web tienen la capacidad de establecer variables como derechos de acceso y configuraciones de localización. Estas variables se aplican a todas y cada una de las interacciones que un usuario tiene con la aplicación web durante la duración de la sesión.

Las aplicaciones web pueden crear sesiones para realizar un seguimiento de los usuarios anónimos después de la primera solicitud del usuario. Por ejemplo, una aplicación puede recordar la preferencia de idioma del usuario cada vez que visita el sitio o la interfaz de la aplicación. Además, una aplicación web utiliza una sesión después de que el usuario se haya autenticado. Esto permite que la aplicación identifique al usuario en cualquier solicitud posterior y pueda aplicar controles de acceso de seguridad y aumentar la usabilidad de la aplicación. En resumen, las aplicaciones web pueden proporcionar capacidades de sesión tanto antes como después de la autenticación.

Una vez establecida una sesión autenticada, el ID de sesión (o token) es temporalmente equivalente al método de autenticación más fuerte utilizado por la aplicación, como nombres de usuario y contraseñas, contraseñas de un solo uso y certificados digitales basados en el cliente. Un buen recurso que proporciona mucha información sobre la autenticación de aplicaciones es la Hoja de referencia de autenticación de OWASP, disponible en https://www.owasp.org/index.php/Authentication_Cheat_Sheet .

El estado autenticado

Para mantener el estado autenticado y realizar un seguimiento del progreso del usuario, las aplicaciones proporcionan a los usuarios identificadores de sesión o tokens. Se asigna un token en el momento de la creación de la sesión, que el usuario y la aplicación web comparten e intercambian durante la sesión. El identificador de sesión es un par de nombre/valor. Los nombres de ID de sesión que utilizan los marcos de desarrollo de aplicaciones web más comunes se pueden identificar fácilmente. Por ejemplo, puede identificar fácilmente PHPSESSID (PHP), JSESSIONID (J2EE), CFID y CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP.NET) y muchos otros. Además, el nombre de ID de sesión puede indicar qué marco y lenguajes de programación utiliza la aplicación web.

Se recomienda cambiar el nombre de ID de sesión predeterminado del marco de desarrollo web a un nombre genérico, como id. El ID de sesión debe ser lo suficientemente largo para evitar ataques de fuerza bruta. A veces, los desarrolladores lo configuran con solo unos pocos bits, aunque debe tener al menos 128 bits (16 bytes). Es muy importante que el ID de sesión sea único e impredecible. Debe utilizar un buen generador de bits aleatorios determinista (DRBG) para crear un valor de ID de sesión que proporcione al menos 256 bits de entropía.

Las cookies

Existen múltiples mecanismos disponibles en HTTP para mantener el estado de la sesión dentro de las aplicaciones web, incluidas las cookies (en el encabezado HTTP estándar), los parámetros de URL y la reescritura definidos en RFC 3986 y los argumentos de URL en las solicitudes GET . Además, los desarrolladores utilizan argumentos de cuerpo en las solicitudes POST , como campos de formulario ocultos (formularios HTML) o encabezados HTTP propietarios. Sin embargo, uno de los mecanismos de intercambio de ID de sesión más utilizados son las cookies, que ofrecen capacidades avanzadas que no están disponibles en otros métodos. Incluir el ID de sesión en la URL puede dar lugar a la manipulación del ID o a ataques de fijación de sesión. Por lo tanto, es importante mantener el ID de sesión fuera de la URL.

Los marcos de desarrollo web como ASP.NET, PHP y Ruby on Rails ofrecen sus propias funciones de administración de sesiones e implementaciones asociadas. Se recomienda utilizar estos marcos integrados en lugar de crear uno propio desde cero, ya que han sido probados por muchas personas. Cuando realice pruebas de penetración, es probable que encuentre personas que intenten crear sus propios marcos. Además, JSON Web Token (JWT) se puede utilizar para la autenticación en aplicaciones modernas.

Cookies no persistentes

Puede parecer bastante obvio, pero hay que recordar que hay que cifrar toda la sesión web, no solo para el proceso de autenticación en el que se intercambian las credenciales de usuario, sino también para garantizar que el ID de sesión se intercambie únicamente a través de un canal cifrado. El uso de un canal de comunicación cifrado también protege la sesión contra algunos ataques de fijación de sesión , en los que el atacante puede interceptar y manipular el tráfico web para inyectar (o corregir) el ID de sesión en el navegador web de la víctima.

Los mecanismos de gestión de sesiones basados en cookies pueden hacer uso de dos tipos de cookies: cookies no persistentes (o de sesión) y cookies persistentes. Si una cookie tiene un atributo Max-Age o Expires , se considera una cookie persistente y el navegador web la almacena en un disco hasta el momento de expiración. Las aplicaciones y los clientes web comunes priorizan el atributo Max-Age sobre el atributo Expires. Las aplicaciones modernas suelen realizar un seguimiento de los usuarios después de la autenticación mediante el uso de cookies no persistentes. Esto obliga a que la información de la sesión se elimine del cliente si se cierra la instancia actual del navegador web. Por eso es importante utilizar cookies no persistentes: para que el ID de la sesión no permanezca en la memoria caché del cliente web durante largos períodos de tiempo.

Los identificadores de sesión

Los identificadores de sesión deben ser validados y verificados cuidadosamente por una aplicación. Según el mecanismo de administración de sesiones que se utilice, el identificador de sesión se recibirá en un parámetro GET o POST , en la URL o en un encabezado HTTP mediante cookies. Si las aplicaciones web no validan ni filtran los valores de ID de sesión no válidos, pueden usarse potencialmente para explotar otras vulnerabilidades web, como la inyección SQL si los ID de sesión se almacenan en una base de datos relacional o secuencias de comandos entre sitios (XSS) persistentes si los ID de sesión se almacenan y se reflejan posteriormente en la aplicación web.

No se preocupes si no comprendes todo ahora todo esto tendrá más sentido en el próximo capítulo en donde profundicemos el protocolo HTTP y más adelante aprenderá sobre inyección SQL y XSS.

Resumen del capítulo

HTTP transmite información en texto plano, lo que deja los datos expuestos a ataques de interceptación (eavesdropping), robo (data theft) o manipulación (message forgery).

Para solucionar esto, surge HTTPS (HTTP Secure), que combina HTTP con los protocolos de cifrado SSL/TLS. Esta unión cifra la comunicación, autentica al servidor (y en algunos casos al cliente) y protege los datos en tránsito.

Qué es HTTPS: HTTPS = HTTP sobre SSL/TLS. Proporciona confidencialidad, integridad y autenticación entre navegador y servidor; evita que el tráfico viaje en texto plano y sea leído o modificado por terceros.

SSL vs TLS: SSL es la versión antigua; TLS es su sucesor moderno. Ambos son protocolos criptográficos que permiten un canal cifrado sobre TCP.

El proceso de conexión segura (handshake TLS) incluye:

Solicitud inicial: el navegador pide acceder a un sitio usando https://.
Autenticación: el servidor responde con su certificado digital para demostrar su identidad.
Verificación: el navegador valida el certificado.
Intercambio de claves: ambas partes acuerdan una clave compartida para cifrar los datos.
Comunicación segura: a partir de este punto, toda la información viaja cifrada y protegida.

Ventajas de HTTPS:

Cifrado de datos en tránsito.
Protección contra espionaje y manipulación.
Autenticación del servidor mediante certificados.
Confianza del usuario y cumplimiento de estándares de seguridad.

Limitaciones

HTTPS no protege contra fallos de la aplicación, como XSS o SQLi; solo asegura la comunicación. Por eso, es una parte del todo, no la solución completa.

En la práctica, HTTPS es obligatorio en:

Banca en línea.
Pasarelas de pago.
Sitios de compras.
Formularios de inicio de sesión.
Aplicaciones que manejan información personal o confidencial.

Cuándo es imprescindible: Banca, pasarelas de pago, comercio electrónico, todas las páginas de inicio de sesión, servicios de correo y en general cualquier intercambio de datos sensibles.

Certificados y Autoridades de Certificación (CA): El certificado, firmado por una CA de confianza, permite al navegador confiar en la identidad del servidor. La validación evita ataques de suplantación (MitM).

Limitaciones: HTTPS no arregla todo: HTTPS protege el canal, no corrige fallos de la aplicación. Vulnerabilidades como XSS, SQLi o errores de lógica siguen siendo posibles aunque el transporte esté cifrado.

Sesiones web y estado autenticado

Las aplicaciones mantienen estado con identificadores de sesión (IDs o tokens).
Un ID de sesión es temporalmente equivalente a las credenciales utilizadas; por eso debe protegerse con cifrado en tránsito y buenas prácticas.
Los nombres de cookie por defecto (PHPSESSID, JSESSIONID, ASP.NET_SessionId, etc.) pueden delatar el framework; se recomienda renombrarlos y usar nombres genéricos.

Cookies y persistencia:

Cookies de sesión (no persistentes) desaparecen al cerrar el navegador; las persistentes tienen Max-Age/Expires.
Es preferible usar cookies no persistentes para tokens de sesión cuando corresponda, evitando almacenamiento prolongado en el cliente.

Seguridad de los IDs de sesión:

Deben ser largos, únicos e impredecibles. Evitar valores cortos o generadores débiles.
Recomendación práctica: al menos 128 bits de entropía (mejor si se usan 256 bits) y usar un buen DRBG (generador criptográfico) para crearlos.
Validar y filtrar siempre los IDs de sesión para evitar que exploten otras vulnerabilidades (p. ej. inyección SQL o XSS persistente).

Mecanismos alternativos de sesión:

Evitar pasar IDs en la URL (riesgo de fijación y exposición).
Preferir cookies seguras (Secure, HttpOnly, SameSite) y uso de frameworks probados en lugar de soluciones caseras.
JWT y otros tokens son comunes en arquitecturas modernas, pero requieren cuidado (expiraciones, revocación, almacenamiento seguro).

10 PREGUNTAS BASADAS EN EL ARTÍCULO

¿Cuál es la diferencia fundamental entre HTTP y HTTPS?
¿Qué rol cumplen SSL y TLS en la seguridad de las comunicaciones web?
¿Por qué es importante utilizar HTTPS en sitios como pasarelas de pago o páginas de inicio de sesión?
¿Qué es el “handshake TLS” y qué función cumple en una conexión HTTPS?
¿Qué elementos debe verificar el navegador al recibir un certificado digital del servidor?
¿Qué ventajas aporta HTTPS frente a ataques como Eavesdropping o Data Theft?
¿Qué papel cumplen los identificadores de sesión en las aplicaciones web?
¿Por qué es recomendable usar cookies no persistentes para la gestión de sesiones?
¿Cuáles son los riesgos de incluir el ID de sesión en la URL?
¿Por qué no es suficiente usar HTTPS si la aplicación web tiene vulnerabilidades como XSS o SQLi?

10 EJERCICIOS BASADOS EN EL CONTENIDO DEL ARTÍCULO

Completa la frase: HTTPS es la combinación del protocolo HTTP con los protocolos ________ y ________.
Verdadero o Falso: El certificado digital lo emite el servidor directamente sin ninguna validación externa.

Dibuja un esquema simple del proceso de conexión segura HTTPS desde el navegador al servidor (puede ser en papel si es físico).
Clasifica los siguientes elementos como «seguro» o «no seguro»:
a) ID de sesión en cookies no persistentes
b) ID de sesión en URL
c) HTTP sin cifrado en Wi-Fi pública
d) HTTPS con certificado válido
Identifica 3 sitios donde siempre debe usarse HTTPS según el artículo.
Menciona al menos 2 funciones que realiza el handshake TLS.
¿Qué características debe tener un buen ID de sesión para que sea seguro?
Explica por qué es peligroso usar cookies persistentes para almacenar el ID de sesión.
¿Qué es más recomendable para la gestión de sesiones: implementar tu propio sistema o usar el del framework? ¿Por qué?
¿Cómo se evita que un atacante pueda leer los datos transmitidos entre un navegador y el servidor?

RESPUESTAS DETALLADAS A LAS 10 PREGUNTAS

Diferencia entre HTTP y HTTPS:
HTTP transmite datos en texto plano sin cifrar, lo cual permite que un atacante los intercepte o manipule fácilmente. HTTPS, en cambio, cifra los datos usando SSL/TLS, lo que garantiza la confidencialidad, integridad y autenticación de la comunicación.
Rol de SSL/TLS:
SSL (Secure Sockets Layer) y TLS (Transport Layer Security) son protocolos criptográficos que cifran los datos transmitidos entre el navegador y el servidor, impidiendo que terceros accedan o alteren la información durante la transmisión.
Importancia de HTTPS en sitios sensibles:
HTTPS es crucial en sitios de banca, pagos o login porque protege datos confidenciales (como contraseñas o tarjetas de crédito) contra interceptación y manipulación.
Handshake TLS:
Es el proceso inicial de una conexión HTTPS donde el navegador y el servidor se autentican mutuamente, intercambian claves y acuerdan el cifrado que se usará durante la sesión.
Verificación del certificado digital:
El navegador verifica que el certificado esté firmado por una Autoridad de Certificación (CA) confiable, que no esté caducado o revocado, y que corresponda al dominio al que se está accediendo.
Ventajas contra ataques:
HTTPS previene ataques como Eavesdropping (espionaje de datos), Data Theft (robo de información) y Message Forgery (falsificación de mensajes), porque los datos viajan cifrados y no pueden ser manipulados ni leídos fácilmente.
Identificadores de sesión:
Permiten mantener la identidad y el estado de autenticación del usuario durante su interacción con una aplicación web. Son esenciales para aplicar políticas de acceso y recordar configuraciones del usuario.
Cookies no persistentes:
Estas cookies se eliminan al cerrar el navegador, lo que evita que el ID de sesión quede almacenado y expuesto a posibles ataques si alguien accede al equipo más tarde.
Riesgos del ID en URL:
Incluir el ID de sesión en la URL puede facilitar ataques como la fijación o manipulación de sesión, ya que esa URL puede quedar registrada en logs, historial o ser compartida accidentalmente.
Limitaciones de HTTPS:
Aunque HTTPS protege la comunicación, no evita vulnerabilidades de la propia aplicación como XSS (Cross-Site Scripting) o SQLi (inyección SQL), que explotan errores de código y lógica interna.

RESPUESTAS DETALLADAS A LOS 10 EJERCICIOS

Completa la frase:
HTTPS es la combinación del protocolo HTTP con los protocolos SSL y TLS.
Verdadero o Falso:
Falso. El certificado digital lo emite una Autoridad de Certificación (CA), no el servidor por sí solo, y debe pasar por un proceso de verificación.
Esquema simple:
(Si es en papel) → El esquema debe incluir: navegador → solicitud HTTPS → servidor responde con certificado digital → validación del navegador → intercambio de claves → canal cifrado → envío y recepción de datos cifrados.
Clasificación de elementos:
- a) Seguro ✅
- b) No seguro ❌
- c) No seguro ❌
- d) Seguro ✅
3 sitios que deben usar HTTPS:
- Sitios bancarios
- Páginas de inicio de sesión
- Pasarelas de pago
Funciones del handshake TLS:
- Autenticación del servidor (y opcionalmente del cliente)
- Establecer claves de cifrado compartidas
- Selección del método de cifrado (algoritmos)
Características de un buen ID de sesión:
- Largo (mínimo 128 bits, preferiblemente con 256 bits de entropía)
- Único
- Impredecible
- Generado con un generador de números aleatorios seguro (DRBG)
Riesgo de cookies persistentes:
Si un atacante accede al dispositivo o a los archivos del navegador, podría robar el ID de sesión almacenado en una cookie persistente, incluso si la sesión ya terminó.
Gestión de sesiones recomendada:
Es mejor usar las funciones integradas del framework web, ya que han sido ampliamente probadas y auditadas. Crear un sistema propio aumenta el riesgo de cometer errores de seguridad.
Cómo evitar que los datos sean leídos por un atacante:
Usando HTTPS, que cifra la información mediante SSL/TLS, garantizando que los datos solo puedan ser interpretados por el navegador y el servidor legítimos.

Ahora sabes

Has visto los fundamentos de HTTPS/TLS, por qué es esencial cifrar el tráfico web y cómo se relaciona esto con la gestión segura de sesiones. Como hacker ético, usarás este conocimiento para: identificar configuraciones TLS débiles, comprobar la correcta protección de tokens y cookies, y diferenciar vulnerabilidades de transporte de fallos en la lógica de la aplicación (XSS, SQLi, etc.). Dominar estos conceptos te permitirá realizar pruebas más precisas, reportes con recomendaciones técnicas claras y, en última instancia, ayudar a construir aplicaciones más seguras.

Ahora sabes cómo HTTPS protege la comunicación web y por qué es la base de la seguridad en Internet. Aprendiste cómo se establecen las conexiones seguras, cómo funcionan los certificados digitales y cómo el cifrado evita que un atacante intercepte o modifique los datos.

Este conocimiento te será clave en tu carrera como hacker ético, porque te permitirá:

Analizar configuraciones seguras e inseguras en servidores web.
Detectar vulnerabilidades en la implementación de SSL/TLS.
Comprender el flujo completo de una sesión HTTPS y sus puntos débiles potenciales.

Recuerda: un buen hacker no solo rompe barreras, también entiende cómo se construyen. Dominar HTTPS es dominar la base de la seguridad en la web. En el próximos capítulos profundizaremos en HTTP y luego entraremos en inyección SQL y XSS — ahí verás cómo las debilidades de la aplicación siguen siendo explotables incluso con HTTPS activo. ¡A seguir aprendiendo y probando con criterio!

Nos vemos en el próximo capítulo, happy hacking…

El protocolo HTTPS