29 jun 2016

#HSTS. ¿Qué es y cómo lo implanto en mi empresa? Parte 1

Buenas a todos, en el post de hoy me gustaría hablaros de HSTS (HTTP Strict Transport Security), la especificación de la RFC 6797 motivada por el Force HTTPS, que fue publicada el 19 de noviembre de 2012, y que aunque ya lleva más de 3 años entre nosotros, en las empresas es un gran desconocido y es un "must" en los informes de auditoría de hacking ético web que sale casi siempre, como el típico banner del servidor expuesto, o las vulnerabilidades de CSRF.

Tal y como explicó hace un par de años David Cantón en el blog de Incibe:
HSTS define el mecanismo, o procedimiento que deben seguir tanto el servidor, como el navegador web (o más genéricamente un "User Agent") para que interactúen de forma más segura, usando exclusivamente comunicaciones seguras, como HTTPS gracias al uso de protocolos de transporte seguros como son TLS/SSL. Esta especificación sería una alternativa al uso de otros protocolos de transmisión de información como SPDY, el cual por definición utiliza comunicaciones siempre cifradas. 
El soporte de esta especificación por parte de los servidores y navegadores web conlleva una considerable mejora en la seguridad y privacidad de las comunicaciones de los usuarios. En este artículo describiremos brevemente tanto el objetivo de la especificación como su funcionamiento. 
Como define su especificación, el objetivo de HSTS es la mejora de la seguridad en las comunicaciones web centrándose en tres tipos de amenazas o ataques:
  • Ataques de red pasivos, aquellos en los que un atacante está escuchando todo el tráfico, como por ejemplo en una red WiFi, con el objetivo de obtener información de comunicaciones no cifradas, llegando en algunos casos a poder robar información sensible como la sesión de los usuarios.
  • Ataques de red activos, en los que los atacantes actúan sobre la propia red inyectando datos, suplantando elementos de la red, redirigiendo los comunicaciones, …
  • Errores cometidos por los desarrolladores del sitio web, como el uso de conexiones no seguras para descargar elementos como recursos de la web (CSS, JavaScript,…) o el envío de datos.
En resumidas cuentas, lo que permite HSTS es informar al navegador que las conexiones al sitio deben utilizar SSL o TLS, definiendo el modo en que deben actuar navegador y servidor, Para reaizar esta información e indicar al navegador que esta especificación se encuentra soportada, se hace uso de un campo en la cabecera de respuesta (Strict-Transport-Security).

A continuación os comparto una imagen publicada por el departamento de defensa de Australia, explicando el proceso de comunicación con HSTS:



Los principales navegadores del mercado la incorporaron rápidamente:
  • Google Chrome: admitido desde la versión 4.0.211.0.21.
  • Firefox: admitido desde Firefox 4 y en la 17 proporciona ya una lista de sitios web que soportan HSTS.
  • Opera: admitido desde la versión 12.
Por lo que resuelto el problema del lado del cliente, ahora el problema proviene de las aplicaciones y los servicios ofertados por las empresas. Que en muchas ocasiones, por grandes que sean los proveedores, es sorprendente ver lo difícil que es para ellos realizar un cambio de estas características.

¿Qué pueden hacer nuestras empresas para comenzar a soportar HSTS?

La verdad que no es un cambio complejo, ni que requiera abrir un proyecto muy grande. Aunque seguro que en algunas empresas es un quebradero de cabeza por problemas de redirecciones...

En el caso de Apache, se puede agregar al archivo .htaccess la siguiente línea
Header always set Strict-Transport-Security "max-age=10886400; includeSubDomains"
En el caso de IIS, se puede agregar el siguiente código en el web.config del site:
<system.webServer><httpProtocol><customHeaders><add name="Strict-Transport-Security" value="max-age=10886400"/></customHeaders></httpProtocol></system.webServer>
En el caso de nginx, se puede agregar la siguiente línea de código en el fichero nginx.conf:
add_header Strict-Transport-Security "max-age=10886400; includeSubDomains";
En PHP podríamos agregar un código como el siguiente (via Wikipedia):

$use_sts = true;

// iis sets HTTPS to 'off' for non-SSL requests
if ($use_sts && isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off') {
    header('Strict-Transport-Security: max-age=10886400; includeSubDomains; preload');
} elseif ($use_sts) {
    header('Location: https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'], true, 301);
    // we are in cleartext at the moment, prevent further execution and output
    die();
}

Siempre se trata como podéis ver de añadir el parámetro max-age, indicando el tiempo de duración en segundos de la comunicación HTTPS de navegador con servidor. 

Esto es todo por hoy, pronto publicaremos la segunda parte del artículo con nuevas medidas de defensa HSTS, y potenciales ataques.

Saludos!

No hay comentarios:

Publicar un comentario