Protocolo HTTP

© Ediciones Roble, S.L.

 Indice
Protocolo HTTP 3
I. Introducción 3
II. Objetivos 3
III. Introducción al protocolo HTTP 4
3.1. Funcionamiento y características 6
3.2. Análisis de una petición estándar HTTP 10
IV. Métodos y códigos de respuesta 11
4.1. Métodos HTTP 12
4.2. Códigos de estado 13
V. Codificación de la información 15
VI. Introducción a las vulnerabilidades en aplicaciones web 17
6.1. ¿Cómo trabajan las aplicaciones web? 17
6.2. Arquitecturas escalables 18
VII. Proyecto OWASP y vulnerabilidades en aplicaciones web 21
VIII. Esnifado y codificación de cabeceras 21
8.1. Concepto de inyección en una cabecera HTTP 22
IX. Resumen 23
X. Lecturas y enlaces recomendados 23
Ejercicios 24
Caso práctico 24
Se pide 24
Solución 24
Recursos 28
Enlaces de Interés 28
Bibliografía 28
Glosario. 29

2/29
 Protocolo HTTP

Protocolo HTTP

I. Introducción

En la presente unidad se dará una visión general de qué es el protocolo HTTP, basado en un esquema de
peticiones y respuestas: está destinado a las transacciones de información entre el cliente y el servidor.
También se centrará en el estudio de la capa de aplicación del modelo OSI estudiando sus RFC (request for
comments), la cual sirve como nexo entre las demás y permite al usuario acceder al resto de capas. Además, es
la encargada de definir los protocolos para la transacción de información dentro de las propias aplicaciones,
como puede ser el correo electrónico o los gestores de bases de datos.

Se analizarán las líneas de inicio o cabeceras HTTP -más conocidas como cabeceras de las peticiones- y las
líneas de inicio de una respuesta HTTP. Se conocerán sus principales métodos o verbos empleados y cómo se
realiza la comunicación entre el cliente y el servidor, así como cuáles son los códigos de respuesta que se
emplean para cada comunicación.

Se mostrará una visión generalista de las vulnerabilidades de las aplicaciones web practicando cómo
interceptar y modificar el tráfico HTTP a modo de introducción general, lo que servirá para desarrollar
correctamente los módulos formativos que conforman el presente curso.

II. Objetivos

Introducir el protocolo HTTP en la capa de aplicación del modelo OSI.

Analizar las cabeceras del protocolo HTTP.

3/29
 Protocolo HTTP

Conocer los principales métodos del protocolo HTTP.

Interpretar los códigos de respuesta del protocolo HTTP.

Ofrecer una visión general sobre las vulnerabilidades de las aplicaciones web.

Interceptar y modificar el tráfico HTTP.

III. Introducción al protocolo HTTP

Dentro del modelo TCP/IP definido en los años setenta para la primera red -la predecesora de internet tal y
como se conoce hoy en día- existen diversas capas que definen su arquitectura. Una de estas capas, la cuarta
en el modelo TCP/IP y la séptima en el OSI, es la denominada nivel de aplicación, la cual define la utilización de
diversos protocolos para realizar el intercambio de datos, entre los que cabe destacar los tres más importantes:
HTTP, SMTP y FTP. Si bien es cierto que cualquiera de ellos podría ser utilizado para realizar la transferencia
de estos datos mediante mensajes, es el protocolo HTTP el que ha quedado establecido como estándar para
su uso en la web y, además, es el más usado en los servicios web que envían XML o JSON como estructura de
datos.

4/29
 Protocolo HTTP

En la figura 1 se pueden observar los distintos protocolos que han sido definidos en las respectivas capas del
modelo OSI (Open System Interconnection), definido en la norma internacional ISO/IEC 7498-1 como modelo de
referencia. Todos los protocolos permiten su implementación de una forma flexible, según la cual pueden
presentar deficiencias en su diseño y, por tanto, ofrecer de alguna forma vulnerabilidades que afecten a las
características de seguridad de una aplicación (integridad, disponibilidad y confidencialidad).

Figura 1. Pila de capas o niveles OSI.

Fuente: LordT, CreativeCommons 2.0.

El protocolo de transferencia de hipertexto (hypertext transfer protocol) es un protocolo cliente-servidor sencillo

que permite articular el intercambio de información entre los servidores HTTP y los clientes web. HTTP es un
protocolo del nivel de aplicación -comentado anteriormente- que se utiliza para la transferencia de información
entre sistemas de forma clara y rápida. Este protocolo ha sido usado por la World Wide Web desde su creación
en 1990. La especificación completa del protocolo HTTP está recogida en distintas RFC, dependiendo de la
versión; las más importantes son la RFC 1945 y la RFC 2616. Fue propuesto por Tim Berners-Lee ante la
necesidad de distribuir e intercambiar información acerca de sus investigaciones de una manera más efectiva.

El protocolo HTTP se basa en un paradigma sencillo de operaciones correspondientes a peticiones y

respuestas. Un cliente establece una conexión con el servidor y realiza el envío de una petición en forma de
método, una URI y una versión de protocolo, seguido de los modificadores de la petición, la información sobre el
cliente y un posible contenido al final. El servidor responde de forma similar con una línea de estado que incluye
la versión del protocolo y un código que indica el éxito o el error de la solicitud, seguida de la información del
servidor en forma de mensaje MIME y un posible contenido.

