JASoft.org

El blog de José Manuel Alarcón Aguín. Programación web y mucho más...

MENÚ - JASoft: JM Alarcón

La extraña cabecera "Upgrade-Insecure-Requests" y cómo gestionarla en el servidor

Como todo programador web que se precie, más temprano que tarde acabarás por utilizar el inspector de tráfico de Google Chrome o cualquier otro analizador de protocolos como por ejemplo el magnífico Fiddler. Estas utilidades sirven para inspeccionar todo el tráfico web saliente y poder ver exactamente qué datos se intercambian, poder modificar peticiones y respuestas, etc... lo cual es de gran ayuda para depurar las aplicaciones Web.

Si inspeccionas tráfico generado por Google Chrome verás una cabecera muy rara en casi todas las peticiones dirigidas a través de HTTP:

Upgrade-Insecure-Requests

¿Qué es esta cabecera "Upgrade-Insecure-Requests"?

Se trata de la implementación en Chrome de la especificación del mismo nombre creada por el World Wide Web Consortium (W3C). Se trata de un mecanismo que trata de generar conexiones más seguras para los usuarios.

Así, cuando un navegador u otro cliente Web se conecta a un canal que no considera suficientemente seguro, puede solicitar al servidor un cambio a un protocolo más seguro antes de lanzar la verdadera petición y que por lo tanto no se transmita información de manera no-segura.

Para ello envía la petición con una cabecera especial, que es la que hemos visto en la figura anterior, llamada Upgrade-Insecure-Requests.

Según dice la especificación:

The Upgrade-Insecure-Requests HTTP request header field sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the upgrade-insecure-requests directive in order to make that preference as seamless as possible to provide.

Si el servidor está de acuerdo con esto y puede atender la petición con un protocolo más seguro (normalmente HTTPS, claro), lo que hará será contestar con una redirección al mismo recurso, pero usando el protocolo seguro en lugar del inseguro.

