Buscando la manera más segura de mostrar una dirección web o URL

Esta semana publicaba un artículo en el que explicaba los riesgos de un entorno basado en parches iterativos, a colación de cómo en nuestro afán de transformar ese Internet que en su día nació bajo el paradigma de la confianza (conectar académicos de X universidades) en algo como lo que es ahora (un ecosistema abierto a cualquier persona del mundo, tenga o no buenos objetivos), nos lleva, de facto, a asumir otros riesgos.

Y para muestra, un botón con lo que hemos ido sufriendo esta última década con el auge del SSL en la URL o direcciones web:

• HTTP: El protocolo base (por simplificarlo mucho) que nos está permitiendo que ahora mismo tú puedas estar leyendo este artículo publicado desde España, y alojado 24/7 en un servidor europeo.
• HTTPs: Puesto que HTTP se concibió en un principio como un protocolo para comunicarse entre iguales (en principio académicos de varias universidades estadounidenses), todo lo que se compartía se hacía en texto plano, es decir, abierto a que cualquier otro interesado pudiera verlo. Algo que parece perfecto para un entorno cerrado como el inicial de Internet, pero que ha demostrado ser profundamente inseguro para el Internet de la actualidad, en el que conviven tanto usuarios «buenos» como cibercriminales. Así que se le incluyó al HTTP un túnel SSL para que las comunicaciones, al menos mientras estuvieran en tránsito (desde que salen del dispositivo emisor y hasta que llegan al servidor o dispositivo receptor), estuvieran cifradas.
• HSTS: El mundo parecía muy bonito con el HTTPs, pero entonces nos dimos cuenta de que el HTTP sigue funcionando, y que de hecho es posible forzar la comunicación por HTTP pese a que la comunicación, a priori, se haga mediante el HTTPs. ¿La solución? Otro nuevo parche, llamado esta vez HTTP Strict Transport Protocol o HSTS, que como su propio nombre indica fuerza a que sí o sí la comunicación se haga por HTTPs… o de no ser posible, no se haga.
• HPKP: Otro momento dulce… hasta que nos dimos cuenta de que una comunicación con HSTS o HTTPs puede hacerse tanto hacia un servidor legítimo, como ilegítimo. Que, de hecho, el SSL solo asegura la privacidad de la comunicación, no su legitimidad. Y para solventarlo, otro parche, basado esta vez en el Certificate Pinning y el HTTP Public Key Pinning o HPKP por sus siglas, en el que ya no solo forzamos a que la comunicación se haga mediante HTTPs (HSTS, ya sabes), sino que además esa «carta» se tiene que enviar única y exclusivamente a este servidor. El mismo que tiene este certificado en particular.

En esta pieza me centraba por tanto en el apartado puramente técnico de la URL, y en esta otra quería centrar el tiro en el apartado puramente visual y comunicativo de una URL.

Pero antes empecemos por lo básico.

¿Qué es realmente una URL?

Para que nos entendamos, la URL o dirección web es un conjunto estandarizado de nombre más apellidos que nos permiten acceder a contenido específico compartido en la Red sin tener que recordar algo tan complejo como es una IP, compuesta por varios grupos de números en decimal o hexadecimal.

De esta manera, para acceder a mi página de servicios en vez de tener que recordar la IP de mi servidor (del tipo 87.324.324.123) y la ruta donde está ese archivo, simplemente vas al campo de direcciones web de tu navegador favorito y escribes pabloyglesias.com/servicios/.

Y aquí empieza la magia.

Por cómo tengo definido a nivel técnico las peticiones a esa dirección, el servidor se encarga de redirigir ese “pabloyglesias.com/servicios/” a “https://www.pabloyglesias.com/servicios-presencia-digital/”:

• “https://”: Esto nos sirve para alertar tanto al navegador como al servidor que la comunicación se tiene que hacer mediante el protocolo http (el estándar para acceder a recursos subidos a un servidor web) y además que esa comunicación debe hacerse cifrada de punto a punto (la “s” del “https”, que utiliza a su vez otro protocolo llamado SSL).
• “www”: Con esto definimos el uso de un estándar (el del World Wide Web) que en su día fue necesario, y que realmente ahora se mantiene más que nada por factores históricos. La web con el dominio principal y la extensión (es decir, pabloyglesias.com en nuestro caso) ya funciona. Pero además, siendo estrictos, ese “www” no deja de ser un subdominio, que se separa entre otros subdominios y del dominio principal siempre con un punto. Un tema en el que profundizaremos más adelante.
• “pabloyglesias.com”: aquí está el “nombre” de la página. Está formado en si por el dominio principal (pabloyglesias) y la extensión (.com), que de nuevo es otro estándar, que en este caso viene del diminutivo de company. Por cierto que las extensiones básicas, al menos hasta el surgimiento de las extensiones de alto nivel (.lol, .porn, .xxx, .shop…) siempre han tenido o 3 caracteres o 2, siendo estas últimas las que corresponden a países (.es para España, .eu para Europa, .mx para México…).
• “/servicios-presencia-digital/”: Sería el “apellido”, y define la ruta a la que el navegador debe llamar una vez está dentro del servidor. En este caso, una página web creada dinámicamente (el archivo como tal no existe, sino que se genera en base a unas consultas a la base de datos para cada usuario que pide acceso a esta página) con un CMS.

Hasta aquí todo correcto, ¿verdad?

Pues vamos a adentrarnos un poco más en la gestión de subdominios… y los problemas asociados a su abuso.

El paradigma de subdominios web y la seguridad

Ahora imagínate que en vez de usar “www”, uso otro subdominio que ya tenía de hace tiempo definido: “sectrip”.