5/29
 Protocolo HTTP

3.1. Funcionamiento y características

HTTP se trata de un protocolo que se establece sobre la capa de transporte en la arquitectura

TCP/IP, de forma que, desde el punto de vista de las comunicaciones, funciona de la misma
forma que el resto de servicios con una conexión TCP/IP: un proceso queda a la escucha en un
puerto de comunicaciones TCP -por defecto es el 80-, forma el servidor y espera recibir las
peticiones de conexión de los distintos clientes web que quiera conectar. Una vez establecida
esa conexión, el protocolo TCP se encargará de mantener la comunicación y de garantizar en
todo momento un intercambio de datos libre de errores.

Como se ha podido ver en la introducción, HTTP se basa en operaciones de petición/respuesta. Este flujo queda
definido por los siguientes pasos:

El cliente debe establecer la conexión con un servidor.

El cliente envía un mensaje con los datos de la solicitud.

El servidor responde con un mensaje que contiene el estado de la operación y su posible resultado.

Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan, ya sea enviado
desde el cliente o como respuesta del servidor. Cada objeto web disponible en el servidor es
identificado por su URL.

La figura 2 muestra el flujo de estas operaciones de diálogo generadas por el protocolo HTTP cuando se lanza una
solicitud de servicio en una aplicación web.

6/29
 Protocolo HTTP

Figura 2. Diálogo de HTTP.

Fuente: elaboración propia, Cyber Academy.

El protocolo HTTP ha recibido distintas actualizaciones a lo largo de toda su historia y ha pasado por múltiples
versiones, muchas de ellas compatibles con las anteriores. Actualmente, la versión más actualizada es la HTTP/3.
Se detallan a continuación las principales características del protocolo HTTP en general y las añadidas en sus
distintas versiones:

HTTP

Primera versión del protocolo, lanzada en 1991.

HTTP/1.0

Primera revisión del protocolo, generada en 1996. Añade la especificación de la versión en las comunicaciones
y permite los métodos GET, HEAD y POST.

HTTP/1.1

Es la versión más utilizada a día de hoy. Fue lanzada en 1999 y permite mantener la persistencia en las
conexiones; es decir, no es necesario abrir y cerrar un socket por cada petición que se realiza, sino que se
puede mantener abierto siempre que no se haya finalizado la comunicación, lo que aumenta considerablemente
la velocidad de acceso a los servidores.

7/29
 Protocolo HTTP

HTTP/2

Nueva versión del protocolo lanzada en 2015. Añade mejoras en el empaquetado de los datos y en su
transporte; por ejemplo, añade compresión en las cabeceras o el uso de una única conexión.

HTTP/3

Propuesta de sucesión lanzada en 2018 que utiliza UDP en lugar de TCP.

De forma general, las características principales del protocolo son las siguientes:

Toda la comunicación realizada entre el cliente y el servidor se realiza a partir de caracteres de ocho bits.

Permite la codificación de archivos binarios en cadenas de caracteres para su transferencia. El contenido de

cada objeto intercambiado está identificado por su clasificación MIME.

Existen ocho métodos (verbos) principales que permiten que un cliente pueda dialogar con el servidor. Los
cuatro más utilizados son:

GET

Para recoger un objeto.

POST

Para enviar información al servidor.

PUT

Para enviar un objeto.

HEAD

Para solicitar las características de un objeto (por ejemplo, la fecha de modificación de un documento
HTML).

8/29
 Protocolo HTTP

Toda operación HTTP implica una conexión con el servidor, la cual es liberada al finalizar. Cada operación
recoge un único objeto. La versión HTTP/1.1 permite que una misma conexión se mantenga activa durante
cierto periodo de tiempo, de forma que puede ser utilizada en sucesivas transacciones. Este mecanismo se
denomina HTTP keep alive y es empleado por la mayoría de los clientes y servidores modernos. HTTP 2, por
su parte, amplía este proceso de conexiones persistentes con opciones adicionales, como la multiplexación.

Se trata de un protocolo sin estado; es decir, cada petición de un cliente a un servidor no es influida por las
transacciones anteriores. Esto hace que el servidor trate cada una de las peticiones como una operación
totalmente independiente del resto.

Todo objeto accesible mediante un método está identificado a través de un localizador de recursos uniforme
(URL) único.

Para entender correctamente el funcionamiento del protocolo HTTP se definen a continuación los pasos que se
ejecutan cada vez que un cliente realiza una petición a un servidor:

Un usuario final accede a una URL desde su navegador, ya sea seleccionando un enlace de un documento
HTML o introduciéndola directamente en la barra de navegación.

El cliente web (navegador) descodifica la URL para separar cada una de sus diferentes partes. De esta forma,
identifica el protocolo de acceso (http, ftp, https, etc.), el puerto (de carácter opcional; el valor por defecto es 80 y
443), el dominio o host y el objeto requerido del servidor.

Se establece una conexión TCP/IP con el servidor mediante el puerto TCP correspondiente.

