Pasar al contenido principal

Navegación segura y la analogía de la fiesta de cumpleaños

Al navegar por Internet la gente suele suponer que sólo hay dos partes involucradas: la persona que navega y el sitio que visita. Sin embargo, la realidad es mucho más compleja e implica muchas cuestiones relacionadas con la seguridad que la mayoría de la gente pasa por alto simplemente porque no son conscientes de ellos

Cuando se navega por Internet, hay numerosos actores que pueden potencialmente acceder al ordenador usado para navegar a través del propio navegador. Aunque los navegadores hacen un muy buen trabajo protegiendo a los usuarios de ataques maliciosos, no es una tarea en absoluto fácil. Para mejorar la seguridad, el equipo de desarrollo de un sitio web pueden ayudar al navegador en la mejora de la seguridad. Para ello, un sitio web puede indicar al navegador qué acciones se podrían querer realizar en el sitio web, evitando así cualquier funcionalidad potencialmente dañina que no sea necesaria para que el sitio funcione correctamente, cerrando de esta forma posibles vectores de ataque. Las cabeceras de seguridad HTTP o HTTP security headers hacen precisamente esto.

Pero no nos liemos con la jerga técnica y veamos este concepto con un ejemplo práctico.

Una fiesta de cumpleaños

Se acerca tu cumpleaños y quieres organizar un fiestón en casa. Por fiestón me refiero a una fiesta con todas letras: comida y bebida de sobra, música en directo, juegos varios relacionados con el deporte, un DJ acorde a la música que te gusta, mucha decoración especial y hasta un mago que vaya de grupo en grupo sorprendiendo con sus trucos.

Como no vas a aprender a tocar la guitarra para entretener a los invitados, ni a convertirte en DJ o preparar tú los cientos de canapés y tortillas, decides delegar estas tareas en profesionales del ramo.

En primer lugar, contratas a un organizador de fiestas de cumpleaños. Conoce a quien puede encargarse de la decoración de la fiesta,  puede encontrar una buena banda de rock para hacer karaoke en vivo (puedo certificar que una banda de karaoke en vivo es algo muy muy divertido) y sabe a quien llamar para preparar y servir la comida y la bebida. Así, lo único que tienes que hacer es relajarte (o no) y disfrutar de la fiesta.

La fiesta se celebrará en el jardín y en las habitaciones de la planta baja que dan al jardín donde se colocará la comida y las bebidas. Cuando llega el día, el organizador lo tiene todo bajo control. El personal del catering llega pronto para preparar lo que se servirá. Disponen las habitaciones, organizan las mesas exteriores y empiezan a cocinar algunos platos que servirán después. Necesitan acceso a agua y  a los baños porque, bueno, son humanos. El DJ llega más tarde y necesita acceso a una fuente de alimentación. El grupo de karaoke llega cuando la fiesta está en ya empezada y necesita una habitación discreta para cambiarse de ropa porque son un show absoluto. Por último, el mago quiere un espacio tranquilo para prepararse para la actuación, estirando y calentando las manos durante una hora antes para poder hacer su magia con total confianza.

Image
A birthday party in a garden with robots helping guests
Una imagen de una fiesta de cumpleaños muy rara con robots hecha por otro robot (una IA)

Son muchas peticiones a satisfacer y muchas personas por tu casa. Sin embargo, no tienes que preocuparte de nada porque vives en el futuro y tu casa está atendida por robots: un robot cocinero para las tareas de la cocina, otros robots para ayudar con la decoración o la preparación en el jardín, y más robots dentro de casa para buscar un enchufe adecuado para el DJ: una servicial cuadrilla de sirvientes automatizados.

Además, el organizador está ahí para atender cualquier petición de quienes harán que tu fiesta sea memorable, comandando a los robots para resolver cualquier necesidad que surja.

Pero... ¿son todas estas personas de fiar? ¿Y si alguien pide a los robots que le dejen entrar en una habitación privada «para añadir algo de decoración»? ¿O solicita un objeto valioso porque «me han pedido ponerlo en el jardín»? ¿O qué pasa si alguien curiosea información personal en un cajón de tu escritorio o husmea por tu casa? Seguro que confías en el organizador de la fiesta de cumpleaños, y  desde luego confías en tus robots, pero... ¿pueden estar seguros de que todos los demás hacen sólo lo que deben por la fiesta? Puede que alguien del personal tenga una idea diferente. O que alguien haya conseguido hacerse pasar por parte del personal pero no lo sea. ¿Cómo puedes asegurarte de que tu casa esté segura y al mismo tiempo permitir que el personal legítimo haga su trabajo sin impedimentos?

