Seguridad web: Introducción a HTTP

HTTP es algo hermoso: un protocolo que ha existido durante más de 20 años sin muchos cambios.



Esta es la segunda parte de la serie de seguridad web: la primera parte fue Cómo funcionan los navegadores .

Como vimos en el artículo anterior, los navegadores interactúan con las aplicaciones web utilizando el protocolo HTTP, y esta es la razón principal por la que profundizamos en este tema. Si los usuarios ingresan la información de su tarjeta de crédito en el sitio web, y un atacante puede interceptar los datos antes de que lleguen al servidor, probablemente tendremos problemas.

Comprender cómo funciona HTTP, cómo podemos asegurar las comunicaciones entre clientes y servidores, y qué características de seguridad ofrece el protocolo es el primer paso para mejorar nuestra seguridad.

Sin embargo, cuando se habla de HTTP, siempre debemos distinguir entre semántica e implementación técnica, ya que estos son dos aspectos completamente diferentes de HTTP.

La diferencia clave entre ellos puede explicarse por una analogía muy simple: hace 20 años, las personas cuidaban a sus familiares de la misma manera que lo hacen ahora, a pesar de que la forma en que interactuaron ha cambiado significativamente. Es probable que nuestros padres tomen su automóvil y conduzcan hasta su hermana para ponerse al día y pasar un tiempo con su familia.

En cambio, en estos días, con mayor frecuencia envían mensajes a WhatsApp, hacen llamadas telefónicas o usan un grupo en Facebook, lo que anteriormente era imposible. Esto no significa que las personas se comuniquen o se preocupen más o menos, sino simplemente que su interacción ha cambiado.

HTTP no es diferente: la semántica del protocolo no ha cambiado mucho, mientras que la implementación técnica de la interacción de clientes y servidores se ha optimizado a lo largo de los años. Si observa la solicitud HTTP de 1996, será muy similar a la que vimos en el artículo anterior, aunque la forma en que estos paquetes pasan a través de la red es muy diferente.

Revisar

Como hemos visto, HTTP sigue un modelo de solicitud / respuesta cuando un cliente conectado a un servidor envía una solicitud y el servidor responde.

Un mensaje HTTP (solicitud o respuesta) consta de varias partes:

• "Primera línea" (primera línea)
• encabezados (encabezados de solicitud)
• cuerpo (cuerpo de solicitud)

En la solicitud, la primera línea indica el método utilizado por el cliente, la ruta al recurso que desea, así como la versión del protocolo que va a utilizar:

GET /players/lebron-james HTTP/1.1

En este caso, el cliente intenta obtener el recurso ( GET ) en /Players/Lebron-James través del protocolo versión 1.1 , nada complicado de entender.

Después de la primera línea, HTTP nos permite agregar metadatos al mensaje a través de encabezados que toman la forma de clave-valor, separados por dos puntos:

GET /players/lebron-james HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

Por ejemplo, en esta solicitud, el cliente agregó 3 encabezados adicionales a la solicitud: Host , Accept y Coolness .

¡Espera, Coolness ?!?!

Los encabezados no deben usar nombres específicos y reservados, pero generalmente se recomienda confiar en aquellos que están estandarizados en la especificación HTTP: cuanto más se desvíe de los estándares, menos será entendido por otro participante del intercambio.

Cache-Control es, por ejemplo, un encabezado utilizado para determinar si (y cómo) una respuesta es almacenable en caché: la mayoría de los proxies y los proxies inversos lo entienden siguiendo la especificación HTTP al pie de la letra. Si tuviera que cambiar el nombre del encabezado Cache-Control a Awesome-Cache-Control , los proxies no tendrían idea de cómo almacenar en caché la respuesta, ya que no están diseñados para cumplir con la especificación que acaba de inventar.

Sin embargo, a veces tiene sentido incluir un encabezado "personalizado" en el mensaje, ya que puede agregar metadatos que realmente no forman parte de la especificación HTTP: el servidor puede decidir incluir información técnica en su respuesta para que el cliente pueda ejecutar simultáneamente solicitudes y recibir información importante sobre estado del servidor que devuelve una respuesta:

...
X-Cpu-Usage: 40%
X-Memory-Available: 1%
...

