4 sep. 2014

HSTS, forzando conexiones seguras

HTTP Strict Transport Security (HSTS) es una especificación (RFC 6797), que surgió a partir de la propuesta ForceHTTPS, para solucionar una serie de problemas y ataques de seguridad detectados. 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.

Cómo funciona

Para solucionar estas amenazas, HSTS básicamente establece que todas las comunicaciones deben ser bajo un protocolo de comunicaciones seguro, como es HTTPS. Además de definir el modo en que deben actuar tanto el navegador como el servidor, HSTS también define un nuevo campo en la cabecera de respuesta (Strict-Transport-Security), como forma de que el servidor informe al navegador que soporta esta especificación y que todas las conexiones entre ambos deben utilizar HTTPS.
  • La extensión NoScript para Firefox impone HSTS partir de la versión 1.9.8.9.
  • La extensión HTTPS Everywhere para Firefox, derivada de NoScript, generaliza el concepto de HSTS, para incluir subconjuntos de los caminos en algunos dominios y reescritura de URI inseguros http:// en un dominio para obtener los https:// en otro.
De forma resumida, HSTS establece la forma en que deben actuar tanto el navegador web y el servidor web si soportan esta especificación:
  1. Petición HTTP, al establecer el navegador una solicitud sobre un protocolo de transporte no seguro el servidor deberá devolver un código de estado 301 (Re-direccionamiento Permanente) indicando la nueva dirección donde se debe realizar la petición y que debe utilizar el protocolo HTTPS.
  2. Petición HTTPS, como en este caso la petición se realiza bajo un protocolo de comunicaciones seguro el servidor responderá normalmente añadiendo en la cabecera de la respuesta el campo Strict-Transport-Security con los datos que se hallan configurado en el servidor.
  3. A partir de este momento, el navegador web sabe que todas las peticiones a este dominio (y subdominio, si así se indica) deben ser bajo un protocolo de comunicaciones seguro, debiendo el propio navegador modificar las peticiones antes de enviarlas al servidor (http://example.com/some/page/ por https://example.com/some/page/). Si durante la conexión se determina cualquier tipo de error deberá terminar la comunicación, estos errores incluyen warning como que el certificado del sitio web esté auto-firmado que en una comunicación HTTPS normal conllevaría una advertencia y daría la opción de poder continuar la conexión. Además estas cabeceras HSTS deben ser almacenadas por el propio navegador web, aplicándolo durante el tiempo de validez definido en campo de cabecera de respuesta del servidor.
  4. Dominios y subdominios cacheados por el navegador, en este caso el navegador debe actuar como en el caso anterior, estableciendo directamente todas las conexiones desde el inicio bajo un protocolo de transporte seguro y por lo tanto cambiando cualquier enlace o petición http a https.
Un ejemplo del campo definido por HSTS para la cabecera de respuesta de conexión HTTPS con un servidor web es el siguiente:

Strict-Transport-Security: max-age=15768000; includeSubDomains

Este campo de la cabecera establece que durante un año (max-age=15768000) tanto el dominio solicitado como todos sus subdominios (includeSubDomains) deben operar bajo la especificación HSTS, obligando que todas las conexiones se realicen bajo un protocolo de transporte seguro. Además el navegador web deberá cachear este dato para su uso en futuras conexiones a este dominio y sus correspondientes subdominios. Más información en OWASP.

Implementación en Apache

# load module (example using [RHEL])
LoadModule headers_module modules/mod_headers.so
 
# redirect all HTTP to HTTPS (optional)
[virtualhost]
       ServerAlias *
       RewriteEngine On
       RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
[/virtualhost]
 
# HTTPS-Host-Configuration
[virtualhost 10.0.0.1:443]
      # Use HTTP Strict Transport Security to force client to use secure connections only
      Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
 
      # Further Configuration goes here
      [...]
[/virtualhost]

Implementación en PHP

// Use HTTP Strict Transport Security to force client to use secure connections only
$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=31536000');
} 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();
}

Bootstrap MITM vulnerability

Un ataque al que se seguía siendo vulnerable aun implementando esta especificación era a un ataque Bootstrap MITM, es decir, la interceptación de conexión entre el navegador y el servidor desde la conexión inicial si esta se realiza mediante un protocolo no seguro (HTTP). Mediante este ataque MITM (man-in-the-middle) el atacante podría interceptar la comunicación y eliminar la cabecera Strict-Transport-Security fácilmente, haciendo de puente y cambiado las comunicaciones sin que el navegador o User Agent pudiese detectar que la comunicación está siendo interceptada.

Para solucionar esta vulnerabilidad la especificación HSTS incluye entre sus recomendaciones la implementación de "listas HSTS Pre-cargadas" por parte de los navegadores. Estas listas serían un conjunto de dominios predefinidos en el navegador y que obligarían a implementar las políticas de seguridad definidas en HSTS como si estuviesen cacheados. De esta forma siempre la primera conexión entre el navegador y el servidor seria bajo HTTPS y el navegador podría verificar la identidad del servidor. Está recomendación sobre "listas HSTS Pre-cargadas" esta implementada por varios navegadores web como son Firefox o Chrome.

Ventajas de HSTS

Resumiendo todo lo visto anteriormente, las principales ventajas que aporta HSTS son:
  • Todas las comunicaciones contra el dominio deben ser bajo HTTPS, incluyendo CSS and JavaScript.
  • Cualquier tipo de fallo o advertencia que se genere durante el establecimiento de la conexión segura aborta la misma.
  • Protección contra ataques MITM (Man-In-The-Middle), evitando también Bootstrap MITM si el navegador implementa las "listas HSTS Pre-cargadas".
Fuente: INTECO

0 comentarios:

Publicar un comentario

Gracias por dejar un comentario en Segu-Info
Si vas a dejar una consulta, procura tener habilitado tu perfil en Blogger o deja una forma de contacto.

Gracias por comentar!