Asegurar una aplicación web usando HSTS

2

Background

Estoy desarrollando una aplicación web utilizando ASP.Net MVC. Desplegué la aplicación en IIS (V8) y ahora hago el proceso de fortalecimiento de la aplicación web. Configuré el SSL en IIS y la aplicación web funciona solo con SSL (usando cookies protegidas, etc.).

Hice algunas pruebas de seguridad y una prueba que hice fue tratar de interceptar el tráfico SSL usando un proxy. Utilicé BurpSuite para esta prueba e instalé el certificado de Burp en mi navegador.

Puedo inspeccionar fácilmente todo el tráfico HTTPS usando la herramienta Burp. Sé que esto es posible solo si instalamos el certificado del interceptor en el navegador del cliente. De lo contrario, dará la notificación SSL rota.

Problema

Mi problema es cómo podemos evitar que cualquier interceptor analice el tráfico HTTPS incluso si alguien instala el certificado del interceptor en el navegador del cliente.

Resolución

He oído que si implementamos HSTS (Seguridad de transporte estricta de HTTP) podemos resolver este problema.

Pregunta

¿Implementar el HSTS resolviendo el problema que tengo? Si es así, ¿cuál es la forma más efectiva de implementarlo (necesitamos implementarlo en el nivel de aplicación o en el nivel de Hosting (IIS))?

Si el HSTS no resuelve este problema, ¿cuáles son las otras alternativas que tenemos para asegurar este escenario?

    
pregunta user3496510 06.01.2017 - 00:48
fuente

1 respuesta

6

Ser capaz de interceptar el tráfico SSL con un certificado raíz importado no se considera una debilidad de la aplicación web. Es una decisión de diseño del navegador para permitir la importación de anclajes de confianza locales personalizados.

  

¿Implementando el HSTS resolviendo el problema que tengo?

No. A Transporte estricto de HTTP El encabezado de seguridad solo aplica HTTPS. A HSTS no le importa el certificado que use, siempre que sea válido. Es decir, con HSTS ya no podrá seleccionar "Agregar una excepción" para un certificado no válido. Pero cuando un certificado es de confianza para una CA importada (como el certificado raíz Burp), HSTS no hace una diferencia.

  

Mi problema es cómo podemos evitar que cualquier interceptor analice el tráfico HTTPS incluso si alguien instala el certificado del interceptor en el navegador del cliente.

No puedes. Si importas localmente un certificado raíz de confianza, un sitio web no puede indicar a tu navegador que lo rechace de todos modos.

Tenga en cuenta que también existe el encabezado HTTP Public Key Pinning (HPKP) que un servidor puede enviar para imponer una cadena de certificados particular. (Este podría ser el concepto que está buscando, en lugar de HSTS). Pero incluso este encabezado no invalida los certificados raíz locales de confianza. (Por ejemplo, Google, Facebook y Github todavía se cargan a través del proxy Burp a pesar de enviar encabezados HPKP que, en teoría, rechazarían la CA Burp).

De " Qué HPKP es pero no es " :

  

HPKP no protege contra ataques locales, como malware que intercepta el tráfico. Mientras el malware tenga la capacidad de instalar un certificado raíz en su máquina, no hay nada que HPKP pueda hacer.

Esto también se explica en Preguntas frecuentes sobre la seguridad de Chromium :

  

Chrome no realiza la validación de pin cuando la cadena de certificados se encadena a un ancla de confianza privada. Un resultado clave de esta política es que los anclajes de confianza privados se pueden usar para establecer conexiones (o MITM), incluso a los sitios anclados. Los dispositivos de "prevención de pérdida de datos", los firewalls, los filtros de contenido y el malware pueden usar esta función para anular las protecciones de la fijación de claves.

Por lo tanto, no existe una forma común de lograr lo que desea. ¿Está seguro de que realmente necesita bloquear los certificados raíz locales? Si un usuario instala el certificado Burp en su navegador para interceptar el tráfico SSL, después de todo, tomó una decisión consciente. Aquí es cómo las preguntas frecuentes de Chromium justifican ese comportamiento:

  

Consideramos esto aceptable porque el proxy o MITM solo pueden ser efectivos si la máquina cliente ya se ha configurado para confiar en el certificado de emisión del proxy, es decir, el cliente ya está bajo el control de la persona que controla el proxy (por ejemplo, administrador de TI de la empresa). Si el cliente no confía en el ancla de confianza privada, el intento del proxy de mediar en la conexión fallará como debería.

    
respondido por el Arminius 06.01.2017 - 01:06
fuente

Lea otras preguntas en las etiquetas