Cuando se usan encabezados personalizados, siempre es preferible poner un prefijo con una clave delante de ellos para que no entren en conflicto con otros encabezados que pueden convertirse en estándar en el futuro: históricamente esto funcionó bien hasta que todos comenzaron a usar los prefijos X "no estándar", que a su vez se convirtió en la norma Los encabezados X-Forwarded-For y X-Forwarded-Proto son ejemplos de encabezados personalizados que son ampliamente utilizados y entendidos por los equilibradores de carga y proxies , incluso si no son parte del estándar HTTP .

Si necesita agregar su propio encabezado personalizado, ahora generalmente es mejor usar un prefijo propietario como Acme-Custom-Header o A-Custom-Header .

Después de los encabezados, la solicitud puede contener un cuerpo que está separado de los encabezados por una línea vacía:

POST /players/lebron-james/comments HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

Best Player Ever


Nuestra solicitud se completa: primera línea (información de ubicación y protocolo), encabezados y cuerpo. Tenga en cuenta que el cuerpo es completamente opcional y, en la mayoría de los casos, se usa solo cuando queremos enviar datos al servidor, por lo que el método POST se usa en el ejemplo anterior.

La respuesta no es muy diferente:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=3600

{"name": "Lebron James", "birthplace": "Akron, Ohio", ...}

La primera información que se envía en la respuesta es la versión del protocolo que utiliza, junto con el estado de esta respuesta. Los siguientes son los encabezados y, si es necesario, un salto de línea seguido por el cuerpo.

Como ya se mencionó, el protocolo se sometió a numerosas revisiones y con el tiempo se agregaron nuevas funciones (nuevos encabezados, códigos de estado, etc.), pero la estructura principal no ha cambiado mucho (primera línea, encabezados y cuerpo). Lo que realmente cambió es cómo los clientes y los servidores intercambian estos mensajes; echemos un vistazo más de cerca a esto.

HTTP vs HTTPS vs H2

Hubo 2 cambios semánticos significativos en HTTP / 1.0 : HTTP / 1.0 y HTTP / 1.1.

“¿Dónde están HTTPS y HTTP2 ?”, Preguntas.

HTTPS y HTTP2 (abreviado como H2) son cambios más técnicos porque introdujeron nuevas formas de entregar mensajes a través de Internet, sin afectar significativamente la semántica del protocolo.

HTTPS es una extensión HTTP "segura" e incluye el establecimiento de una clave secreta compartida entre el cliente y el servidor, asegurando que nos comuniquemos con la parte correcta y encriptemos los mensajes que intercambian una clave secreta compartida (más sobre esto más adelante). Mientras que HTTPS tenía como objetivo mejorar la seguridad del protocolo HTTP, H2 tenía como objetivo proporcionar alta velocidad.

H2 usa mensajes binarios en lugar de mensajes de texto, admite multiplexación, usa el algoritmo HPACK para comprimir encabezados ... ... En resumen, H2 mejora el rendimiento sobre HTTP / 1.1.

Los propietarios de sitios web se mostraron reacios a cambiar a HTTPS, ya que esto incluía soluciones adicionales entre el cliente y el servidor (como se mencionó, es necesario establecer una clave secreta compartida entre las dos partes), lo que ralentiza al usuario: con H2, que está cifrado de forma predeterminada, no hay más excusas dado que características como la multiplexación y la inserción del servidor lo hacen mejor que HTTP / 1.1 simple .

Https

HTTPS (HTTP Secure) permite a los clientes y servidores comunicarse de forma segura a través de TLS (Transport Layer Security), el sucesor de SSL (Secure Socket Layer).

El problema en el que se enfoca TLS es bastante simple y puede ilustrarse con una simple metáfora: su alma gemela lo llama a mitad del día cuando está en una reunión y le pide que le diga la contraseña de su cuenta bancaria en línea, ya que debe completar la banca transferir para garantizar el pago oportuno de la educación de su hijo. Es muy importante que lo informe ahora, de lo contrario correrá el riesgo de que su hijo sea expulsado de la escuela a la mañana siguiente.

Ahora te enfrentas a dos problemas:

• autenticando que realmente estás hablando con tu alma gemela, ya que puede ser alguien que finge ser ella
• cifrado : transmitir su contraseña para que sus colegas no puedan entenderla y anotarla

Que vas a hacer Este es exactamente el problema que HTTPS está tratando de resolver.

