HTTP/S Protocol Fundamentals
Last updated
Last updated
HTTP (Hypertext Transfer Protocol) es un protocolo de capa de aplicación sin estado que se utiliza para la transmisión de recursos como datos de aplicaciones web y se ejecuta sobre TCP.
Fue diseñado específicamente para la comunicación entre navegadores web y servidores web.
HTTP utiliza la arquitectura típica de cliente-servidor para la comunicación, en la que el navegador es el cliente y el servidor web es el servidor.
Los recursos se identifican de forma única con una URL/URI.
HTTP tiene 2 versiones: HTTP 1.0 y HTTP 1.1.
HTTP 1.1 es la versión más utilizada de HTTP y tiene varias ventajas sobre HTTP 1.0, como la capacidad de reutilizar la misma conexión y puede solicitar múltiples URI/recursos.
Durante la comunicación HTTP, el cliente y el servidor intercambian mensajes, que normalmente se clasifican como solicitudes y respuestas HTTP.
El cliente envía solicitudes al servidor y recibe respuestas.
El Request Line es la primera línea de una solicitud HTTP y contiene los siguientes tres componentes:
Método HTTP (p. ej., GET, POST, PUT, DELETE, etc.): indica el tipo de solicitud que se está realizando.
URL (Uniform Resource Locator): la dirección del recurso al que el cliente desea acceder.
Versión HTTP: la versión del protocolo HTTP que se está utilizando (p. ej., HTTP/I.I).
Los encabezados proporcionan información adicional sobre la solicitud. Los encabezados comunes incluyen:
User-Agent: información sobre el cliente que realiza la solicitud (por ejemplo, tipo de navegador).
Host: el nombre de host del servidor.
Accept: los tipos de medios que el cliente puede manejar en la respuesta (por ejemplo, HTML, JSON).
Authorization: credenciales para autenticación, si es necesario.
Cookie: información almacenada en el lado del cliente y enviada de vuelta al servidor con cada solicitud.
Algunos métodos HTTP (como POST o PUT) incluyen un cuerpo de solicitud donde se envían los datos al servidor, generalmente en formato JSON o de formulario.
Examinemos una solicitud HTTP en detalle. A continuación, se muestran los datos que contiene una solicitud que enviamos cuando navegamos a www.google.com con un navegador web.
Se inicia una solicitud HTTP a www.google.com. Lo que se ve aquí son los encabezados (HTTP Request Headers) para esta solicitud.
Tenga en cuenta que se inicia una conexión a www.google.com en el puerto 80 antes de enviar comandos HTTP al servidor web.
Los métodos de solicitud HTTP (HTTP Verbs) proporcionan una forma estandarizada para que los clientes y servidores se comuniquen e interactúen con los recursos en la Web. La elección del método adecuado depende del tipo de operación que se debe realizar en el recurso.
GET es el método de solicitud predeterminado que se utiliza cuando se realiza una solicitud a una aplicación web; en este caso, estamos intentando conectarnos a www.google.com.
GET
El método GET se utiliza para recuperar datos del servidor. Solicita el recurso especificado en la URL y no modifica el estado del servidor. Es un método seguro e idempotente, lo que significa que realizar la misma solicitud GET varias veces no debería tener efectos secundarios.
POST
El método POST se utiliza para enviar datos para que los procese el servidor. Normalmente incluye datos en el cuerpo de la solicitud y el servidor puede realizar acciones en función de esos datos. Las solicitudes POST pueden provocar cambios en el estado del servidor y no son idempotentes.
PUT
El método PUT se utiliza para actualizar o crear un recurso en el servidor en la URL especificada. Reemplaza todo el recurso con la nueva representación proporcionada en el cuerpo de la solicitud. Si el recurso no existe, PUT puede crearlo.
DELETE
El método DELETE se utiliza para eliminar el recurso especificado por la URL del servidor. Después de una solicitud DELETE exitosa, el recurso ya no estará disponible en esa URL.
PATCH
El método PATCH se utiliza para aplicar modificaciones parciales a un recurso. Es similar al método PUT, pero solo actualiza partes específicas del recurso en lugar de reemplazar el recurso completo.
HEAD
El método HEAD es similar al método GET, pero solo recupera los encabezados de respuesta y no el cuerpo de la respuesta. Se suele utilizar para comprobar los encabezados en busca de elementos como la existencia de un recurso o las fechas de modificación.
OPTIONS
El método OPTIONS se utiliza para recuperar información sobre las opciones de comunicación disponibles para el recurso de destino. Permite a los clientes determinar los métodos y encabezados compatibles con un recurso en particular.
La dirección del recurso/URL al que el cliente desea acceder.
La página de inicio de un sitio web siempre es 1'/"t. Por supuesto, se pueden solicitar otras páginas, por ejemplo: /downloads/index.php.
Su solicitud siempre hace referencia a la carpeta raíz para especificar el archivo solicitado (de ahí el "/" inicial).
Esta es la versión del protocolo HTTP con el que su navegador desea comunicarse (HTTP 1.0/HTTP 1.1).
Este es el comienzo de los HTTP Request Headers. Los HTTP Headers tienen la siguiente estructura: Heade r -name : Heade r -Value.
El Host header permite que un servidor web aloje varios sitios web en una única dirección IP. Nuestro navegador especifica en el encabezado Host qué sitio web le interesa.
Después de cada encabezado de solicitud, encontrará el valor correspondiente. En este caso, queremos acceder al host www.google.com.
Nota: El valor del host + Path se combinan para crear la URL completa que está solicitando: la página de inicio de www.google.com/
El User-Agent se utiliza para especificar y enviar su navegador, la versión del navegador, el sistema operativo y el idioma al servidor web remoto.
Todos los navegadores web tienen su propia cadena de identificación de User-Agent. Así es como la mayoría de los sitios web reconocen el tipo de navegador en uso.
Su navegador utiliza el encabezado Accept para especificar qué tipos de documentos/archivos se espera que se devuelvan desde el servidor web como resultado de esta solicitud.
El Header Accept-Encoding es similar a Accept y se utiliza para restringir la codificación de contenido aceptable en la respuesta. La codificación de contenido se utiliza principalmente para permitir que un documento se comprima o transforme sin perder el formato original y sin perder información.
Al utilizar HTTP 1.1, puede mantener o reutilizar la conexión al servidor web remoto durante un período de tiempo no especificado utilizando el valor "keep-alive".
Esto indica que todas las solicitudes al servidor web se seguirán enviando a través de esta conexión sin iniciar una nueva conexión cada vez (como en HTTP 1.0).
De manera similar a los encabezados de solicitud, los encabezados de respuesta brindan información adicional sobre la respuesta. Los encabezados comunes incluyen:
Content-Type: el tipo de medio del contenido de la respuesta (p. ej., text/html, application/json).
Content-Length: el tamaño del cuerpo de la respuesta en bytes.
Set-Cookie: se utiliza para establecer cookies en el lado del cliente para solicitudes posteriores.
Cache-Control: directivas para el comportamiento de almacenamiento en caché.
El cuerpo de la respuesta contiene el contenido real de la respuesta. Por ejemplo, en el caso de una página HTML, el cuerpo de la respuesta contendrá el marcado HTML.
Ahora que sabemos de qué se compone una solicitud HTTP, examinemos las respuestas HTTP.
En respuesta a la solicitud HTTP, el servidor web responderá con el recurso solicitado, precedido por un conjunto de nuevos encabezados de respuesta HTTP.
Estos nuevos encabezados de respuesta del servidor web serán utilizados por su navegador web para interpretar el contenido incluido en el contenido/cuerpo de la respuesta.
El fragmento de código que aparece a continuación es un ejemplo de una respuesta típica de un servidor web.
Nota: Se ha omitido el cuerpo de la respuesta o el contenido de la página, ya que no es relevante en este momento.
Examinemos algunos de estos encabezados de respuesta HTTP con mayor detalle.
La primera línea de una respuesta HTTP es la línea de estado (Status-Line), que consta de la versión del protocolo (HTTP 1.1) seguida del código de estado HTTP (200) y su significado textual relativo (0K).
200 0K
La solicitud se realizó correctamente y el servidor ha devuelto los datos solicitados.
301 Moved Permanently
El recurso solicitado se ha movido de forma permanente a una nueva URL y el cliente debe utilizar la nueva URL para todas las solicitudes futuras.
302 Found
El recurso solicitado se encuentra temporalmente en una URL diferente. Este código se utiliza habitualmente para redirecciones temporales, pero suele ser mejor utilizar 303 o 307 en su lugar.
400 Bad Request
El servidor no puede procesar la solicitud debido a un error del cliente (por ejemplo, sintaxis de solicitud mal formada).
401 Unauthorized
Se requiere autenticación y el cliente debe proporcionar credenciales válidas para acceder al recurso solicitado.
403 Forbidden
El servidor entendió la solicitud, pero el cliente no tiene permiso para acceder al recurso solicitado.
404 Not Found
No se pudo encontrar el recurso solicitado en el servidor.
500 Internal Server Error
El servidor encontró un error al procesar la solicitud y no se proporciona la causa específica.
El encabezado "Date" de una respuesta HTTP se utiliza para indicar la fecha y la hora en que el servidor generó la respuesta.
Ayuda a los clientes e intermediarios a comprender la actualidad de la respuesta y a sincronizar la hora entre el servidor y el cliente.
Los encabezados de caché permiten que el navegador y el servidor se pongan de acuerdo sobre las reglas de almacenamiento en caché. Permiten a los servidores web indicar a los clientes durante cuánto tiempo pueden almacenar en caché la respuesta y en qué condiciones deben volver a validarla con el servidor.
Esto ayuda a optimizar el rendimiento y la eficiencia de las aplicaciones web al reducir las solicitudes de red innecesarias.
Public
Indica que la respuesta puede ser almacenada en caché por cualquier caché intermedio (como servidores proxy) y compartida entre diferentes usuarios.
Private
Especifica que la respuesta está destinada a un usuario específico y no debe ser almacenada en caché por cachés intermedios.
no-cache
Indica al cliente que vuelva a validar la respuesta con el servidor antes de usar la versión almacenada en caché. No impide el almacenamiento en caché, pero requiere la revalidación.
no-store
Indica al cliente y a los cachés intermedios que no almacenen ninguna versión de la respuesta. Garantiza que la respuesta no se almacene en caché en ningún formato.
max-age=<SECONDS>
Especifica la cantidad máxima de tiempo en segundos que el cliente puede almacenar en caché la respuesta. Después de este período, el cliente debe volver a validar con el servidor.
El encabezado "Content-Type" en una respuesta HTTP se utiliza para indicar el tipo de contenido del medio de la respuesta.
Le indica al cliente qué tipo de datos está enviando el servidor para que el cliente pueda manejarlos adecuadamente.
El encabezado "Content-Encoding" de una respuesta HTTP se utiliza para especificar la codificación de compresión aplicada al contenido de la respuesta.
Le indica al cliente cómo ha codificado el servidor los datos de respuesta, lo que permite al cliente decodificarlos y descomprimirlos correctamente.
El encabezado "Server" muestra el banner del servidor web, por ejemplo, Apache, Nginx, IIS, etc.
Google utiliza un banner de servidor web personalizado: gvvs (Google VVeb Server).
Existe dos tipos de comunicaciones que se realiza durante una navegacion web, uno es atravez del la conexion htpp (rquest/response) y otro es a nivel de TCP
Antes de inicializar una comunicacion http, primero se inicia una conexion TCP, como se observa en la siguiente imagen.
Una vez que la conexion a nivel de TCP sea exitosa, se procede a la conexion a nivel de http, en el mismo se ve un paquete con la solicitud "GET", y si ingresamos al paquete en la sección "Hypertext Transfer Protocol" podremos observar todas las cabeceras del cuerpo de la solicitud
Si le da follow a los paquetes de TCP Stream, podra obserbar que tiene paquetes tanto de solicitud como respuestas, y podrá observar como funciona los paquetes de gzip, desde la descargar hasta que los mismos se descomprimen.
Los archivos gzip generalmente se encuentran codificados, pero desde wireshark se puede decodificar y descargar. Menu > File > Export Objects > HTTP
A continuación se presenta un ejemplo de cómo podría verse la salida del comando curl -v http://192.191.151.3/:
En este ejemplo, curl establece una conexión con el servidor, envía una solicitud GET, y recibe una respuesta HTTP 200 junto con contenido tipo text/html.
Las cabeceras HTTP proporcionan información adicional sobre la solicitud o respuesta. A continuación se describen algunas de las cabeceras presentes en el ejemplo:
Date: Indica la fecha y hora en la que se generó la respuesta en formato GMT.
Server: Especifica el software que está sirviendo la solicitud, en este caso, Apache versión 2.4.41 en Ubuntu.
X-Powered-By: Muestra la tecnología detrás del servidor, aquí PHP versión 5.5.9.
Set-Cookie: Asigna una cookie al cliente, aquí con el valor PHPSESSID que identifica la sesión.
Content-Type: Define el tipo de contenido de la respuesta, en este caso text/html con charset UTF-8.
Content-Length: Indica el tamaño del cuerpo de la respuesta en bytes.
Cache-Control y Pragma: Controlan el almacenamiento en caché de la respuesta.
Vary: El uso de esta cabecera permite al servidor indicar que puede devolver diferentes respuestas con base en ciertos parámetros del request, como Accept-Encoding.
Estas cabeceras permiten manejar aspectos como el almacenamiento de datos, la seguridad, y la presentación del contenido.
Utilizando el comando curl, puedes inspeccionar las cabeceras de una respuesta HTTP sin necesidad de descargar el cuerpo completo. En el ejemplo proporcionado, el comando curl -v -I http://192.191.151.3/ realiza una solicitud HEAD al servidor, mostrando exclusivamente las cabeceras HTTP. Esta práctica es útil para verificar la configuración del servidor y depurar problemas sin transferir datos innecesarios.
Las cabeceras HTTP juegan un papel crucial en el manejo de la interacción entre cliente y servidor, y entender sus características permite optimizar el rendimiento de aplicaciones web, mejorar la seguridad y garantizar una experiencia de usuario consistente.
En este contexto, la respuesta a una solicitud OPTIONS proporciona información crucial sobre los métodos HTTP permitidos por el servidor, tales como GET, HEAD, y OPTIONS mismos. Esto es vital para asegurar que las aplicaciones que interactúan con el servidor estén alineadas con las capacidades de procesamiento previstas. Al conocer qué solicitudes son aceptadas, los desarrolladores pueden adecuar sus implementaciones para evitar errores y optimizar las interacciones con el servidor.
For casos en los que necesitas enviar datos al servidor para actualizar un recurso existente, el método PUT es el adecuado. Utilizando curl, puedes enviar una solicitud PUT de la siguiente manera, para actualizar datos en el recurso especificado por la URL:
Este comando envía los datos especificados en -d, que puede ser en formato clave-valor o incluso un archivo JSON, dependiendo de lo que el servidor espera. Asegúrate de verificar que el servidor permite las solicitudes PUT revisando la respuesta a una solicitud OPTIONS como se explicó anteriormente.
Si el método no es aceptado por el servidor, recibirás una respuesta con el código de estado HTTP 405 Method Not Allowed. Esta respuesta incluirá una cabecera Allow que enumera los métodos permitidos para el recurso solicitado. Un ejemplo de cómo se vería esta respuesta es:
Es crucial monitorear la respuesta OPTIONS para adaptar tus solicitudes adecuadamente.
En caso de que se detecte un directorio donde se pueda subir archivos.
Subiar archivo con malware utilizando curl
Eliminar el archivo que se subió
Ahora que comprende cómo funciona HTTP, analicemos cómo se protege.
De manera predeterminada, las solicitudes HTTP se envían en texto sin formato (clear-text) y un atacante puede interceptarlas o alterarlas fácilmente durante el camino hacia su destino.
Además, HTTP no proporciona una autenticación sólida entre las dos partes que se comunican.
HTTPS (Hypertext Transfer Protocol Secure) 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 una aplicación web.
HTTPS proporciona una capa adicional de seguridad al cifrar los datos transmitidos a través de Internet, lo que los hace más seguros y los protege del acceso no autorizado y la interceptación.
HTTPS también se conoce comúnmente como HTTP Secure.
HTTPS es la forma preferida de usar y configurar HTTP e implica ejecutar HTTP sobre SSL/TLS.
SSL (Secure Sockets Layer) y TLS (Transport Layer Security) 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 integridad y autenticación al protocolo HTTP.
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 puedan espiar los datos intercambiados entre el navegador del usuario y el servidor web. Esto es especialmente crucial cuando los usuarios ingresan información confidencial, como credenciales de inicio de sesión, números de tarjetas de crédito o datos personales.
El protocolo HTTPS no protege contra fallas en aplicaciones web. Diversos 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 agregada solo protege los datos intercambiados entre el cliente y el servidor y detiene los ataques contra la propia aplicación web.
