Protezione di un'applicazione Web tramite HSTS

2

Sfondo

Sto sviluppando un'applicazione Web utilizzando ASP.Net MVC. Ho distribuito l'applicazione in IIS (V8) e ora sto facendo il processo di hardening delle app Web. Ho configurato SSL in IIS e l'app Web funziona solo tramite SSL (utilizzando cookie protetti ecc.).

Ho fatto alcuni test di sicurezza e un test che ho fatto stava cercando di intercettare il traffico SSL usando un proxy. Ho usato BurpSuite per questo test e ho installato il certificato di Burp nel mio browser.

Posso ispezionare facilmente tutto il traffico HTTPS usando lo strumento Burp. So che questo è possibile solo se installiamo il certificato dell'intercettore nel browser client. Altrimenti darà la notifica SSL rotta.

problema

Il mio problema è come possiamo impedire a qualsiasi intercettore di analizzare il traffico HTTPS anche se qualcuno installa il certificato dell'intercettore nel browser client?

Risoluzione

Ho sentito che se implementiamo HSTS (HTTP Strict Transport Security) possiamo risolvere questo problema.

Domanda

L'implementazione dell'HSTS risolve il problema che ho? In tal caso, qual è il modo più efficace di implementarlo (è necessario implementarlo a livello di applicazione o di hosting (IIS))?

Se l'HSTS non risolve questo problema, quali sono le altre alternative che dobbiamo proteggere da questo scenario?

    
posta user3496510 06.01.2017 - 00:48
fonte

1 risposta

6

Essere in grado di intercettare il traffico SSL con un certificato radice importato non è considerato un punto debole dell'applicazione web. È una decisione progettuale del browser che consente l'importazione di ancoraggi fiduciari locali personalizzati.

Does implementing the HSTS solving the problem I have?

No. A HTTP Strict Transport L'intestazione sulla sicurezza applica semplicemente HTTPS. A HSTS non interessa il quale certificato che usi finché è valido. Cioè, con HSTS non potrai più selezionare "Aggiungi un'eccezione" per un certificato non valido. Ma quando un certificato è considerato affidabile da una CA importata (come il certificato di root Burp), l'HSTS non fa differenza.

My problem is how we can prevent any interceptor analysing the HTTPS traffic even if someone installs the interceptor's certificate in the client browser?

Non puoi. se importi localmente un certificato di radice attendibile, un sito web non può istruire il tuo browser a rifiutarlo comunque.

Tieni presente che l'intestazione HTTP Public Key Pinning (HPKP) che un server può inviare per applicare una particolare catena di certificati. (Questo potrebbe essere il concetto che stai cercando, piuttosto che l'HSTS.) Ma anche questa intestazione non sovrascrive i certificati di root attendibili locali. (Ad esempio, Google, Facebook e Github continuano a caricarsi attraverso il proxy Burp malgrado l'invio di intestazioni HPKP che teoricamente rifiuterebbero la CA Burp.)

Da " Che cos'è HPKP ma non " :

HPKP does not protect against local attacks, such as malware intercepting traffic. As long as the malware has the ability to get a root certificate installed on your machine, there’s nothing HPKP can do.

Ciò è spiegato anche nel Domande frequenti sulla sicurezza di Chromium :

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

Quindi non esiste un modo comune per ottenere ciò che vuoi: sei sicuro di aver davvero bisogno di bloccare i certificati di root locali? Se un utente installa il certificato Burp nel proprio browser per intercettare il traffico SSL, dopo tutto ha fatto una scelta consapevole. Ecco come le domande frequenti su Chromium giustificano tale comportamento:

We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate — that is, the client is already under the control of the person who controls the proxy (e.g. the enterprise’s IT administrator). If the client does not trust the private trust anchor, the proxy’s attempt to mediate the connection will fail as it should.

    
risposta data 06.01.2017 - 01:06
fonte

Leggi altre domande sui tag