Para verificar con quién está hablando, HTTPS utiliza certificados de clave pública (certificados de clave pública), que no son más que certificados que indican la identidad de un servidor en particular: cuando se conecta a través de HTTPS a una dirección IP, el servidor detrás de esa dirección le presenta Su certificado es para que usted pruebe su identidad. Volviendo a nuestra analogía, puede pedirle a su alma gemela que diga su número de seguro social. Tan pronto como verifique que el número es correcto, obtendrá un nivel adicional de confianza.

Sin embargo, esto no impide que los "atacantes" descubran el número de seguro social de la víctima, roban el teléfono inteligente de su alma gemela y lo llaman. ¿Cómo verificamos la identidad de la persona que llama?

En lugar de pedirle directamente a su alma gemela que escriba su número de seguro social, llame a su madre (que vive al lado) y le pida que vaya a su departamento y asegúrese de que su otra mitad diga el número de seguro social. Esto agrega un nivel adicional de confianza, ya que no considera a su madre una amenaza y confía en ella para verificar la identidad de la persona que llama.

En términos de HTTPS, su madre se llama CA, abreviatura de Autoridad de certificación: el trabajo de una CA es verificar la identidad de un servidor en particular y emitir un certificado con su propia firma digital: esto significa que cuando me conecte a un dominio específico no recibiré un certificado generado por el propietario del dominio (el llamado autofirmado certificado ) y CA.

La tarea de la CA es verificar la autenticidad del dominio y emitir el certificado en consecuencia: cuando "ordena" un certificado (generalmente llamado certificado SSL, aunque actualmente se usa TLS, ¡los nombres realmente se quedan!), La CA puede llamarlo o Solicite cambiar la configuración de DNS para asegurarse de que controla este dominio. Una vez que se complete el proceso de verificación, emitirá un certificado, que luego se puede instalar en los servidores web.

Luego, los clientes, como los navegadores, se conectarán a sus servidores y recibirán este certificado para que puedan verificar su autenticidad: los navegadores tienen una especie de "relación" con la CA, en el sentido de que realizan un seguimiento de la lista de dominios de confianza en la CA para asegurarse El certificado es verdaderamente confiable. Si el certificado no está firmado por una autoridad confiable, el navegador mostrará una gran advertencia informativa para los usuarios:



Estamos a medio camino de garantizar la comunicación entre usted y su otra mitad: ahora que hemos pasado la autenticación (verificación de la identidad de la persona que llama), debemos asegurarnos de que podamos comunicarnos de manera segura sin la intervención de otros en el proceso. Como mencioné, está justo en el medio de la reunión y necesita escribir su contraseña para la banca en línea. Necesita encontrar una manera de encriptar su comunicación para que solo usted y su alma gemela puedan entender su conversación.

Puede hacerlo estableciendo una clave secreta común entre los dos y cifrar los mensajes con esta clave: por ejemplo, puede usar la opción de cifrado César según la fecha de su boda.



Esto funcionará bien si ambas partes han establecido relaciones, como usted y su alma gemela, ya que pueden crear una clave basada en la memoria compartida que nadie conoce. Sin embargo, los navegadores y servidores no pueden usar el mismo mecanismo, ya que no se conocen de antemano.

En cambio, se utilizan variaciones del protocolo de intercambio de claves Diffie-Hellman , que aseguran que las partes sin conocimiento previo establezcan una clave secreta compartida y nadie más pueda "robarla". Esto incluye el uso de las matemáticas .



Una vez que se instala la clave secreta, el cliente y el servidor pueden comunicarse sin temor a que alguien pueda interceptar sus mensajes. Incluso si los atacantes hacen esto, no tendrán una clave secreta compartida necesaria para descifrar los mensajes.

Para obtener más información sobre HTTPS y Diffie-Hellman, recomendaría leer " Cómo HTTPS protege las conexiones " de Hartley Brody y " ¿Cómo funciona realmente HTTPS?" »Robert Heaton. Además, Nueve algoritmos que cambiaron el futuro tiene un capítulo sorprendente que explica el cifrado de clave pública, y lo recomiendo encarecidamente a los entusiastas de la informática interesados ​​en algoritmos originales.

Https en todas partes