O sea, el proceso es:

  1. El navegador solicita un recurso web a través de HTTP (no-securizado), por ejemplo, http://www.miservidor.com/carpeta/recurso/ e incluye una cabecera "Upgrade-Insecure-Requests" con valor 1 para indicar que prefiere un protocolo seguro
  2. El servidor al ver esa cabecera, si tiene disponibilidad de usar un protocolo seguro (SSL/TSL en este caso), debería redirigir al navegador hacia una versión segura de la URL (por ejemplo https://www.miservidor.com/carpeta/recurso/), así que devuelve una cabecera de redirección (con estatus 307 de movido temporalmente)
  3. El navegador se dirige a la nueva URL segura y continua con la navegación.

El esquema del tráfico sería algo similar a esto:

El servidor solicita la página a través de HTTP tal y como le indica el usuario, pero incluye la cabecera de subir el nivel de seguridad:

GET /Carpeta/Recurso HTTP/1.1
Host: www.miservidor.com
Upgrade-Insecure-Requests: 1

El servidor recibe la petición y si es capaz de entender la cabecera, en lugar de devolver el recurso lo que hace es devolver un código de estado 307 y redirige al navegador a la versión segura del recurso, en este caso la misma dirección pero con HTTPS:

HTTP/1.1 307 Moved Temporarily
Location: https://www.miservidor.com/Carpeta/Recurso
Vary: Upgrade-Insecure-Requests

Además, y esto es importante, incluye una cabecera de tipo "Vary" indicando el motivo de la variación (que es la cabecera anterior) para evitar que algún proxy intermedio pueda servir la página desde una caché en lugar de solicitarla ala nueva dirección.

No es obligatorio que el servidor responda de esta manera y genere una versión segura del recurso, pero sí que es recomendable y seguramente a medio/largo plazo será muy recomendable, ya que basta que Google decida que los servidores que no lo hagan bajen el ranking en las búsquedas, para que todo el mundo deba hacerlo. Además, realmente la especificación dice claramente que el servidor debería responder de esta manera.

Hoy por hoy no ocurre nada si no lo haces, pero Chrome lo hace por defecto en todas las peticiones :-S

Conseguir que el servidor se responda a esta cabecera es relativamente fácil. En un posterior post explicaré cómo conseguirlo con Internet Information Server.

Nota de interés: En la versión 44 de Chrome que salió en verano de 2015, en lugar de utilizar esta cabecera usaron simplemente una llamda "HTTPS" para indicar que prefieren una conexión segura. El problema es que, de repente, solo por ese pequeño cambio miles de sitios web empezaron a romper por todo Internet. En especial sitios con Wordpress y software similar de este tipo hecho con PHP. Solo WooCommerce está en cerca de un millón de sitios web, y rompía con Chrome por culpa de esto. El motivo es que la mayor parte del software escrito con PHP interpreta esa variable de servidor ($_SERVER['HTTPS'];) como que la petición se está ejecutando a través de un protocolo seguro, cuando no era el caso, y las aplicaciones rompían. Sacaron un parche en unos días y en la siguiente versión 45 lo corrigieron y lo cambiaron por esta cabecera propia de la especificación del W3C.

¡Espero que te sirva de ayuda!

José Manuel Alarcón José Manuel Alarcón
Fundador de campusMVP.es, el proyecto de referencia en formación on-line para programadores en lengua española. Autor de varios libros y cientos de artículos. Galardonado como MVP de Microsoft desde 2004. Gallego de Vigo, amante de la ciencia y la tecnología, la música y la lectura. Ayudando a la gente en Internet desde 1996.
Descarga GRATIS mi último libro (no técnico): "Tres Monos, Diez Minutos".
Banner

Comentarios (3) -

Spain nomelocremix

Como siempre interesante articulo, sigue así, da gusto. Alguno (que rima con alguno) debería tomar nota y dejar de darnos el coñazo con lo primero que se le viene a la cabeza, solamente por el hecho de publicar por publicar

Responder

Spain José Manuel Alarcón

Gracias, me alegro de que te interese. Muchas veces son solo cosas que voy aprendiendo o investigando porque no las conocía (como en este caso) y las reflejo aquí casi como archivo y para que le valgan a alguien.

Me dejas mosqueado con lo del "alguno" ¿quién será? Si quieres mándame un privado desde el formulario de contacto y me lo cuentas ;-)

De todos modos, cualquiera que se anime a escribir cosas propias, que no sean copias, en un blog público siempre merece todos los respetos pues siempre lleva tiempo y esfuerzo (www.jasoft.org/.../...y-cuanto-cuesta-crearlo.aspx) y lo que no le sirve a unos le sirve a otros (siempre hay público). Yo por ejemplo suelo escribir cosas bastante básicas aquí porque con los años es lo que he visto que ayuda más a la gente, pero a algunos no les gusta, así que... nunca se sabe,

Saludos.

Responder

Muy bueno sin duda. Se agradece.

(quién será alguno, :-) )

Desde mi ignorancia, y IMHO todo ayuda, lo básico para iniciarse, y también más elaborado  y en detalle muchísimo.

Artículos-Posts muy completos de Codeproject dan una visión muy profunda y aclaran las dudas, y artículos en algunos blogs son siempre una referencia.


El tener proyectos para mirar y tomar como referencia, no te asegura la adopción de buenas prácticas para el tuyo, y te explico por qué: Los proyectos de referencia son diferentes entre sí, y todos diferentes al tuyo..



En mi experiencia, las buenas prácticas son aplicadas hasta que.... no se puede o no conviene hacerlo. Y en todo proyecto vas a encontrar varias de éstas situaciones.



Pero, retrocedamos un par de casilleros y entendamos para qué quiero tener buenas prácticas. En general, son para que el desarrollo y mantenimiento de aplicaiciones sea lo menos caótico (y caro).



Ahora, de nuevo en la salida, y buscando ese objetivo, te cuento que un patron que pude ver en mas de 10 empresas en las que trabajé es el siguiente: Mientras mas cultura de desarrollo hay, mas fácil se hacen las cosas. Y por cultura de desarrollo entiendase convenciones