Bueno, pues esto es exactamente lo que ocurre cuando navegas por Internet. Tu casa es como tu ordenador, con todos los datos personales y sensibles a los que puede acceder, incluidos correos electrónicos, archivos personales, fotos, mensajes de redes sociales e información bancaria. Los robots son como tu navegador, el organizador de fiestas de cumpleaños es el sitio web por el que navegas, y todo el personal de la fiesta son los distintos recursos de terceros que intervienen en la presentación de la web (anuncios, vídeos de YouTube, herramientas de medición de audiencia, librerías externas utilizadas para mostrar carruseles de imágenes, etc.). Y aunque puedes confiar en tu navegador, aunque normalmente puedes confiar en el sitio que visitas (al menos en la mayoría de los sitios que visita la gente), y más o menos puedes confiar en las librerías externas, lo cierto es que cada vez que visitas un sitio web hay un pequeño festival de gente haciendo cosas dentro de tu móvil u ordenador.

La fiesta de una petición a una página web

Cuando accedes a una página web, el navegador se conecta a un servidor y le pide el contenido de la página. El navegador son los robots de tu casa: lee el contenido de la página web y sigue las instrucciones que allí se indican: mostrar un título determinado, colocar una foto grande en la parte superior, poner algo de texto debajo, etcétera. Estas instrucciones proceden del sitio web, pero al igual que el organizador de fiestas de cumpleaños, la mayoría de los sitios dependen de otros para completar la tarea de mostrar la web. Por ejemplo, los anuncios son normalmente gestionados por organizaciones externas, que tienen que cargar sus scripts en la web para gestionar el contenido que se presenta al usuario. Muchas veces, el navegador también carga el software de medición de audiencia siguiendo las instrucciones del sitio. A menudo, este código externo se carga sin que el sitio sea plenamente consciente del contenido o lo haya auditado de alguna forma. Al igual que el organizador de cumpleaños, delegan en otros para poder hacer todo.

Todos estos recursos de terceros se cargan en tu navegador y éste ejecuta alegremente sus instrucciones.

Se puede pensar que esto no es para tanto. ¿Qué hay de malo? ¿Cuál es el peor escenario posible? Bueno, el principal problema es que tu navegador es capaz de hacer todo tipo de cosas. Puede acceder al contenido de los discos de tu ordenador, a menudo conoce tus contraseñas, tiene acceso a sitios personales con mucha de tu información íntima que podría ser utilizada contra ti por actores malintencionados, e incluso acceder a tu micrófono y webcam, porque los sitios que ofrecen videollamadas necesitan acceder a estas funciones y por tanto esas funcionalidades las ofrece el navegador.

El navegador es tu aliado y los sitios web pueden ayudar

Que no cunda el pánico. Al igual que los robots de la fiesta siguen instrucciones para que todo funcione correctamente, tu navegador está diseñado no sólo para mostrar las páginas web según las instrucciones del sitio, sino también para aplicar medidas de seguridad de protección ante ataques. Esa es la razón por la que, por ejemplo, el navegador siempre pide permiso antes de usar el micrófono. Debes autorizar a un sitio a utilizar el micrófono antes de que pueda grabar cualquier sonido, y menos mal.

Sin embargo, un actor malicioso puede engañarte para que aceptes el acceso al micrófono. Y es aquí es donde el propio sitio web puede intervenir para ayudar. Un sitio web puede informar al navegador sobre sus necesidades y bloquear cualquier funcionalidad que no sea necesaria para su correcto funcionamiento. Por ejemplo, un sitio puede decirle al navegador que nunca necesitará utilizar el micrófono. El navegador registra esta información y, si más tarde, algún script de terceros incluido en el sitio web intenta activar el micrófono, el navegador denegará la petición. Ni siquiera se molesta en preguntarte, porque el sitio ya ha dicho que los micrófonos no son necesarios para nada y eso es inamovible.