¿Aún decide si debe admitir HTTPS en su sitio? Tengo malas noticias para usted: los navegadores han comenzado a proteger a los usuarios de sitios web que no son compatibles con HTTPS para "forzar" a los desarrolladores web a proporcionar capacidades de navegación totalmente encriptadas.

Siguiendo el lema " HTTPS en todas partes " , los navegadores comenzaron a oponerse a las conexiones no cifradas: Google fue el primer proveedor de navegadores en dar un plazo a los desarrolladores web al anunciar que a partir de Chrome 68 (julio de 2018), marcaría los sitios web HTTP como "inseguros" :



Aún más preocupante para los sitios web que no aprovechan HTTPS es el hecho de que tan pronto como un usuario escribe algo en una página web, la etiqueta "Inseguro" se vuelve roja: este paso debería alentar a los usuarios a pensar dos veces antes de intercambiar datos. con sitios web que no admiten HTTPS.



Compare esto con el aspecto de un sitio HTTPS con un certificado válido:



Teóricamente, un sitio web no debería ser seguro, pero en la práctica asusta a los usuarios, y con razón. En los días en que H2 no era una realidad, tendría sentido seguir con el tráfico HTTP simple no encriptado. Prácticamente no hay razón para esto en este momento. Únase al movimiento HTTPS Everywhere y ayude a hacer de Internet un lugar más seguro para navegar .

OBTENER vs POSTAR

Como vimos anteriormente, una solicitud HTTP comienza con una especie de "primera línea":

En primer lugar, el cliente le dice al servidor qué métodos utiliza para ejecutar la solicitud: los métodos HTTP básicos incluyen GET, POST, PUT DELETE, pero la lista puede continuar con métodos menos comunes (pero aún estándar), como TRACE, OPTIONS o HEAD

Teóricamente, ningún método es más seguro que otros; En la práctica, no todo es tan simple.

Las solicitudes GET generalmente no contienen un cuerpo, por lo que los parámetros se incluyen en la URL (por ejemplo, www.example.com/articles?article_id=1 ), mientras que las solicitudes POST se usan generalmente para enviar ("publicar") datos que se incluyen en el cuerpo. Otra diferencia son los efectos secundarios que tienen estos métodos: GET es un método idempotente, lo que significa que no importa cuántas solicitudes envíe, no cambiará el estado del servidor web. En cambio, POST no POST idempotente: por cada solicitud que envíe, puede cambiar el estado del servidor (piense, por ejemplo, en realizar un nuevo pago; ahora probablemente comprenda por qué los sitios le piden que no actualice la página al completar una transacción).

Para ilustrar la importante diferencia entre estos métodos, debemos echar un vistazo a los registros del servidor web con los que ya puede estar familiarizado:

192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:39:47 +0000] "GET /?token=1234 HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:40:47 +0000] "GET / HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:41:34 +0000] "PUT /users HTTP/1.1" 201 23 "http://example.local/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201

Como puede ver, los servidores web registran la ruta de solicitud: esto significa que si incluye datos confidenciales en su URL, el servidor web los omitirá y almacenará en algún lugar de sus registros; sus datos confidenciales estarán en algún lugar texto plano, que debemos evitar por completo. Imagine que un atacante podría obtener acceso a uno de sus archivos de registro antiguos , que puede contener información de tarjeta de crédito, tokens de acceso para sus servicios privados, etc., esto será un completo desastre.

Los servidores web no registran encabezados y cuerpos HTTP, porque los datos almacenados serán demasiado voluminosos, por lo que generalmente es más seguro enviar información a través del cuerpo de la solicitud en lugar de la URL. A partir de aquí, podemos deducir que POST (y métodos similares no idempotentes) es más seguro que GET , incluso si depende más de cómo se envían los datos utilizando un método determinado, y no del hecho de que un método particular es esencialmente más seguro que otros: Si incluyó información confidencial en el cuerpo de la solicitud GET , no tendría más problemas que usar POST , incluso si dicho enfoque se considerara inusual.

Creemos en los encabezados HTTP

En este artículo, analizamos HTTP, su evolución y cómo su extensión segura combina autenticación y cifrado para permitir que los clientes y servidores se comuniquen a través de un canal seguro: esto no es todo lo que HTTP tiene para ofrecer en términos de seguridad.

---

La traducción fue respaldada por EDISON Software , una compañía de seguridad profesional, y también está desarrollando sistemas electrónicos de verificación médica .