El cliente envía la petición HTTP. Esto incluye, por orden, el envío del método o verbo necesario (GET, POST,
PUT, HEAD , etc.), la dirección al objeto solicitado (el contenido de la URL que sigue a la dirección del servidor),
la versión del protocolo HTTP solicitada por el cliente y un conjunto variable de información, que incluye datos
sobre las capacidades del navegador, datos opcionales para el servidor, etc.

9/29
 Protocolo HTTP

El servidor devuelve la respuesta HTTP al cliente. El mensaje de respuesta está formado por un código de
estado y el tipo de dato MIME de la información de retorno, seguidos de la propia información.

Finalmente, la conexión TCP finaliza. Si no se utiliza el modo HTTP keep alive, este proceso se repite para cada
acceso al servidor HTTP.

Como se ha podido ver en la descripción del flujo, solo existen dos tipos de mensajes diferentes: uno para
peticiones y otro para respuestas. Este diálogo del cliente con los servidores HTTP se establece a través de
mensajes formados por líneas de texto plano, cada una de las cuales contiene los diferentes comandos y opciones
del protocolo.

3.2. Análisis de una petición estándar HTTP

Para realizar un breve análisis de una petición estándar de HTTP se lleva a cabo una petición GET a un sitio web
como www.google.es. A continuación, se muestran la petición y la respuesta recibida para identificar las
cabeceras.

Ejemplo estándar de petición GET