Volviendo a la analogía de la fiesta de cumpleaños, esto es como si el organizador de fiestas de cumpleaños dijera a los robots que nadie va necesitar subir en ningún caso a la planta superior. Así, tus robots no dejarán subir a nadie al piso superior, por muchas elaboradas excusas  que cualquier listillo malintencionado se inventé. Y punto.

Cómo informan los sitos web al navegador

Los sitios web pueden utilizar las cabeceras HTTP para restringir las acciones disponibles del navegador con el objetivo de aumentar la seguridad de sus visitantes. Digamos que junto con el contenido a mostrar, los sitios web envían instrucciones como «no utilices el micrófono», «no permitas que scripts de terceros utilicen las credenciales de este sitio» o «utiliza siempre conexiones seguras».

Esto no es una tarea fácil, ya los responsables del sitio web (o más bien el equipo de desarrollo) deben analizar el sitio y utilizar estas cabeceras HTTP para eliminar todas las funcionalidades que la web no necesita.

Se debe determinar si el sitio debe cargar scripts de proveedores externos, como vídeos de YouTube o contenidos más especializados, como gráficos o informes financieros. Por ejemplo, si un sitio muestra vídeos de una fuente externa, debe permitir la ejecución de scripts de sitios de terceros, o los vídeos no se reproducirán.

Otra cuestión es si el sitio puede ser mostrado dentro de otros sitios web, lo que se dice incrustado. Esto es lo que ocurre cuando un sitio muestra mensajes de redes sociales, como al incluir contenido de Instagram o Twitter. Aunque esto puede no parecer un gran problema, podemos pensar en el sitio web de un banco. Si el sitio del banco puede mostrarse dentro de otro sitio web, los atacantes podrían engañar a los usuarios haciéndoles creer que están utilizando la aplicación legítima del banco cuando no es así. Podrían estar en un sitio hostil que accedería a información tan sensible como la información bancaria.

Y no sólo los visitantes corren riesgo. Los editores de contenido de un sitio web -las personas que crean y editan las distintas páginas que ven los visitantes- pueden ser blanco de ataques para robar sus credenciales o alterar el contenido del sitio web de formas sutiles que no se notan fácilmente, como añadir enlaces invisibles a sitios de cuestionables para beneficiarse de la reputación SEO del sitio que atacan (y dañando esa reputación en el proceso).

Todas estas medidas de seguridad pueden aplicarse de forma fácil y directa, y algo insegura, o de forma más segura y precisa. Por ejemplo, un sitio que utilice vídeos de YouTube podría simplemente permitir todos los scripts de terceros, y los vídeos funcionarían. Sin embargo, esto también permitiría la ejecución de cualquier script malicioso de terceros. En este caso, lo más seguro sería autorizar sólo los scripts de YouTube y nada más. En este ejemplo se usaría la cabecera HTTP llamada Content-Security-Policy, que permite a los sitios declarar desde qué otros sitios se permite cargar JavaScript.

Visualizando los recursos de terceros cargados por un sitio web

Es interesante analizar todos los recursos de terceros que carga un sitio. La herramienta en línea Request Map hace exactamente eso: muestra un gráfico con esos recursos de terceros que intervienen en la renderización de una página web. A menudo sorprende el número de actores que intervienen en una simple petición. Por ejemplo, aquí tenemos el gráfico de terceros de weather.com:

Image
A graph that displays a central node that is weather.com surrounded and connected to several bubbles representing the third parties.

El círculo azul representa el sitio weather.com. Aparte de algunos datos servidos por subdominios de weather.com, todos los demás círculos representan recursos de terceros. Los círculos rojos están relacionados con la publicidad, los morados no se sabe (lo que significa que la herramienta no puede determinar el propósito exacto de esos recursos), el círculo verde sirve scripts de Adobe, y el amarillo es una librería JavaScript.

Por otro lado, este es el gráfico de la Wikipedia en español, y como puede verse, no hay recursos de terceros implicados porque todos los círculos mostrados son de la propia Wikipedia:

Image
A graph displaying a central circle and several other related circles, all owned by Wikipedia.

