Las aplicaciones seguras de verdad no se olvidan de las cabeceras HTTP

Heartbleed cambió algo en el "mercado" de la seguridad. Es verdad que vulnerabilidades con un llamativo nombre propio las hubo antes (se me viene a la cabeza aquel "Ping de la muerte" de finales del siglo pasado), pero Heartbleed llegó un momento en que el mercado de la seguridad mueve dinero y la publicidad es parte del negocio. Si previamente las cosas eran llamadas MS08-068 o por el estilo, ahora en cuanto se descubre algo, aunque no sea demasiado relevante, se le pone nombre, se le crea una página web e incluso se le compone una canción.

Y es que los nombres son importantes y pueden cambiar la forma en que vemos las cosas. Recuerdo los viejos tiempos, cuando supe por primera vez de las "Active Server Pages" (ASP) o, algo después, de PHP. A ambos sistemas se les categorizaba como "generadores de páginas web dinámicas".

Puede que a primera vista no lo parezca, pero llamarles de ese modo tiene sus implicaciones para la seguridad de los sistemas. Porque puede hacer que los desarrolladores centren su atención en sólo uno de los aspectos de la creación de aplicaciones basadas en estas tecnologías: la generación de páginas web. De código HTML. En otras palabras, en la creación de un documento.

Y, claro, se dejan atrás de otras cosas que también deberían ser parte fundamental del programa. Como la forma en que el documento es transmitido. Porque no se debe olvidar que existe un buen número de cabeceras HTTP cuya configuración puede afectar, y mucho, a la seguridad de la aplicación final.

Aunque ninguna protección es, por sí sola, suficiente para garantizar la seguridad de una aplicación, cosas como la cabecera de HTTP "X-Frame-Options" ayudan a evitar ser víctimas del ClickJacking. Igual que "X-XSS-Protection" puede configurar el comportamiento del navegador (si es que dispone de filtro anti-XSS) ante posibles XSS reflejados. O que "X-Content-Type-Options" puede evitar que el content sniffing se convierta en un problema con ciertas versiones de ciertos navegadores. O que "Cache-Control", o su hermana de HTTP 1.0 "Pragma", puede evitar que información confidencial quede guardada en los "archivos temporales de internet" o como en cada caso se llame. O que "Strict-Transport-Security" permite controlar el uso de HTTPS. Y, para acabar, ahí anda esa solución de carácter general, la Content Security Policy.

Y seguro que me he dejado un montón de cosas en el tintero. Un buen programa (y un buen programador) debería hacer uso de estas herramientas o, como poco, permitir al administrador de la aplicación configurar las cabeceras y avisarle en caso de detectar unos ajustes que pudieran suponer un riesgo.

Ciertamente, tratar con las cabeceras HTTP añade líneas de código. Y las cabeceras tienen sus variantes, derivadas de distintas versiones o de detalles de implementación propios de cada navegador, etc. Es necesario que la implementación tenga todo esto en cuenta y genere valores consistentes entre aquellas cabeceras que estén relacionadas entre sí o que configuran un mismo comportamiento.

Pero nadie dijo que esto de escribir programas fuera sencillo.