$ curl -v www.google.es/
Trying 216.58.210.163... Connected to www.google.es port 80
> GET / HTTP/1.1
> Host: www.google.es
> User-Agent: curl/7.50.1
> Accept: */*

< HTTP/1.1 200 OK

< Date: Wed, 02 Apr 2019 14:51:20 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=ISO-8859-1
< Content-Length: 2580
< Connection: close
<
< […]

Al realizar la petición, se muestra un código de respuesta (200-OK) del tipo 2xx -que será detallado más adelante-,
además de otra serie de parámetros como:

10/29
 Protocolo HTTP

User-agent

Incluye información sobre el dispositivo de consulta (normalmente se corresponde con el nombre y la versión del
navegador web) que realiza la petición HTTP.

Date

Fecha y hora actual del servidor.

Cache-control

Genera las directivas que deben ser usadas por cualquier mecanismo a lo largo de la petición/respuesta.

Content-type

Define el tipo de contenido y de codificación.

Content-length

Se refiere al tamaño de la información contenida en el cuerpo del mensaje.

Connection

Indica que la conexión se cierra (no se mantiene como en keep alive).

IV. Métodos y códigos de respuesta

El protocolo HTTP tiene definidas unas palabras clave que están reservadas para el lenguaje de la comunicación.
En este apartado se describen las siguientes dos partes reservadas del protocolo:

Una de estas palabras reservadas son los métodos de petición o verbos que se utilizan para indicar la acción
que se quiere efectuar sobre el recurso identificado al que se realiza la petición.

El otro apartado reservado corresponde a los códigos de estado de la respuesta, los cuales son un número que
indica qué ha ocurrido con la petición recibida.

11/29
 Protocolo HTTP

4.1. Métodos HTTP

Se mencionan a continuación los métodos HTTP más comunes y los más usados dentro de una navegación web
cotidiana. Es importante tenerlos identificados, ya que son los más manipulados en ataques y técnicas de
pentesting y de esnifado en las aplicaciones.

GET

Sirve para pedir una representación del recurso especificado. Este método es utilizado siempre que un usuario
pulsa sobre un enlace o teclea directamente una URL en la barra de navegación. El resultado a esta petición
será la recepción del documento ubicado en la dirección especificada por dicha URL. Por seguridad y su propia
definición en la RFC, este método no debería ser empleado por aplicaciones que transmitan información
sensible, ya que agrega parámetros en la URL.

HEAD

Es un método similar a GET, con la diferencia de que solicita solo las cabeceras del objeto sin devolver el
cuerpo en la petición. Principalmente, suele ser utilizado por los gestores de cachés de páginas o por los
servidores proxy para conocer cuándo es necesario actualizar la copia que se mantiene de un recurso.

POST

Este método envía datos de información (que viajan en el cuerpo de la petición) al servidor para que este los
administre o los añada a una base de datos. Normalmente, suele utilizarse dentro de un formulario web para
realizar el envío de esa información al servidor.

PUT

Método para almacenar un objeto en la URL especificada. Si la dirección de destino ya contenía el mismo
recurso, se considera que se está enviando una versión actualizada.

DELETE

Método que borra el recurso especificado en la petición. Este comando es muy poco utilizado.

TRACE

Solicita al servidor que realice un mapeo de la solicitud recibida para que la respuesta incluya qué servidores
intermedios están añadiendo información o modificando la petición.

OPTIONS

Devuelve los métodos HTTP que soporta el servidor para una URL. Se suele utilizar para comprobar la
funcionalidad de un servidor web.

12/29
 Protocolo HTTP

CONNECT

Se utiliza en los servidores proxy que puedan establecer un túnel dinámicamente (por ejemplo, un túnel SSL).

El protocolo HTTP ha sido desarrollado de forma que permite una flexibilidad completa a la hora de incorporar
nuevos métodos o verbos para añadir más funcionalidades.

4.2. Códigos de estado

Ante cada transacción con un servidor HTTP, este devuelve un código numérico en la primera línea del mensaje de
respuesta que informa sobre el resultado de la operación. En algunos casos, estos códigos aparecen en la pantalla
del cliente cuando se produce un error.

Los códigos de estado están clasificados en cinco categorías:

1xx

Corresponden a respuestas informativas.

2xx

Corresponden a respuestas asociadas con operaciones exitosas o correctas.

3xx

Corresponden a respuestas de redirección, que informan de las operaciones complementarias que debe
realizar el cliente para finalizar la operación.

4xx

Corresponden a errores en el lado del cliente (el requerimiento contiene algún error o no puede ser realizado).

5xx

Corresponden a errores en el lado del servidor (no se ha podido llevar a cabo una solicitud).

En la tabla 1 se presenta de forma resumida una lista con los códigos de respuesta que se utilizan con mayor
frecuencia en una navegación web cotidiana:

Tabla 1. Listado de códigos HTTP más frecuentes

13/29
 Protocolo HTTP

Código Acción Descripción

200 OK La operación se ha realizado de forma correcta y

satisfactoria.

201 Created La operación se ha realizado de forma correcta y, como

resultado, se ha generado un nuevo objeto cuya URL de
acceso se proporciona en el cuerpo de la respuesta. El nuevo
objeto ya está disponible.

202 Accepted La operación se ha realizado de forma correcta y, como

resultado, se ha generado un nuevo objeto cuya URL de
acceso se proporciona en el cuerpo de la respuesta. El nuevo
objeto no está accesible aún, pero en el cuerpo del mensaje
se informa de cuándo estará disponible.

204 No Content La operación ha sido aceptada, pero no ha producido ningún

resultado que deba mostrar información de interés. No es
necesario que el cliente actualice el objeto que está
mostrando.

301 Moved Permanently El objeto solicitado ha sido movido a otra ubicación

permanentemente. El servidor devuelve un campo
denominado Location con la información de la nueva
localización del objeto.

302 Found El objeto solicitado ha sido movido a otra ubicación de forma

temporal. El servidor devuelve un campo denominado
Location con la información de la nueva localización del
objeto.

304 Not Modified Estado devuelto tras recibir una petición GET condicional que
no ha modificado el objeto.

400 Bad Request La petición no es entendida por el servidor (posiblemente, por

un error de sintaxis).

14/29
 Protocolo HTTP

401 Unauthorized El recurso solicitado requiere de una autorización especial en

la petición que, normalmente, consiste en un nombre y una
clave. El servidor informa de los protocolos de autenticación
disponibles para este recurso mediante el campo WWW-
Autenticate.

403 Forbidden El objeto solicitado está protegido contra el acceso y no es

posible utilizar una clave para modificar la protección.

404 Not Found La URL solicitada no existe, no está disponible o no se

encuentra.

500 Internal Server Error El servidor ha sufrido algún error interno y no puede continuar
con la solicitud.

501 Not Implemented El servidor no tiene la capacidad para llevar a cabo el

requerimiento del cliente por su diseño interno.

502 Bad Gateway El servidor ha encontrado un error al acceder al recurso que

había solicitado el cliente.

503 Service Unavailable El servidor está deshabilitado o inaccesible y no es capaz de

atender la petición.

Tabla 1. Listado de códigos HTTP más frecuentes.

Fuente: RFC (www.rfc-editor.org).

V. Codificación de la información

El protocolo HTTP es ampliamente usado debido a una de sus características principales: permite el envío de
información mediante texto plano utilizando un conjunto de caracteres entendibles y fáciles de gestionar. Sin
embargo, debido a la evolución que ha sufrido internet, es necesario disponer de un mecanismo que permita el
envío de información distinta al texto plano -como puede ser un archivo binario (imagen, vídeo, música, etc.)-,
cuyo contenido no puede ser representado por este grupo tan reducido de caracteres.

15/29
 Protocolo HTTP

En este sentido y para poder solventar esta limitación en el envío de archivos, se genera el estándar de internet
denominado MIME (multipurpose internet mail extensions o extensiones multipropósito de correo de internet). El
estándar está comprendido por una serie de convenciones o especificaciones dirigidas a que se puedan
intercambiar todo tipo de archivos (texto, audio, vídeo, etc.) a través de internet de forma transparente para el
usuario. Además, MIME también ha permitido mejorar las posibilidades de transferencia de texto en distintos
idiomas y alfabetos. Toda la especificación de este estándar se encuentra recogida dentro de las RFC 2045,
2046, 2047, 4288, 4289 y 2049.

Normalmente, todos los objetos o recursos que son enviados dentro de una petición o respuesta del protocolo
HTTP están clasificados por su descripción MIME, la cual viene especificada en el campo de cabecera
denominado Content-type. De esta forma, el protocolo puede intercambiar cualquier tipo de dato sin
preocuparse de su contenido.

La identificación del tipo con el estándar MIME permite que el receptor o intérprete trate los datos
adecuadamente. La IANA (Internet Assigned Numbers Authority) gestiona la definición de los nueve tipos
disponibles: text, application, audio, example, image, message, model, multipart y video. Además, dentro de
cada tipo hay multitud de subtipos: text/html, image/gif, image/jpeg, audio/x-mpeg, video/quicktime, etc.

Por otro lado, el contenido del cuerpo (body) de una respuesta HTTP se codifica siguiendo uno de los tres
métodos básicos de codificación existentes:

7 bits

Utilizado por defecto. Supone que los archivos son de texto.

Quoted-printable

Es utilizado para la codificación de textos que contienen caracteres que exceden los siete bits utilizados en
US-ASCII. Con esto, se permite la representación de caracteres de otros alfabetos, como los idiomas
procedentes del latín. Funciona mediante la codificación en tres caracteres de siete bits (por ejemplo, la letra
ñ se corresponderá con los tres caracteres “=F1”).

Base64

Es utilizado para la codificación de contenido que no es legible por humanos, como pueden ser los archivos
de vídeo o las imágenes. De forma resumida, cada tres octetos se codifican cuatro caracteres que
pertenecen a un subconjunto de 64 caracteres imprimibles del US-ASCII.

16/29
 Protocolo HTTP

Es importante diferenciar correctamente un algoritmo de cifrado de una codificación, ya que estas últimas son
siempre reversibles y no necesitan de una contraseña para obtener el texto en claro. La información sensible o
confidencial debe almacenarse siempre utilizando un algoritmo de cifrado robusto -ya sea simétrico (AES) o
asimétrico (RSA)- o incluso un algoritmo de hash para el caso de contraseñas, como puede ser SHA-256 o
PBKDF2.

VI. Introducción a las vulnerabilidades en aplicaciones web

En esta sección se recoge una breve descripción de cómo trabajan e interactúan las aplicaciones y los servicios
web con diferentes componentes y escenarios tecnológicos para, posteriormente, adentrarse en la gestión de
vulnerabilidades en aplicaciones web.

6.1. ¿Cómo trabajan las aplicaciones web?

Hoy en día, se puede decir que el uso de las aplicaciones web es tan común que está masificado por todo tipo de
usuarios, instituciones y empresas privadas. Existen distintos usos de las aplicaciones web: desde la simple acción
de poder leer el correo electrónico hasta realizar una transacción bancaria o una compra en línea, sin importar su
cobertura, su tamaño, su diseño, su código de implementación, sus plataformas y su arquitectura.

A simple vista, se puede observar que la forma en la que una aplicación web trabaja es sencilla
y práctica, lo que puede explicar por qué son más vulnerables (sin llegar a ser una afirmación).
Por lo general, las aplicaciones web consisten en una base de datos que está ubicada en
varias capas por detrás del servidor que aloja el sitio web y que está escrita en un lenguaje de
programación que es capaz de extraer información específica de esa base de datos por
solicitudes y peticiones de los usuarios remotos o locales mediante interacciones dinámicas
con esos usuarios o clientes.

Teniendo en cuenta esa definición a alto nivel, normalmente es muy común que las aplicaciones estén compuestas
por tres niveles cuando se usan bases de datos para la gestión de la información. Estos tres niveles vienen
representados de la siguiente forma:

Un nivel de presentación

Formado por un navegador web o motor de búsqueda.

Un nivel lógico

Escrito en un lenguaje de programación, como puede ser Java, C#, .NET, PHP, etc.

17/29
 Protocolo HTTP

Un nivel de almacenamiento

Formado por una o varias bases de datos, como MySQL, Microsoft SQL Server, MongoDB, etc.

Figura 3. Niveles de una aplicación.

Fuente: OpenSource. Copyright de las marcas por sus respectivos fabricantes.

En la figura 3 se puede observar la secuencia de peticiones y la operación de los tres niveles: el navegador web
(nivel de presentación) -por ejemplo, Chrome, Safari, Firefox, etc.- envía peticiones a la capa media (nivel lógico),
que define los servicios, las solicitudes, las consultas y las actualizaciones de la base de datos (nivel de
almacenamiento).

6.2. Arquitecturas escalables

Este modelo de tres niveles ha demostrado no ser eficiente cuando la carga soportada aumenta de forma
exponencial, como ha ocurrido en los últimos años con el uso de internet desde cualquier dispositivo. Es por
esto por lo que el modelo de tres niveles tuvo que ser reevaluado para generar un nuevo concepto que se basa
en la escalabilidad y el mantenimiento.

18/29
 Protocolo HTTP

En este nuevo diseño de la arquitectura surge la solución de cuatro niveles, la cual incluye una nueva pieza
denominada middleware -típicamente llamado servidor de aplicaciones- entre el servidor web y el servidor de la
base de datos.

Esta nueva arquitectura consta de un servidor en una nueva capa de abstracción que aloja una interfaz de
programación de aplicaciones o API (application programming interfaces) para conseguir exponer la lógica y los
procesos de negocio de forma que sean usados por los servidores web. Además, el servidor de aplicaciones
puede hablar con varias fuentes de datos, incluyendo bases de datos, mainframes u otros sistemas.

Figura 4. Esquema de arquitectura escalable.

Fuente: OpenSource. Copyright de las marcas por sus respectivos fabricantes.

En la figura 4, el navegador web (capa de presentación) envía la petición a la capa intermedia (capa lógica), que, a
su vez, llama a la API expuesta del servidor de aplicaciones, que reside en la capa de aplicación y es el que realiza
las consultas y las actualizaciones de la base de datos (capa de almacenamiento).

Los pasos completos del flujo quedan definidos de la siguiente forma:

El usuario final ejecuta una consulta en el navegador instalado en el cliente y se conecta a

http://www.servidor.com.

El servidor web que reside alojado en la capa lógica se encarga de ejecutar una secuencia de comandos del
sistema de archivos y se lo pasa a través de su motor de scripting, en el que se analiza y se ejecuta.

19/29
 Protocolo HTTP

El script llama a una API expuesta desde el servidor de aplicación que reside en la capa de aplicación
mencionada.

El servidor de aplicación es el encargado de abrir una conexión con la capa de almacenamiento utilizando un
conector o un sistema de gestión de base de datos y ejecuta una instrucción SQL o NoSQL en la base de datos.

Se devuelven los datos al conector de la base de datos y al servidor de aplicaciones que implementa las reglas
de la lógica de aplicación o negocio antes de devolver los datos al servidor web, que aplica un retoque (de
lógica final) antes de la presentación de los datos en formato HTML en el navegador web del usuario.

La presentación de la web en el navegador final se realiza mediante HTML y JavaScript y se muestra al usuario
una representación gráfica del código.

Todos estos pasos anteriores suceden de forma transparente para el usuario final, ya que tienen lugar de manera
instantánea e imperceptible. Igualmente, se debe plantear la reflexión de por qué se dividen las tareas en capas o
niveles. El concepto básico de una arquitectura estratificada trae consigo la división de una aplicación en trozos
lógicos o niveles, a cada uno de los cuales se le asignan roles o tareas para desempeñar. Todas estas capas
pueden localizarse o implementarse en diferentes máquinas -físicas o virtuales-, incluso en la misma máquina de
forma virtualizada o separadas la una de la otra.

Ventajas de la arquitectura por capas

Si se dividen las responsabilidades en múltiples capas, el escalado de la aplicación es más fácil, las tareas
de desarrollo se distribuyen de una forma más eficiente y hace que sea más fácil de entender o leer, lo que
permite su reutilización en otras aplicaciones existentes o nuevas.

Las capas otorgan características de robustez a las aplicaciones diseñadas con esta arquitectura, lo que
permite eliminar puntos de fallos críticos y únicos que puedan presentarse si la aplicación o servicio sufre una
caída total o irreparable.

20/29
 Protocolo HTTP

La decisión de cambiar de proveedor o de sistema de bases de datos no requerirá nada más que algunos
cambios en las porciones aplicables de la capa de aplicación, la presentación y los niveles lógicos que
hagan uso de ella.

VII. Proyecto OWASP y vulnerabilidades en aplicaciones

web

Antes de entrar en la temática fuerte de la seguridad en aplicaciones web, hay que hacer referencia al proyecto
OWASP: el proyecto abierto de seguridad en aplicaciones web (Open Web Application Security Project). Se
trata de una comunidad abierta dedicada a habilitar a las organizaciones para desarrollar, comprar y mantener
aplicaciones confiables.

En las próximas unidades formativas se trabajará en profundidad con todos y cada uno de los riesgos y
vulnerabilidades de seguridad más comunes que se producen en las aplicaciones web según OWASP. Esta
información queda reflejada en lo que se conoce como OWASP Top 10.

Ejercicio de webgoat relativo a HTTP/HTTPS

VIII. Esnifado y codificación de cabeceras

El temario que se ha tratado hasta aquí ha descrito de forma general el protocolo HTTP y las negociaciones o
diálogos entre cliente y servidor que se establecen a través de peticiones y respuestas que incluyen cabeceras,
también denominadas en el lenguaje profesional HTTP Headers.

Para poder trabajar fácilmente con las cabeceras de una petición o respuesta HTTP se deben adquirir y
configurar una serie de utilidades cuya finalidad es interceptar las peticiones que manda nuestro navegador con
el objeto de realizar un análisis o, incluso, una modificación de estas. Dichas utilidades pueden estar incluidas
en dos categorías de aplicaciones: los denominados sniffers (esnifadores), que funcionan interceptando los
paquetes de red en tránsito, o los denominados proxy, que hacen de intermediarios en las peticiones de
recursos que realiza un cliente a un servidor.

21/29
 Protocolo HTTP

Estas herramientas pueden ser instaladas en forma de addons o plugins para los diferentes navegadores -entre
los que destacan Firefox, Tamper Data y Live HTTP Headers- o también pueden ser programas proxy
independientes de propietarios (Burp Suite) o de código abierto (OWASP ZAP). Además, permiten realizar
estudios sobre las peticiones de HTTP de forma que sea posible la manipulación o alteración tanto de
cabeceras HTTP como del contenido propiamente dicho.

Adicionalmente, existen también otras formas de trabajar con las cabeceras para modificarlas sin tener que
esnifearlas: por ejemplo, aprovechar algún tipo de programa que realice las negociaciones TCP, como pueden
ser Telnet, Putty o los populares Netcat y Netcat-NG (NextGeneration), que incluso soporta la pila de protocolos
IPv6. Asimismo, existen otros programas, como Ncat, que permiten realizar conexiones con cifrado SSL, por lo
que se permite la omisión de firewall en muchos casos.

8.1. Concepto de inyección en una cabecera HTTP

El proceso de sniffing o de interceptar las cabeceras HTTP puede realizarse con dos objetivos, principalmente:

Observar los datos que se envían y de ahí buscar un posible CSRF (cross-site request forguery), XSS (cross-site
scripting), SQLi (inyección SQL), etc.

Para manipular las cabeceras enviadas y añadirle algún código malicioso que provoque en una aplicación
vulnerable una respuesta que no era la que debía.

Dicho código malicioso es inyectado en una de las cabeceras de la petición; si en el lado del servidor se está
realizando algún tipo de procesado de los datos procedentes de la cabecera sin realizar un correcto filtrado o
saneado, una aplicación web se puede llegar a volver vulnerable.

Esto ocurre más aún cuando, sin restricciones o controles de acceso, se permite a usuarios
malintencionados o maliciosos (usuarios mal denominados hackers; en realidad son
ciberdelincuentes) la modificación de la cabecera para que la aplicación web maneje estos
códigos maliciosos y los procese o ejecute. De esta forma, se pueden convertir las cabeceras
en un medio para inyectar sentencias de SQL maliciosas, código JavaScript, etc., con el objeto
de realizar diversos ataques a una web o sistema.

22/29
 Protocolo HTTP

IX. Resumen

Dentro de esta unidad se ha explicado de forma general qué es el protocolo HTTP, su

importancia en la capa correspondiente del modelo OSI y como medio de transferencia de
datos entre el cliente y el servidor y cómo interpretar su codificación para poder obtener
información.

A su vez, es importante recordar que dentro del protocolo HTTP pueden identificarse cabeceras
donde se puede encontrar información muy relevante sobre el sitio web, como datos sobre el
tipo de contenido que se está transmitiendo y su codificación, datos de la consulta que ha
realizado la petición, etc.

Finalmente, toda esta información ayudará a analizar las diferentes vulnerabilidades que se
pueden encontrar dentro del sitio web según la clasificación OWASP Top 10; por ejemplo, una
inyección SQL, un XSS o un XXE.

X. Lecturas y enlaces recomendados

Lectura. Hypertext Transfer Protocol Version 2 (HTTP/2)

Belshe et al. Hypertext Transfer Protocol Version 2 (HTTP/2). Tools; 2015.

Lectura. “OWASP Top 10 - 2017 Los diez riesgos más críticos en Aplicaciones Web”

The OWASP Foundation. “OWASP Top 10 - 2017 Los diez riesgos más críticos en Aplicacione
s Web”; 2017.

Enlace. Rfc-editor

http://www.rfc-editor.org/rfc/rfcXXXX.txt (siendo XXXX el número de RFC indicado).

23/29
 Protocolo HTTP

Ejercicios

Caso práctico

Se pide

Uso de Burp interceptando petición a IMF

Mediante la instalación y la configuración de la herramienta Burp Suite se realizará la interceptación y la

modificación de una petición HTTP.

Se debe comprobar cómo es posible modificar la petición para que muestre otro resultado si se realiza una
búsqueda en un buscador común, como Google.

Solución
Descargar la herramienta desde su página web oficial: PortSwigger.
Instalar la herramienta para entorno Windows o Linux (también está disponible la versión portable en JAR).
Una vez instalada, arrancar la herramienta de forma que quede configurada como un proyecto temporal y
con las configuraciones por defecto.

24/29
 Protocolo HTTP

Figura 1. Configuración de la herramienta Burp Suite.

Figura 1. Configuración de la herramienta Burp Suite.

Fuente: elaboración propia.

Deshabilitar el intercept dentro de la pestaña Proxy para que no pare las comunicaciones continuamente.
Configurar el navegador web para habilitar la navegación a través de un proxy gestionado en localhost y en
el puerto 8080, que es donde se despliega por defecto la herramienta.

25/29
 Protocolo HTTP

Figura 2. Configuración del navegador web.

Figura 2. Configuración del navegador web.

Fuente: elaboración propia.

Figura 3. Configuración manual, proxy.

Figura 3. Configuración manual, proxy.

Fuente: elaboración propia.

26/29
 Protocolo HTTP

Tras configurar el navegador para hacer uso del proxy, se debe instalar el certificado de Burp accediendo a
la dirección <http://burp> e instalando el certificado descargado en el navegador.

Figura 4. Instalación del certificado Burp.

Figura 4. Instalación del certificado Burp.

Fuente: elaboración propia.

Con esto ya estaría configurada la aplicación Burp Suite para interceptar las comunicaciones HTTP que
realice el navegador. En la pestaña Target se puede comprobar cómo van quedando registradas todas las
peticiones realizadas por el navegador.
Para parar una petición concreta se debe activar de nuevo el intercept de la pestaña Proxy, lo que hará que
todas las peticiones queden paradas en una cola FIFO dentro de la herramienta. Se irán enviando a medida
que se presione el botón Forward.

Figura 5. Activación del Intercept

Figura 5. Activación del Intercept

Fuente: elaboración propia.

El texto resaltado en amarillo se corresponde con la búsqueda realizada en el navegador.

27/29
 Protocolo HTTP

Recursos

Enlaces de Interés
Hypertext Transfer Protocol Version 2 (HTTP/2).
https://tools.ietf.org/html/rfc7540

OWASP Top 10 - 2017 Los diez riesgos más críticos en Aplicaciones Web
https://wiki.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf

Rfc-editor
http://www.rfc-editor.org/rfc/rfcXXXX.txt

portswigger
https://portswigger.net/burp/releases/professional-community-2021-2-1?requestededition=community

Bibliografía
Baca Urbina, G. Introducción a la seguridad informática. México D.F: Grupo Editorial Patria. 2016.:
Berners-Lee, T. Request For Comments: Hypertext Markup Language 2.0. En: RFC-Editor. 1995.
[En línea] URL disponible en: https://www.rfc-editor.org/rfc/rfc1866.txt:
Berners-Lee, T. Request For Comments: Hypertransfer Protocol HTTP/1.0. En: RFC-Editor. 1996.
[En línea] URL disponible en: https://www.rfc-editor.org/rfc/rfc1945.txt:
Burp Suite. Application Security Testing Software. PortSwigger. s. f. [En línea] URL disponible en:
https://portswigger.net/burp:
Colaboradores de Wikipedia. Base64. Wikipedia, la enciclopedia libre. 2021. [En línea] URL
disponible en: https://es.wikipedia.org/wiki/Base64:
Colaboradores de Wikipedia. Modelo OSI. Wikipedia, la enciclopedia libre. 2021a. [En línea] URL
disponible en: https://es.wikipedia.org/wiki/Modelo_OSI:
Colaboradores de Wikipedia. Protocolo de transferencia de hipertexto. Wikipedia, la enciclopedia
libre. 2021b. [En línea] URL disponible en:
https://es.wikipedia.org/wiki/Protocolo_de_transferencia_de_hipertexto:
Freed, N. Request For Comments: Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Example. En: RFC-Editor. 1996. [En línea] URL disponible en:
https://www.rfc-editor.org/rfc/rfc2049.txt:
Freed, N. Request For Comments: Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures. En: RFC-Editor. 1996. [En línea] URL disponible en: https://www.rfc-
editor.org/rfc/rfc2048.txt:
Freed, N. Request For Comments: Multipurpose Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies. En: RFC-Editor. 1996. [En línea] URL disponible en: https://www.rfc-
editor.org/rfc/rfc2045.txt:
Freed, N. Request For Comments: Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types. En: RFC-Editor. 1996. [En línea] URL disponible en: https://www.rfc-
editor.org/rfc/rfc2046.txt:
Internet Assigned Numbers Authority. IANA. s. f. [En línea] URL disponible en:
https://www.iana.org/:
Moore, K. Request For Comments: Multipurpose Internet Mail Extensions (MIME) Part Three:
Message Header Extensions for Non-ASCII Text. En: RFC-Editor. 1996. [En línea] URL disponible
en: https://www.rfc-editor.org/rfc/rfc2047.txt:

28/29
 Protocolo HTTP

OWASP Foundation | Open Source Foundation for Application Security. OWASP. s. f. [En línea]
URL disponible en: https://owasp.org/:
Stallings, W. Effective Cybersecurity: A Guide to Using Best Practices and Standars. 2018.:
The ZAP Homepage. OWASP ZAP. s. f. [En línea] URL disponible en: https://www.zaproxy.org/:
Wu, C. H. Irwin, J. D. Introduction to Computer Networks and Cybersecurity. Boca Ratón: CRC
Press. 2016.:

Glosario.
CICLO DE VIDA DEL DESARROLLO DE LOS SISTEMAS (“SYSTEMS DEVELOPMENT LIFE
CYCLE”): Se trata del proceso que recorre un sistema de información dentro del desarrollo de software.

HTTP Headers: O “cabecera HTTP”. Se trata de un conjunto de datos que se envían al servidor o al cliente
dentro de una petición o respuesta HTTP. Estos datos pueden incluir información sobre el tipo de contenido,
cookies, los controles de caché, etcétera.

HTTP Status code: O “código de estado HTTP”. Se trata de mensajes que proporcionan información
sobre una respuesta HTTP. Normalmente están formados por tres cifras, de las cuales la primera especifica
un tipo de respuesta (hay cinco en total: información, respuesta correcta, redirección, error del cliente y error
del servidor).

MODELADO DE AMENAZAS: Proceso estructurado a través del cual se establecen los distintos niveles de
amenazas y su criticidad. Esta división de amenazas se suele aplicar al ciclo de vida del desarrollo de
software (SDLC).

TCP: transmission control protocol: Es un protocolo de transporte que permite el intercambio seguro de
datos gracias a sistemas como la autorización emisor-receptor o el acuse de recibo (o ACK).

URI: uniform resource identifiers: Es un identificador asignado a un recurso en la World Wide Web. Las
URL apuntan, en teoría, a un recurso único en la web.

29/29