De esta manera, la página “https://www.pabloyglesias.com/servicios-presencia-digital/” también puede ser accesible mediante “https://sectrip.pabloyglesias.com/servicios-presencia-digital/”.

Y es aquí donde empiezan los problemas, ya que igual que yo he creado el subdominio “sectrip”, podría haber creado el subdominio “google”, o el subdominio “facebook”, y quizás me interesaría jugar con el diseño de la URL completa y del propio diseño de la página web para engañar a los usuarios haciéndoles pensar que están accediendo a un servicio de Google, de Facebook, o de quien me de la gana.

Sencilla y llanamente porque al igual que los dominios requieren un registro previo que más o menos podemos considerar centralizado a nivel mundial (cada dominio, según la extensión que utilice, depende de uno o unos pocos organismos que certifican que el dominio “pabloyglesias.com” solo me pertenece a mi, que el de “google.es” solo le pertenece a Google…), los subdominios se pueden crear con total libertad, ya que están asociados a la identidad del dominio, y se espera que la gente entienda qué es un subdominio y qué es un dominio. Cosa que, a la vista de lo bien que funcionan los ataques de phishing, no está ocurriendo.

Que recalco: LOS SUBDOMINIOS NO DEFINEN LA IDENTIDAD DE UNA WEB. Son solo un mero añadido, pero no nos sirven para legitimar si estamos ante el servicio online adecuado o no.

Para colmo el problema se agrava en el momento en el que te das cuenta que ni siquiera la industria ha definido aún un estándar de cómo mostrar una URL.

Cada navegador hace lo que le da la real gana. De hecho por aquí puedes ver un ejemplo de cómo se mostraría la URL que he puesto de ejemplo según el navegador que usemos.

• Chrome: El navegador más utilizado pone en negrita tanto los subdominios como el dominio principal, extensión incluida, y oculta tanto el protocolo (https) como los www. Es decir, sectrip.pabloyglesias.com/servicios-presencia-digital/
• Firefox: Es el único que realmente hace las cosas bien, mostrando toda la URL y poniendo en negrita únicamente el dominio principal con la extensión. Es decir, https://sectrip.pabloyglesias.com/servicios-presencia-digital/
• Edge: Casi igual que Chrome a excepción que sí muestra toda la URL. Es decir, https://sectrip.pabloyglesias.com/servicios-presencia-digital/
• Safari: el navegador de Apple directamente oculta toda la ruta, mostrando solo los subdominios más el dominio y extensión en la barra, y complicando por tanto aún más la identificación de potenciales campañas de phishing. Es decir, sectrip.pabloyglesias.com.

En dispositivos móviles, por cierto, la mayoría han acordado debido a las limitaciones de espacio (y a sabiendas del riesgo que se está asumiendo) hacerlo igual que Safari.

Como decía solo Firefox gestiona adecuadamente la señalética del dominio, dándole importancia (las negritas) únicamente a aquello que define la legitimidad de un enlace: su dominio principal junto con su extensión. Y dejando en una tipografía normal el resto de elementos que forman esa URL.

De hecho Mozilla es la única que sabemos a ciencia cierta que gestiona la legitimidad de los dominios mediante una lista pública denominada Public Suffix (EN). En otros casos puede que lo consulten o no, pero no hay registro público que así lo confirme.

¿Cuál parece que puede ser el futuro de las URLs?

Pues te diría que es difícil saberlo, ya que entran en juego muchos intereses distintos.

Sin ir más lejos Chrome, el navegador con mayor porcentaje de usuarios a nivel mundial, depende de Google, y por ende, de un negocio que a su vez depende de las búsquedas y de la publicidad que se muestra en esas búsquedas.

Es más, desde Chrome 71 está disponible una función experimental llamada “Query in Omnibox” que de activarla se encarga de que cuando escribimos una búsqueda en la barra de direcciones de Chrome, la URL resultante no se muestre como hasta ahora, sino que en su lugar solo aparece el texto que buscamos.

Eso sí, aún es posible acceder a la URL si hacemos click derecho sobre la barra de dirección y luego en “Mostrar URL”.

Según Google esto se hace porque en efecto las URLs, por cómo están diseñadas hoy en día, no están ayudando nada. Y tienen parte de razón (EN). Pero de ahí a eliminarlas absolutamente de la ecuación me parece que es como intentar matar moscas a cañonazos, y que el ecosistema final sería aún más peligroso.

A mi personalmente me gusta bastante más la propuesta que ofrecían a título personal dos ingenieros de Google en el podcast HTTP 203, que lo puedes ver y oír por aquí:

Básicamente, el cambio consistiría en hacer que la barra de direcciones muestre a la izquierda la URL del dominio propietario (pabloyglesias.com), y a la derecha, en un color más grisáceo, se mostraría la URL completa.

Es decir, sería una especie de unión entre la propuesta de Safari y la de Firefox. Por un lado mostramos en un apartado no clicable el dominio principal y la extensión, e igualmente dejamos visible el resto de la URL ya editable al lado.

Ni molestamos al usuario ofuscando la URL y complicándole por tanto algo tan típico como es compartirla, y evitamos de paso que un juego de homografía o diseño de patrón oscuro confunda al usuario, pensando que está entrando en el servicio online de su banco cuando realmente lo está haciendo en una página de phishing.

En fin, que hay muchas propuestas en la mesa, y como decía parece que todavía no existe un consenso… en algo que realmente está sirviendo de caldo de cultivo para engañar a miles de usuarios día tras día.

________

Puedes ver más artículos de esta serie en #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital.

Y si el contenido que realizo te sirve para estar actualizado en tu día a día, piensa si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.