Quién se encarga de evangelizer en la cultura? Un arquitecto de software, un team leader, la de tetas mas grandes o el que la tenga mas chica. No importa, siempre que sea alguien, Ese alguien se encarga de enseñar cómo hacer las cosas... de fijar sus buenas prácticas. Luego de un tiempo, todo el euipo hace las cosas de esa forma y ese alguien sigue enseñando a los nuevos que vienen.



Entonces vas a poder tomar los proyectos de referencia, google, o cualquier fuente, y adecuarla a tu manera de trabajo.



Actualmente estoy en una empresa en donde no existe ésta cultura. El resultado? 20 aplicaciones (no exagero) en términos de tecnología, con pequeñas variants, pero en el código todas distintas. Toooooodas todas todas distintas. Porque fueron hechas por distintas personas, sin el paraguas de la cultura de desarrollo,



Como yo digo siempre a mis gerentes, -y no les gusta mucho-: Code is all that matters.


Creo que la idea del open source es esa, compartir conocimiento (buenas o malas practicas, mal hecho o bien hecho, es un camino en una sola via, compartir) y a alguien le sera de ayuda.



Desgraciadamente el mundo .Netero es como decirle, un avido consumidor pero dificilmente producen, a diferencia de otros stacks tecnologicos como ruby,python o hasta objective C, ya que muchos tienen la idea de esto me costo, lo voy a guardar y nadie lo va a conocer, cuando realmente, puede serle de utilidad para otras personas.




Muchos van a decir, regalas tu trabajo, no, no lo regalo, porque estoy obteniendo un aprendizaje, si libero algo que hice por ejemplo en C# para resolver un problema, yo gane al aprender al resolverlo( y quizas aprendi una nueva tecnologia,tecnica,metodologia), y si esto puede resolver el mismo problema a alguien mas,pos que bueno, a compartirlo. Adicional que en algunos de los que hecho, hay gente que me ha mandando un pull request con nuevos features, entonces tambien gane por ese lado,porque ya yo no tuve que invertir tiempo en hacer esos features.


Tener un proyecto de referencia no te asegura ganar tu guerra (de tu proyecto), pero si ves muchos buenos proyectos seguro que ayuda mucho, esa referencia sirve para sacar los patrones y buenas prácticas. Se tiene toda esa experiencia para analizar y sacar los patrones para el desarrollo de proyectos. Sí, se va definiendo en función de la necesidad, pero mucha infraestructura puede ser común entre proyectos muy diferentes, y mejor sacar lo bueno de los proyectos "ejemplares" que comentaban, que otros que no lo sean tanto.

Y también muy importante esa Cultura de desarrollo y convenciones, lo cual lleva a decir que es un trabajo de equipo y de organización a lo largo del tiempo.

Compartir, vale, no es regalar el trabajo, pues primero es aprendizaje, y también involucrar a la comunidad en utilizar y reutilizar, lo cual aporta feedback y mejoras. Así pasó con JQuery, que se ha convertido casi en estandar.

Otra cosa es que alguno no lo valore y exija solucionar bugs, sin aportar nada. Si se encuentra un bug de algo que utilizas en tu beneficio, lo mínimo colaborar a la resolución, aportando una prueba de cómo reproducir el bug. No basta decir "esto falla, arreglalo".

La idea de talleres y coaching-mentoring con desarrolladores de alto nivel sería la mejor forma de aprender

Tomo ideas de Rodrigo Corral  geeks.ms/.../el-requeteframework.aspx

Flexibilidad y la reutilización NO son valores en si mismos, y no son gratis.  La simplicidad si que es un valor por si misma.  Escribir código es barato. Los costes están en mantenerlo, probarlo, desplegarlo y son proporcionales a la complejidad del código. Las abstracciones tienen un precio.


Y también de Productive Programmer de Neal Ford - www.scribd.com/.../Productive-Programmer-Tutorial-Neal-Ford

We invented our own web/persistence/messaging/caching framework because none of the existing ones was good enough.

Responder

Agregar comentario