Por desgracia, es casi imposible servir un sitio tan limpio como Wikipedia. La mayoría de los sitios requieren ciertas herramientas relacionadas con el marketing, la publicidad y la medición de la audiencia, y habitualmente incluyen imágenes y vídeos externos u otro tipo de datos que requieren algún tipo de script.

Este es, por ejemplo, un gráfico con los recursos cargados por webs de cuatro clientes de Metadrop:

Image
Four graphs displaying the third party resources used by websites from Metadrop's clients

En estos casos, nuestro trabajo consiste en garantizar que esos sitios informen al navegador sobre qué requisitos exactos necesita el sitio web del cliente y eliminen cualquier funcionalidad adicional no utilizada.

Comprobando las cabeceras HTTP de un sitio web

Hay varias herramientas disponibles para comprobar si las cabeceras HTTP de un sitio están configuradas correctamente y lo permisivas que son. La primera herramienta que se me ocurre es HTTP Headers Analyzer de Dries Buytaert, el creador de Drupal. Es sencilla sin ser demasiado simplista; proporciona información detallada sobre cada punto que comprueba, es rápida y va directa al grano. Usando esta herramienta, he aprendido mucho intentando llevar la puntuación a su máximo: 10 puntos. Tengo previsto publicar un artículo con los detalles técnicos, pero de momento este artículo voy a mantenerlo libre de cuestiones muy técnicas.

Otra buena herramienta es el HTTP Observatory Report ofrecido por Mozilla. Parece más estricto que el analizador de Dries y probablemente es imposible de conseguir una puntuación perfecta para muchos sitios, ya que requiere algunas configuraciones que son simplemente inviables de implementar si el sitio ofrece ciertas funcionalidades.

Por último, me gustaría mencionar Security Headers, otra herramienta que analiza las cabeceras HTTP de un sitio. Es muy clara y proporciona información sobre la puntuación y los aspectos concretos que comprueba.

Bonus: ¡la GDPR funciona!

Me gustaría concluir con un algo de lo que me di cuenta durante la preparación de este artículo: parece que la GDPR (Reglamento General de Protección de Datos) es eficaz a la hora de proteger a los usuarios. ¿Por qué digo esto? Si se comparan los recursos de terceros cargados por el mismo sitio cuando se accede desde Estados Unidos frente a la Unión Europea, la diferencia es bastante notable. El siguiente gráfico ilustra esta comparación para weather.com:

Image
Weather.com loads much more resources when visited from USA

El cuadrado rojo de la derecha representa más o menos el mismo conjunto de recursos que el gráfico de la izquierda. Esto significa que cuando se accede a weather.com desde EE.UU., se pide al navegador que cargue un número significativamente mayor de recursos de terceros. Aunque no puedo estar totalmente seguro, creo que esto se debe al GDPR, una ley de la Unión Europea que se aplica a todos los ciudadanos que están dentro del territorio de la UE. En consecuencia, los sitios web pueden aplicar reglas diferentes cuando detectan una dirección IP procedente de Europa para cargar más o menos recursos, respetando la GDPR.

Conclusión

Internet puede ser un lugar peligroso, pero los navegadores hacen un buen trabajo protegiendo a los usuarios. Sin embargo, los sitios web pueden mejorar esta protección de base proporcionando a los navegadores información sobre cómo aumentar la seguridad sin comprometer la funcionalidad. Los actores maliciosos son muy hábiles, y minimizar la superficie de ataque es una forma eficaz de evitar sorpresas desagradables que pueden afectar a un sitio de varias maneras, incluyendo SEO, reputación, costes y éxito en general.

Mejorar la seguridad a través de las cabeceras HTTP ayuda significativamente a reducir esta superficie de ataque eliminando todas las funcionalidades que el sitio no necesita, cerrando así posibles vectores de ataque.

En Metadrop vemos el desarrollo de un sitio web como un trabajo integral que cubre no sólo los aspectos visibles para el propietario y sus visitantes, sino también elementos menos visibles como la seguridad. Por eso hemos incorporado todo lo que hemos aprendido sobre las cabeceras HTTP en la batería de pruebas de nuestros proyectos. Si crees que tu sitio podría beneficiarse de estos conocimientos, ponte en contacto con nosotros y hablemos de cómo conseguirlo.

Image
RIcardo Sanz Ante

Ricardo Sanz

CTO