lunedì 28 novembre 2011

OWASP Top 10 per gli sviluppatori NET parte 9:. Insufficiente protezione Transport Layer

Quando si tratta di sicurezza del sito Web, l'indicazione più diffuso che il sito è "sicuro" è la presenza di protezione livello di trasporto. La garanzia fornita dal sito è diversa tra i browser, ma il messaggio è sempre lo stesso, tu sai con chi stai parlando, sai che il tuo comunicazione è criptata sulla rete e si sa che non è stata manipolata in transito:
Diverse rappresentazioni TLS su diversi browser
HTTPS, SSL e TLS (andremo nelle differenze tra questi tra poco), sono punti essenziali della sicurezza del sito. Senza questa garanzia non abbiamo fiducia di chi stiamo parlando e se le nostre comunicazioni - sia i dati che inviamo e riceviamo i dati - è autentico e non è stato intercettato.
Ma purtroppo spesso ci si accorge siti carenti e non aver applicato una protezione livello di trasporto. A volte questo è a causa dei costi percepiti di attuazione, a volte non è sapere come e, talvolta, è semplicemente non capire il rischio che la comunicazione pone in chiaro.Parte 9 di questa serie sta andando a chiarire questi malintesi e mostrare a implementare questa funzione essenziale di sicurezza in modo efficace all'interno di ASP.NET.

La definizione di una protezione insufficiente livello di trasporto

Protezione livello di trasporto è più coinvolto non solo se esiste o no, in effetti questo intero post parla di insufficiente implementazioni. E 'del tutto possibile implementare SSL su un sito ma non farlo in un modo che fa pieno uso della protezione che offre.
Ecco come OWASP riassume:
Le applicazioni spesso non riescono a autenticare, crittografare e proteggere la riservatezza e l'integrità del traffico di rete sensibili. Quando lo fanno, a volte il supporto di algoritmi deboli, utilizzare certificati scaduti o non validi, o non li usano correttamente.
Ovviamente questo suggerisce che vi è una certa variabilità nell'efficacia di diverse implementazioni. OWASP definisce la vulnerabilità e l'impatto come segue:
Minaccia
agenti
Attacco di
Vettori
Debolezza di sicurezzaTecnico
Impatti
Affari
Impact
 SfruttabilitàFACILE
PrevalenzaUNCOMMON
RilevabilitàMEDIA
ImpattoMODERATO
 
Considerare chiunque può monitorare il traffico di rete degli utenti. Se l'applicazione è su internet, che sa come utenti di accedervi. Non dimenticare di nuovo terminare le connessioni.Il traffico di rete degli utenti di monitoraggio 'può essere difficile, ma a volte è facile. La difficoltà principale sta nel monitoraggio del traffico della rete corretta, mentre gli utenti accedono al sito vulnerabile.Le applicazioni spesso non proteggono il traffico di rete.Possono utilizzare il protocollo SSL / TLS durante l'autenticazione, ma non altrove, esponendo dati e ID di sessione alle intercettazioni.Scaduti o certificati configurato in modo improprio può essere utilizzato anche.
Rilevare i difetti di base è semplice. Basta osservare il traffico di rete del sito. I difetti più sottili richiedono controllo della progettazione dell'applicazione e la configurazione del server.
Tali difetti esporre i dati dei singoli utenti 'e possono portare al furto di account. Se un account amministratore è stata compromessa, l'intero sito potrebbero essere esposti.Poveri configurazione SSL può anche facilitare gli attacchi di phishing e MITM.Si consideri il valore di business dei dati esposti sul canale di comunicazione in termini di riservatezza e le esigenze di integrità, e la necessità di autenticare entrambi i partecipanti.
Ovviamente questo ha molto a che fare con la possibilità di monitorare il traffico di rete, qualcosa che stiamo andando a guardare in pratica a breve. La matrice sopra allude anche al fatto che strato protettivo di trasporto è importante oltre la semplice protezione dei dati come le password e le informazioni sulle pagine web restituite. Infatti SSL e TLS va ben oltre questo.

Chiarimento delle ambiguità: SSL, TLS, HTTPS

Questi termini sono usati in modo intercambiabile in modo un po 'cerchiamo di definirle in anticipo prima di iniziare a usarli.
SSL Secure Sockets Layer è che è il termine che usato da utilizzare per descrivere il protocollo crittografico utilizzato per comunicare attraverso il web. SSL fornisce uno schema di crittografia asimmetrica che sia client che server possono utilizzare per cifrare e decifrare i messaggi inviati in entrambe le direzioni. Netscape originariamente creato indietro SSL negli anni '90 e da allora è stata superata da TLS.
TLS è il Transport Layer Security e il successore di SSL. Potrai frequente vedere i numeri di versione TLS accanto equivalente SSL, TLS 1.0 è SSL 3.1, TLS 1.1 è SSL 3.2, ecc In questi giorni, è solitamente vedere le connessioni sicure espresso come versioni TLS:
La versione TLS visualizzato sul certificato di American Express '
SSL / TLS può essere applicato a una serie di protocolli diversi livello di trasporto: FTP, SMTP e, naturalmente, HTTP.
HTTPS è Hypertext Transport Protocol Secure ed è l'implementazione di TLS su HTTP. HTTPS è anche il sistema di URI di indirizzi di siti web attuazione SSL, che è che è il prefisso di un indirizzo come https://www.americanexpress.com e implica il sito verrà caricato tramite una connessione criptata con un certificato che di solito può essere ispezionato nel browser.
Utilizzando questi tre termini intercambiabili, l'intento è di solito la stessa in quanto si riferisce a comunicare in modo sicuro su HTTP.

Anatomia di un attacco insufficiente protezione dello strato di trasporto

Al fine di dimostrare adeguatamente il rischio della sicurezza dei trasporti insufficienti, voglio ricreare un tipico scenario ad alto rischio. In questo scenario abbiamo un sito web ASP.NET MVC, che implementa provider di appartenenza di Microsoft, un out eccellente della soluzione box per la registrazione, login e memorizzazione delle credenziali che ho discusso di nuovo inparte 7 di questa serie di memorizzazione di dati crittografici. Questo sito è un progetto che sto attualmente costruendo presso asafaweb.com e ai fini di questo post, non stava facendo uso di TLS.
Per questo esempio, ho un computer portatile, un iPad e una scheda di rete che supporta la modalità promiscua che significa semplicemente che è in grado di ricevere pacchetti wireless che non può necessariamente essere destinati al suo indirizzo. Normalmente un adattatore wireless riceverà solo i pacchetti diretti al suo indirizzo MAC, ma come pacchetti wireless sono semplicemente trasmessi via etere, non c'è nulla per fermare un adattatore di ricevere i dati non esplicitamente previsto per esso. Un sacco di built-in schede di rete non supportano questa modalità, ma 27 dollari da eBay e AWUSO36H Alfa risolve questo problema:
Un'Alfa AWUSO36H promiscuo adattatore wireless
In questo scenario, l'iPad è un utente innocente del sito ASafaWeb. Sono già effettuato l'accesso come amministratore e come tale ho le voci di menu evidenziate di seguito:
Registrati al sito ASafaWeb sul iPad come un admin
Anche se non è esplicito sul iPad, questa pagina è stata caricata su HTTP. Una pagina caricata su HTTPS viene visualizzato un piccolo lucchetto sulla destra della scheda:
immagine
Il portatile è l'attaccante ed ha diritti non più di qualsiasi pubblico, utente non autenticato sarebbe. Di conseguenza, manca le voci di menu amministrativi iPad aveva:
Accedendo al sito ASafaWeb sul PC, mentre non autenticata
Per un senso di realismo e di simulare un vero e proprio scenario di attacco vita, ho fatto un giro giù per il locale McDonald, che offre la connessione wifi. Sia il computer portatile e l'iPad stanno approfittando del servizio, così come molti altri clienti sparsi in tutto il ristorante.L'iPad è stato assegnato un indirizzo IP di 192.168.16.233 come confermato dallaapplicazione IP Scanner :
L'applicazione IP Scanner che mostra l'indirizzo IP del iPad
Quello che stiamo andando a fare è utilizzare il portatile per ricevere i pacchetti che vengono inviati attraverso la rete wireless indipendentemente dal fatto che in realtà dovrebbe essere di riceverli o meno (ricordate questo è il nostro modo promiscuo in azione). Windows è notoriamente cattiva esecuzione in modalità promiscua, quindi sono in esecuzione il software BackTrack in una macchina virtuale Linux. Un intero pre-configurate immagine può essere scaricata e funzionante in poco tempo. Utilizzando la pre-installato il software airodump-ng , tutti i pacchetti la scheda wireless possono raccogliere sono ora in fase di registrazione:
Catturare i pacchetti provenienti da wifi del McDonald usando BackTrack
Quello che vediamo sopra è airodump-ng catturare tutti i pacchetti che possono entrare in possesso di tra il BSSID del punto di accesso wireless alla McDonald nonché i singoli dispositivi ad esso collegati. Possiamo vedere l'indirizzo MAC del dell'iPad sulla seconda riga della tabella. L'adattatore collegato al computer portatile è appena sopra e che un certo numero di altri clienti poi apparire più in basso nella lista. Come funziona la cattura, è in streaming i dati in un file. Tappo di file che possono poi essere analizzati in un secondo momento.
Mentre la cattura corse, ho avuto un navigare intorno al sito ASafaWeb sul iPad. Ricordate, l'iPad potrebbe essere un qualsiasi utente pubblico - non ha assolutamente alcuna associazione al computer portatile di eseguire la cattura. Dopo aver abbandonato il processo di correre per qualche minuto, ho aperto il file di cattura in Wireshark che è un cattura dei pacchetti e strumento di analisi frequentemente utilizzati per il monitoraggio e controllo del traffico di rete:
Rivedere i pacchetti catturati HTTP utilizzando Wireshark
In questo caso, ho filtrato il traffico per includere solo i pacchetti inviati tramite il protocollo HTTP (si può vedere in questo il filer in cima alla pagina). Come potete vedere, c'è un sacco di traffico che passa avanti e indietro attraverso una serie di indirizzi IP. Solo alcuni di essi - come i primi 6 pacchetti - viene dal mio iPad. Il resto sono da altri avventori in modo eticamente, non andrà da nessuna parte vicino a questi. Facciamo filtro i pacchetti ulteriormente, in modo che solo quelli provenienti dal mio iPad sono indicati:
Wireshark filtrare i pacchetti HTTP per quelli inviati dal iPad
Ora iniziamo a vedere alcune informazioni interessanti, come le richieste GET per il collegamento ELMAH apparire. Cliccando col tasto destro sul primo pacchetto e seguendo il flusso TCP, possiamo vedere l'intera richiesta:
L'. ASPXAUTH cookies inviati dal pubblico oltre iPad wifi
È qui che diventa davvero interessante: ogni richiesta qualsiasi browser fa a un sito web comprende i cookie il sito è impostato. La richiesta contiene sopra un certo numero di cookie, tra cui quella denominata ". ASPXAUTH". Questo cookie viene utilizzato dal provider di appartenenze per mantenere lo stato autenticata del browser attraverso il non-persistente, protocollo senza stato che è HTTP. Sul portatile, sto correndo il Modifica Questa estensione dei cookie in Chrome che consente una facile ispezione dei cookie esistenti impostato da un sito web. Ecco ciò che il sito ASafaWeb ha stabilito:
I cookie nel browser attualmente del PC per il sito web ASafaWeb
Ignorare i cookie __utm prefisso - questo è solo Google Analytics. Quello che è importante è che perché questo browser non è autenticato, non c'è cookie ". ASPXAUTH". Ma questo è facilmente rimedio semplicemente aggiungendo un nuovo cookie con lo stesso nome e valore, come abbiamo appena osservato dal iPad:
Manualmente ricreando l'. Cookies ASPXAUTH nel PC annusato da iPad
Con il nuovo cookie di autenticazione è semplicemente una questione di aggiornare la pagina:
Dirottamento di successo della sessione nel browser del PC
Bingo. Insufficiente protezione dello strato di trasporto ha appena permesso di dirottare la sessione e diventare un amministratore.

Ciò che ha reso possibile tutto questo?

Quando ho fatto riferimento a "dirottare la sessione", ciò significa che l'attaccante era in grado di inviare le richieste che, per quanto il server è stato interessato, continua la stessa sessione di autenticazione di quello originale. In realtà l'utente legittimo può continuare a utilizzare il sito senza alcun impatto negativo di sorta, ci sono semplicemente due browser separati autenticato come lo stesso utente nello stesso momento. Questa forma di dirottamento di sessione in cui i pacchetti sono sniffato in transito e il cookie di autenticazione ricreato è spesso definito come sidejacking , una forma di dirottamento di sessione, che è particolarmente vulnerabile al pubblico hotspot wifi data la facilità di sniffing dei pacchetti (come dimostrato sopra).
Questo non è un difetto sul fine McDonald o un difetto con il provider di appartenenze non è nemmeno un difetto con il modo in cui l'ho configurato, l'attacco di cui sopra è semplicemente un prodotto di pacchetti che vengono inviati sulle reti in chiaro senza crittografia. Pensate alle potenziali opportunità di intercettare i pacchetti in chiaro: McDonald è ormai ovvio, ma ci sono migliaia di negozi di caffè, lounge delle compagnie aeree e altri punti di accesso wireless pubblici che fanno un gioco da ragazzi.
Ma non è solo wifi, letteralmente qualsiasi punto di una rete in cui i pacchetti di transito è a rischio. Che cosa succede a monte del router? O all'interno del vostro ISP? Oa livello del gateway della rete aziendale? Tutti questi luoghi e molti altri sono potenziali punti di intercettazione dei pacchetti e quando volare in giro per il chiaro, entrare in possesso di loro è molto semplice. In alcuni casi, lo sniffing dei pacchetti su una rete può essere un compito molto rudimentale infatti:
Una rete di intercettazioni cavo
Molte persone pensano di TLS come un puro mezzo di crittografia dei dati sensibili degli utenti in transito. Per esempio, vedrete spesso moduli di login inviando credenziali su HTTPS inviando poi l'utente autenticato torna a HTTP per il resto della loro sessione. Il pensiero è che una volta che la password è stata correttamente protetto, TLS non ha più un ruolo da svolgere. L'esempio sopra mostra che l'intero sessioni autenticate devono essere protetti, non solo le credenziali in transito. Questa è una lezione insegnata da Firesheep l'anno scorso ed è senza dubbio il catalizzatore per l'attuazione di Facebook la possibilità di utilizzare TLS tra le sessioni autenticate.

Le basi dei certificati

La premessa di TLS è incentrata sulla possibilità per i certificati digitali da emettere che forniscono la chiave pubblica del processo di crittografia asimmetrica e verificare l'autenticità dei siti che li portano. I certificati sono rilasciati da un'autorità di certificazione (CA), che è regolato da normative stringenti controllare come vengono accantonati (ce ne sono attualmente oltre 600 CA in oltre 50 paesi ). Dopo tutto, se qualcuno certificati disposizione potrebbe allora il fondamento su cui è costruita TLS sarebbe molto traballante davvero. Ne riparleremo più avanti.
Così come fa il browser sapere quale CA fidarsi certificati da? Memorizza le autorità di fiducia, che sono gestiti dal produttore del browser. Per esempio, Firefox li visualizza nella Certificate Manager (La CA di fiducia Firefox può anche essere visto in linea ):
Firfox di certificazione attendibili
Microsoft sostiene CA in Windows sotto il suo programma Root Certificate che è accessibile da Internet Explorer:
Radice di autorità di certificazione accessibile da Internet Explorer
Naturalmente il produttori di browser devono inoltre essere in grado di mantenere queste liste. CA ogni tanto vengono aggiunte nuove e in casi estremi (come DigiNotar di recente), possono essere rimossi causando in tal modo i certificati rilasciati dalle autorità di non essere più attendibile dal browser e causare avvisi di protezione e non palese.
Come ho scritto prima, SSL non è sulla crittografia . Si tratta infatti di una serie di vantaggi:
  1. Esso fornisce garanzia dell'identità del sito (verifica del sito).
  2. Si garantisce che il contenuto non è stata manipolata in transito (integrità dei dati).
  3. Si garantisce che le intercettazioni non si è verificato in transito (riservatezza dei dati).
In questi giorni, entrare in possesso di un certificato è rapido, economico e facilmente procurati dal registrar di domini e hosting provider. Per esempio, GoDaddy (che affermano di essere il più grande fornitore mondiale di certificati), può cominciare da $ 79 all'anno . O si può anche prendere uno gratuito da StartSSL che ora sono stati aggiunti alla lista di certificazione attendibili nei principali browser. Web host più buoni hanno anche disposizioni per la facile installazione dei certificati all'interno del vostro ambiente di hosting. In breve, TLS è molto economico e molto facilmente configurabili.
Ma, naturalmente, la grande domanda è "Che cosa significa il traffico di rete protetto da TLS effettivamente assomiglia?" Dopo aver applicato un certificato al sito ASafaWeb e il caricamento di una pagina su HTTPS autenticata dalla mia rete locale, sembra proprio così:
ASafaWeb TLS traffico visualizzato in Wireshark
L'indirizzo IP di destinazione nel filtro è quello dietro asfaweb.com e mentre i pacchetti, ovviamente, identificare la destinazione finale, che non rivelano molto oltre. Infatti il ​​flusso TCP svela nulla al di là i dettagli del certificato:
Il flusso TCP della pagina di login caricata su HTTPS
Naturalmente ci aspettiamo che queste informazioni da inviare in chiaro, è solo ciò che troverete quando si ispeziona il certificato nel browser:
Dettagli certificato per ASafaWeb caricata nel browser
Non c'è davvero molto altro da mostrare, ciascuno dei pacchetti con la cattura Wireshark sono ben crittografate e conservate lontano da occhi indiscreti, che è esattamente quello che ci si aspetterebbe.
Un'ultima cosa sui certificati, è sempre possibile creare ciò che è indicato come un certificato autofirmato ai fini del test. Piuttosto che essere emesso da una CA, un certificato autofirmato viene creato dal proprietario in modo la sua legittimità non è mai veramente certo. Tuttavia, è un modo molto semplice per verificare come si comporta la vostra applicazione su HTTPS e quello che verrà usato in una serie di esempi in questo post. C'è un grande post piccolo blog di Scott Gu in Attivazione di SSL su IIS 7.0 Utilizzo di self-signed certificati che guida attraverso il processo. A seconda del browser, si otterrà un avvertimento molto appariscenti quando si accede a un sito con un certificato self-signed:
Avvertimento di Chrome su un certificato self-signed
Ma ancora una volta, a scopo di test, questo funzionerà bene.

Utilizzare sempre SSL per l'autenticazione forme

Chiaramente il problema nel dirottamento di sessione esempio precedente era che non era presente TLS. Ovviamente ipotizzando esiste un certificato valido, un modo di affrontare il problema sarebbe semplicemente per garantire accesso avviene su TLS (tutti i link alla pagina di login dovrebbe includere lo schema HTTPS). Ma c'è un difetto con solo facendo questo solo; lasciatemi dimostrare.
Qui 'abbiamo lo stesso sito in esecuzione in locale tramite HTTPS con un certificato self-signed, da qui gli indicatori di avviso nella barra degli indirizzi:
Il sito ASafaWeb in esecuzione localmente con un certificato autofirmato
Questo da solo va bene, ammesso, naturalmente, aveva un certificato valido. Il problema, però, è questo:
Caricamento del sito ASafaWeb su HTTP dopo l'autenticazione tramite HTTPS
C'è una sottile differenza in questa schermata - il regime è ormai HTTP. Il problema è però che siamo ancora registrato in cosa questo significa è che il. Cookies ASPXAUTH è stato inviato attraverso la rete in chiaro ed è aperto a intercettazione nello stesso modo ho preso quello di McDonald in precedenza. Tutto ciò che serve è una richiesta HTTP al sito web, mentre sto collegato - anche se mi sono collegato su HTTPS - e il dirottamento di sessione ritorna rischio. Quando abbiamo ispezionare il cookie, la ragione di questo è chiaro:
. Cookies ASPXAUTH non contrassegnati come "sicuro"
Il cookie non è contrassegnato come "sicuro". L' attributo cookie sicuro indica al browser se debba o meno inviare il cookie tramite una connessione HTTP. Quando il cookie non è decorato con questo attributo, il browser lo invierà insieme a tutte le richieste al dominio che si era prefissi, indipendentemente dal fatto che lo schema HTTP o HTTPS viene utilizzato.
La mitigazione di questo all'interno di un sito web autenticazione basata su form in ASP.NET è quella di impostare la proprietà requireSSL nel web.config su "true":
< forme loginUrl = " ~ / Account / LogOn " timeout = " 2880 " requireSSL = " true " />
Dopo lo facciamo, la proprietà "sicura" sul cookie è ora impostata e ben visibile quando guardiamo i biscotti passato sopra il regime di HTTPS:
. Cookies ASPXAUTH contrassegnati come "sicuri" dopo aver impostato auth moduli per richiedere SSL
Ma tornare e il cookie HTTP ASPXAUTH è completamente scomparso - tutti di sinistra che è il cookie che persiste l'ID di sessione.:
No. Cookies ASPXAUTH su HTTP dopo il login su HTTPS
Che il cookie non è sicuro che garantisce assolutamente, positivamente non può essere passata attraverso la rete in chiaro. Il dirottamento di sessione esempio da prima su è ora impossibile da riprodurre. Significa anche che non è più possibile accedere oltre lo schema HTTP:
Errore del server durante il tentativo di accesso su HTTP dopo auth forme previste per richiedere HTTPS
Questa è una bella auto-esplicativo messaggio di errore!

Se possibile, utilizzare SSL per i cookie

Nel precedente esempio, il provider di appartenenze si prese cura di impostare il. Cookies ASPXAUTH e dopo la corretta configurazione del web.config, ma ha anche assicurato il cookie è stato segnalato come "sicuri". Ma la portata di questo è puramente il cookie auth, niente di più. Prendete il codice seguente come esempio:
var cookies = nuovo HttpCookie ( "ResultsPerPage" , "50" );
Response.Cookies.Add (cookie);
Supponiamo che questo cookie viene utilizzato per determinare il numero di risultati che voglio tornato sulla pagina "Log" della sezione amministrativa. Posso definire questo valore tramite i controlli sulla pagina ed è persistito tramite un cookie. Sono sempre e solo andando ad avere bisogno sul pagina di amministrazione e, come ora sappiamo, posso solo accedere alla pagina di amministrazione, se già autenticato che, seguendo i consigli nella sezione precedente, significa che avrò un cookie auth sicuro. Ma non significa che il cookie "ResultsPerPage" è sicuro:
Biscotti personalizzati non impostato su "sicuro" per impostazione predefinita
Ora, naturalmente, la necessità per il cookie per essere contrassegnato come sicuro è un fattore di informazioni protetto al suo interno. Anche se questo cookie non contiene informazioni sensibili, una migliore posizione di default su un sito abilitato TLS è quello di iniziare sicuro e questo può essere facilmente configurato tramite il file web.config:
< httpCookies requireSSL = " true " />
Una volta che la bandiera requireSSL è impostato, si ottiene la stessa protezione che siamo tornati nella sezione di autenticazione basata su form per il cookie di autenticazione:
Cookie impostato sicuro dopo impostandola esplicitamente nel codice
Questo costituisce ora una molto diversa, come il cookie viene goda della stessa sicurezza come il cookie di autenticazione in precedenza. Se la richiesta non è fatta tramite HTTPS, il cookie semplicemente non verrà inviato attraverso la rete. Ma questa impostazione significa che ogni cookie può essere inviato solo su HTTPS che significa che anche il cookie ASP.NET_SessionId non viene inviato su HTTP con conseguente nuovo ID di sessione per ogni richiesta. In molti casi questo non importa, ma a volte più granularità è richiesto.
Quello che possiamo fare è impostare il flag sicuro quando il cookie viene creato piuttosto che farlo a livello globale nel web.config:
var cookies = nuovo HttpCookie ( "ResultsPerPage" , "50" );
cookie.Secure = true ;
Response.Cookies.Add (cookie);
Anche se tu avessi davvero bisogno di fare questo quando è importante avere i cookies di altri che possono essere inviati attraverso HTTP, è bello avere la possibilità.
Solo una cosa più sui cookies, mentre siamo qui, e non è realmente legati al trasporto strato di protezione. Se il cookie non ha bisogno di essere richiesto da script lato client, assicurarsi che sia contrassegnata come HTTP solo . Quando si guarda indietro le informazioni del cookie in palio schermo, avrete notato che questo è impostato per l'. Cookies ASPXAUTH ma non per il cookie è stato creato da codice. L'impostazione di questo a "true" offre protezione contro malware lato client attacchi come XSS ed è altrettanto facile da attivare sia in tutto il sito nel web.config:
< httpCookies httpOnlyCookies = " true " />
O manualmente durante la creazione del cookie:
var cookies = nuovo HttpCookie ( "ResultsPerPage" , "50" );
cookie.HttpOnly = true ;
Response.Cookies.Add (cookie);
E 'basso costo di assicurazione e significa script client non possono più accedere ai cookie.Naturalmente ci sono momenti in cui si vuole accedere il cookie tramite JavaScript, ma ancora una volta, iniziare bloccato e aprire da lì, se necessario.

Chiedete MVC per richiedere SSL e link a HTTPS

Qualcosa che ASP.NET MVC rende estremamente semplice è la possibilità di richiedere i controllori o azioni per essere serviti solo su HTTPS, è solo un attributo semplice:
[ RequireHttps ]
 public class AccountController : controller
In un caso come il controller conto (questa è solo quello di default da un nuovo progetto MVC), non vogliamo che una delle azioni per essere servito su HTTP in quanto includono funzioni per il login, la registrazione e modifica delle password. Questo è un caso facile per decorare l'intera classe controller ma può essere utilizzato esattamente nello stesso modo nei confronti di un metodo di azione se più granularità è richiesto.
Una volta che abbiamo bisogno di HTTPS, qualsiasi richiesta HTTP sarà raggiunto con una (spostato temporaneamente) la risposta 302 e poi il browser reindirizzato alla versione sicura. Possiamo vedere questa sequenza di giocare in Fiddler :
Richiesta reindirizzamento HTTP a HTTPS quando il controllore ha l'attributo RequireHttps
Ma è sempre preferibile evitare redirect in quanto significa che il browser finisce per fare una richiesta aggiuntiva, più esso pone alcuni rischi per la sicurezza vedremo a breve. Un approccio preferibile è quello di collegare direttamente alla risorsa utilizzando lo schema HTTPS e nel caso di collegamento ad azioni di controllo, è facile passare nel protocollo attraverso uno degli overload:
@ Html.ActionLink ( "Collegamento" , "accesso" , "Account" , "https" , nullo , nullo , nullo , nullo )

Purtroppo il sovraccarico ActionLink solo che ha un protocollo ha anche un altro quattro parametri ridondanti, ma a prescindere, il risultato finale è che un URL assoluto utilizzando lo schema di HTTPS è emessa al markup:
< uno href = "https://localhost/Account/LogOn">
L'applicazione di entrambe queste tecniche offre il meglio dei due mondi: E 'facile da collegare direttamente al sicuro le versioni di azioni, più il controller arriva a giocare poliziotto e garantire che non è possibile aggirare HTTPS, deliberatamente o per caso.

Tempo limite di validità del token di autenticazione

Mentre stiamo parlando di difese facilmente configurabile, molto "rapida vittoria" - anche se non specifiche per TLS - è quello di garantire il periodo in cui un token di autenticazione valido è ridotto al minimo indispensabile. Quando abbiamo ridurre questo periodo, la finestra in cui la sessione potrebbe essere dirottato è ridotta.
Un modo per ridurre questa finestra è semplicemente quello di ridurre il timeout impostato nell'elemento autenticazione basata su form del web.config:
< forme loginUrl = " ~ / Account / LogOn " timeout = " 2880 " />
Mentre il valore predefinito in una nuova applicazione ASP.NET (sia MVC o moduli web) è di 2.880 secondi (48 minuti), riduzione di questo numero il valore minimo pratico offre un certo grado di sicurezza. Naturalmente è poi compromesso l'usabilità, ma questo è spesso l'equilibrio con cui lavoriamo nel settore della sicurezza (autenticazione a due fattori è un grande esempio di questo).
Ma anche i timeout brevi lasciare un persistente rischio, se il dirottatore fa entrare in possesso della sessione, possono solo continuare l'emissione di richieste fino a quando hanno finito con le loro attività dannose e faranno rimanere autenticato. Un modo per mitigare questo rischio - ma anche a costo di usabilità - è quella di disabilitare scorrevole di scadenza:
< forme loginUrl = " ~ / Account / LogOn " timeout = " 2880 " slidingExpiration = " falso " />
Ciò significa che, indipendentemente dal fatto che l'utente autenticato continua a spedire richieste o no, l'utente sarà disconnesso al termine del periodo di timeout, una volta che è registrato in questo tappi la finestra del rischio di dirottamento di sessione.
Ma il valore di entrambe queste impostazioni è maggiore quando non esiste TLS. Sì, le sessioni possono ancora essere dirottato TLS quando è a posto, ma è un pezzo aggiuntivo di sicurezza che è sempre bello avere in atto.

Sempre servire pagine di login su HTTPS

Una pratica abbastanza comune sui siti web è quello di visualizzare un modulo di login in ogni pagina. . Solitamente queste pagine sono servite su HTTP, dopo tutto, hanno solo un contenuto pubblico Singapore Airlines utilizza questo approccio in modo che durante la navigazione attraverso il sito, il modulo di login rimane in alto a sinistra dello schermo:
Singapore Airlines carico form di login su HTTP
Al fine di proteggere le credenziali in transito, hanno poi inviare ad un indirizzo HTTPS:
< form id = "headerLoginForm" azione = "https://www.singaporeair.com/kfHeaderLogin.form" metodo = "post">
Si pensi dello scenario form di login HTTP in questo modo:
Sequenza di pagina di login caricata su HTTP e HTTPS inviati ad
Questo metodo verrà crittografare le credenziali prima di postare, ma c'è un difetto molto importante nel disegno: è aperta ad un uomo in mezzo l'attacco . Un attacco MITM opere da parte di malintenzionati intercettare e manipolare la conversazione tra client e server. In precedenza ho spiegato che uno dei vantaggi offerti da TLS è che "garantisce che il contenuto non è stata manipolata in transito". Si consideri che nello scenario MITM seguenti:
Sequenza di pagina di login caricata su HTTP e HTTPS, mentre inviati ad essere copiati in un attaccante
Poiché il modulo di accesso è stato caricato su HTTP, è stato aperto a modifiche da parte di malintenzionati. Ciò potrebbe accadere in molti punti diversi tra il client e il server, gateway Internet del cliente, l'ISP, il fornitore di hosting, ecc Una volta che il modulo di accesso è disponibile per la modifica, l'inserimento, ad esempio, alcuni in modo asincrono JavaScript per inviare le credenziali al largo di sito di un aggressore può essere fatto senza che la vittima che sia il più saggio.
Questa non è roba da fantascienza, proprio questo scenario è stato svolto dal governo tunisino solo un anno fa:
L'Agenzia tunisina Internet (Agence tunisienne d'Internet o ATI) viene incolpato per la presenza di Javascript iniettato in grado di catturare nomi utente e password. Il codice è stato scoperto sulle pagine di login per Gmail, Yahoo e Facebook, e dice che sia la ragione della recente eruzione di dirottamenti conto riferito dai manifestanti tunisini.
E:
C'è un lato positivo però, come il codice JavaScript incorporato viene visualizzato solo quando uno dei siti si accede con HTTP anziché HTTPS. In ogni caso prova, siamo stati in grado di confermare che Gmail e Yahoo erano solo compromessa quando HTTP è stato utilizzato.
La mitigazione di tale rischio è semplicemente di non visualizzare le forme di accesso alle pagine che possono essere richieste via HTTP. In un caso come Singapore Airlines, ciascuna pagina deve essere servito su HTTPS o ci deve essere un link ad una pagina di login HTTPS.Non si può avere entrambe le cose.
OWASP si riferisce anche a questo rischio specifico nel foglio TLS barare in Usa TLS per tutte le pagine di accesso e tutte le pagine autenticati :
La pagina di login e tutte le pagine successive autenticate devono essere esclusivamente accessibile su TLS. La pagina di login iniziale, denominato "landing page di accesso", deve essere servito su TLS. Il mancato utilizzo di TLS per la pagina di destinazione di login permette ad un aggressore di modificare l'azione form di login, provocando le credenziali dell'utente per essere inviati ad una posizione arbitraria.
Molto chiaro davvero.
Ma c'è anche un difetto secondario con il caricamento di un modulo di accesso su HTTP poi inviando a HTTPS, non c'è possibilità di visitare il certificato prima di inviare dati sensibili. Per questo motivo, l'autenticità del sito non può essere verificata fino a quando è troppo tardi.In realtà, l'utente non ha alcuna idea se la sicurezza del trasporto saranno impiegati a tutti e senza vedere gli indicatori del browser usuale che TLS è presente, l'ipotesi sarebbe normalmente che non esiste TLS. Non c'è semplicemente niente visibile per indicare il contrario.

Cercate di non reindirizzare da HTTP a HTTPS

Uno dei rischi che rimane in un mondo HTTPS è come l'utente arriva per cominciare.Prendiamo un tipico scenario e guardare American Express. La maggior parte delle persone, quando si vuole accedere al sito digitare questo nella barra degli indirizzi del browser:
www.americanexpress.com
Tutti i browser di default questo indirizzo per utilizzare lo schema di richiesta HTTP in modo che in realtà fanno è:
http://www.americanexpress.com
Ma come potete vedere dal browser in basso, la risposta non utilizzare lo schema HTTP affatto, anzi torna con la pagina di destinazione (compresi impianti login) su HTTPS:
Il sito web di American Express dopo il reindirizzamento a HTTPS
Quello che succede qui è che Amex riceve la richiesta HTTP poi la restituzione di un HTTP 301 (moved permanently) risposta e chiedendo il browser per reindirizzarehttps://www.americanexpress.com/ . Possiamo vedere in questo Fiddler con la richiesta nella metà superiore dello schermo e la risposta in basso:
Il 301 risposta da American Express reindirizzamento a HTTPS
Perché la prima richiesta che viene fatta su HTTP è vulnerabile alla manipolazione nello stesso modo come l'esempio tunisino in precedenza in quella che può essere modificato in transito. In realtà non c'è niente di fermare un malintenzionato che è riuscito a manipolare la risposta di cambiare il redirect percorso (o qualsiasi altra parte della risposta) a qualcosa di completamente diverso o semplicemente risintonizzare una pagina HTTP con controlli di accesso modificati (ancora una volta, ripensare a Tunisia ). Tutto questo è semplicemente perché la sequenza richiesta iniziato più di un protocollo non sicuro.
E 'stato solo qualche anno fa che il rischio che questa pratica è stata portata sotto i riflettori da Moxie Marlinspike quando creò Striscia di SSL . Ciò che ci ha mostrato Moxie è la facilità con la quale la sicurezza dei trasporti può essere completamente rimosso da un MITM semplicemente intercettando che prima richiesta HTTP poi invece di permettere il reindirizzamento a HTTPS, inviando la risposta al client in HTTP proxy e quindi richiede al server su HTTPS. A meno che non esplicitamente cercando la presenza di HTTPS (che la maggior parte degli utenti non avrebbe consapevolmente fare), il percorso è stato pavimentato ad osservare le credenziali e altri dati sensibili inviati attraverso pianura vecchio protocollo HTTP non crittografato. Il video sul sito vale la pena di guardare e mostra quanto facilmente HTTPS può essere eluso quando si inizia con una dipendenza da HTTP (anche considerare questo nel contesto della sezione precedente sul caricamento dei moduli di login su HTTP).
In un mondo perfetto, la soluzione è quella di reindirizzare mai, il sito dovrebbe caricare solo se l'utente in modo esplicito digitato un URL che inizia con lo schema HTTPS mitigando così il rischio di manipolazione. Ma, naturalmente, che avrebbe un impatto significativo l'usabilità e chi ha tentato di accedere a un URL senza uno schema sarebbe andato da nessuna parte.
Fino a poco tempo, OWASP ha pubblicato una sezione intitolata Non eseguire il redirect da non-TLS TLS alla pagina di login (è ancora lì, proprio contrassegnati come "rimosso"). Il loro suggerimento è stato il seguente:
Si consiglia di visualizzare un messaggio di avviso di sicurezza per l'utente ogni volta che il non-TLS pagina di login è richiesto. Questo avviso di sicurezza deve spingere l'utente a digitare sempre "HTTPS" nel browser o il segnalibro la pagina sicura di login. Questo approccio contribuirà a informare gli utenti sulle modalità per un corretto e sicuro di accesso dell'applicazione.
Ovviamente questo ha un impatto notevole usabilità; che chiede all'utente di risalire alla loro barra degli indirizzi e modificare manualmente l'URL appare ridicolo in un mondo di hyperlink e redirect. Questo, purtroppo, è il motivo per il reindirizzamento HTTP per HTTPS modello rimarrà per qualche tempo ancora, ma almeno gli sviluppatori devono essere consapevoli del rischio. La mitigazione è disponibile solo per verificare la validità del certificato prima di fornire le proprie credenziali:
Ispezionare il certificato sul sito American Express

HTTP sicurezza dei trasporti severe

Una possibile soluzione ai rischi di servire contenuti su HTTP, che dovrebbe essere sicuro è la sicurezza del trasporto HTTP Strict , o HSTS in breve. Le specifiche HSTS rimane in forma di bozza, dopo essere inizialmente presentato IETF intorno alla metà dello scorso anno. La promessa della specifica proposta è che fornirà servizi per i contenuti ad essere contrassegnati come sicuri in modo che il browser capire e che non possono essere manipolati da parte di malintenzionati.
Tende da essere il modo con il web, non avendo una specifica ratificato non è motivo di evitare l'uso del tutto. In realtà è comincia ad essere supportata dai browser principali, soprattutto Chrome, che ha adottato già nel 2009 e Firefox, che ha preso a bordo all'inizio di quest'anno. Come è spesso il caso, altri browser - come Internet Explorer e Safari - ancora non lo supportano a tutti e semplicemente ignorare l'intestazione HSTS.
Così come HSTS lavoro? Una volta che riceve un browser che supporti questa intestazione tornato da una richiesta HTTPS (non possono essere restituiti su HTTP - che ora sappiamo non può essere attendibile - o il browser lo ignorano), sarà solo questione le richieste successive a tale sito nel corso degli HTTPS schema. L'intestazione "Strict-Transport-Security" restituisce anche un attributo "max-age" in pochi secondi e fino a quando questo periodo è scaduto, il browser automaticamente tradurre le richieste HTTP in HTTPS versioni con lo stesso percorso. Applicare HTTPS e sostenendo HSTS può facilmente essere realizzato in un app ASP.NET, non è niente più che un colpo di testa. Il vero lavoro è fatto sulla fine browser che poi prende la responsabilità di non rilasciare le richieste HTTP a un sito già contrassegnato come "Strict-Transport-Security". Infatti il browser fa la propria versione interna di un HTTP 301, ma perché non siamo affidamento su questa risposta tornare su HTTP, non è vulnerabile agli attacchi MITM abbiamo visto in precedenza.

L'intestazione HSTS e reindirizzamento forte al sistema HTTPS può sia essere facilmente implementato in caso Application_BeginRequest del global.asax:
protected void Application_BeginRequest ( Object sender, EventArgs e)
{
  interruttore (Request.Url.Scheme)
  {
    caso "https" :
      Response.AddHeader ( "Strict-Transport-Security" , "max-age = 300" );
       pausa ;
     caso "http" :
       var path = "https://" + + Request.Url.Host Request.Url.PathAndQuery;
      Response.Status = "301 Moved Permanently" ;
      Response.AddHeader ( "Location" , percorso);
       pausa ;
  }
}
Con questo luogo in, diamo uno sguardo al HSTS in azione. Quello che sto per fare è impostare il link al foglio di stile del sito di usare esplicitamente HTTP in modo che appaia così:
< collegamento href = "http://localhost/Content/Site.css" rel = "stylesheet" 
tipo = "text / css" />
Ora ecco cosa succede quando faccio una richiesta HTTP al sito con Chrome:
HSTS causando una richiesta HTTP da inviare su HTTPS
E questa è l'intestazione della risposta della seconda richiesta:
L'attributo "Strict-Transport-Security" nell'intestazione di risposta
Ci sono tre cose importanti da notare:
  1. Richiesta 1: La richiesta HTTP è risposto con un reindirizzamento HTTP 301 me per il regime di HTTPS per la stessa risorsa.
  2. Richiesta 2: HTTPS redirect dal punto precedente restituisce l'intestazione "Strict-Transport-Security" nella risposta.
  3. Richiesta 6: Questo è il foglio di stile che è stato esplicitamente incorporato con un collegamento assoluto utilizzando lo schema di HTTP, ma come si può vedere, il browser ha convertito questo l'utilizzo di HTTPS prima ancora della rogatoria.
Tornando all'esempio originale in cui i pacchetti inviati tramite HTTP sono stati fiutati, se l'accesso fosse stato su HTTPS e HSTS è stato utilizzato, sarebbe stato impossibile per il browser per l'emissione di richieste su HTTP per i prossimi 500 secondi anche se esplicitamente chiesto di fare così. Naturalmente questa struttura poi impedisce qualsiasicontenuto che deve essere servito su HTTP, ma in molti casi, è proprio questo lo scenario che stai cercando di raggiungere.
Un commento finale sulla HSTS, o meglio il concetto di costringere le richieste HTTPS, anche se l'intestazione "Strict-Transport-Security" non viene restituito dal server, è ancora possibile garantire le richieste vengono inviati solo su HTTPS utilizzando il protocollo HTTPS Everywhere plug-in per Firefox. Questo plugin simula il comportamento di HSTS ed esegue un redirect del browser alla versione sicura di contenuti per i siti che hai specificato come TLS-only. Naturalmente il sito deve ancora sostenere HTTPS in primo luogo, ma dove lo fa, la HTTPS Everywhere plugin garantire tutte le richieste vengono emessi attraverso una connessione sicura. Ma alla fine questa è solo una mitigazione è possibile eseguire come unutente su un sito web, non come sviluppatore .

Non mescolare TLS e non-TLS contenuti

Questo potrebbe sembrare un problema minore, ma il caricamento di una pagina su TLS poi anche non-TLS contenuti realmente causa alcuni problemi abbastanza importanti. Dal punto di vista puramente tecnico, significa che la non-TLS contenuti possono essere intercettati e manipolati. Anche se è solo una singola immagine, non hai più certezza di autenticità, che è uno dei valori chiave che TLS offre.
Ma il problema più evidente è che questo sarà ben presto essere portate a conoscenza degli utenti della pagina web. L'implementazione differisce da browser a browser, ma nel caso di Chrome, ecco cosa succede quando il contenuto è misto:
Il sito Qantas carico contenuto misto e causando un avvertimento del browser
Cancellando l'icona del lucchetto e lo schema HTTPS nella URL, il browser invia un avvertimento molto chiaro per l'utente - non fidatevi di questo sito! La fiducia che hai costruito con l'utente è molto rapidamente lacerato solo con l'inclusione di un singolo asset non-TLS sulla pagina. L'avvertimento nel pannello Info certificato è al di sopra chiaro: si sta richiedendo risorse insicura e non possono essere di fiducia per fede.
E questo è tutto quello che serve - una risorsa. In caso Qantas ', possiamo facilmente vedere questo controllando il contenuto in Fiddler. C'è solo una singola richiesta di circa 100 che viene caricato su HTTP:
Una piccola richiesta sul sito Qantas causa l'errore
E che cosa avrebbe giustificato sacrificare TLS correttamente attuata? Solo un piccolo file Flash promozione Secret Santa:
Il contenuto offensivo sul sito della Qantas - Secret Santa
Più probabile che non si tratta di una svista da parte loro ed è qualcosa di rimanere vigili circa quando costruire le tue applicazioni. Il problema più grande ciò pone è che una volta che si avvia desensibilizzazione agli utenti di avvisi di protezione, c'è un rischio reale chelegittimi gli avvisi vengono semplicemente ignorati, e questo molto rapidamente erode il valore espresso dal TLS.
Mentre HTTPS misti e contenuto HTTP è un problema facilmente risolvibile quando tutto il contenuto è servito dal sito uno, rimane una sfida costante durante l'incorporazione di contenuti da risorse esterne. In effetti alcune persone sostengono che questo è uno dei motivi per cui il web non è passato a SSL-solo ancora . Per esempio, Google AdSense non supporta la versione SSL dei loro annunci . Non essendo in grado di visualizzare pubblicità generatori di entrate sta per essere un affare-interruttore per alcuni siti e se si affidano a incorporare questi annunci sulle pagine autenticata, alcune decisioni difficili e, infine, di sacrifici sia di sicurezza o di dollari, avranno bisogno di essere fatte.
Ma non è solo cattive notizie e di molti servizi esterni non forniscono alternative HTTPS per garantire questo non è un problema. Per esempio, Google Analytics funziona bene su HTTPS come fa il pulsante tweet di Twitter . Ironia della sorte, che è attualmente ultimo anello ritornando contenuto misto se stesso:
Twitter ritorno contenuto misto e causando un avvertimento del browser
Si va solo a dimostrare che di base come il concetto è, anche i grandi sbagliano.

I dati sensibili ancora non sotto l'URL

Un meccanismo di persone tendono ad utilizzare regolarmente per mantenere i dati su tutte le richieste è quello di passare intorno tramite stringhe di query in modo che l'URL ha tutte le informazioni è necessario per elaborare la richiesta. Per esempio, di nuovo nella parte 3 diautenticazione rotto e la gestione delle sessioni ho mostrato come l'attributo "cookie" dell'elemento di autenticazione basata su form nel web.config potrebbe essere impostata su "UseUri" che causa la sessione di essere mantenuta attraverso l'URL, piuttosto che utilizzando i cookie. Significa l'indirizzo finisce per guardare qualcosa di simile:
Il passaggio di dati sensibili (informazioni di sessione) nell'URL
Nell'esempio che ho mostrato come questo significava l'URL potrebbe quindi essere riutilizzato altrove e la sessione dirottato. Transport Layer Security cambia nulla in questo scenario.Perché l'URL contiene dati sensibili può ancora essere passata ad un altro partito - sia attraverso il social engineering o la condivisione semplice - e la sessione dirottato.
OWASP parla anche di mantenere i dati sensibili fuori dell'URL e identifica rischi aggiuntivi nel foglio trucco SSL. Tali rischi includono la possibilità di caching della pagina (inclusi gli URL) sul computer dell'utente e il rischio di essere passato l'URL nella intestazione del referrer quando si collegano da un sito TLS ad un altro. Chiaramente l'URL non è il posto giusto per mettere tutto ciò che è o sensibili, o, nel caso del dirottamento di sessione esempio di cui sopra, potrebbero essere utilizzati per eseguire attività dannose.

La (mancanza di) impatto sulle prestazioni di TLS

Il processo di crittografia e decrittografia dei contenuti sul web server non è libero - ha un prezzo prestazioni. Gli oppositori di applicare TLS liberamente sostengono che questo impatto sulle prestazioni è di importanza sufficiente che per i siti di scala, il costo può anche andare oltre la semplice procurarsi un certificato e opportunamente configurare l'applicazione.Potenza di elaborazione supplementare può essere richiesto per supportare TLS in cima alla testa esistenti di far girare le applicazioni su HTTP.
C'è un precedente eccellente che sfata questa teoria: la mossa di Google per TLS solo per Gmail. All'inizio dello scorso anno (prima della comparsa di Firesheep), Google ha effettuato la chiamata che tutte le comunicazioni tra Gmail e il browser dovrebbe essere garantita con TLS. Nel white paper intitolato Verisign proteggendo gli utenti da Firesheep e altri attacchi Sidejacking con SSL , Google è citato come dicendo quanto segue riguardo l'impatto sulle prestazioni della decisione:
Per fare questo abbiamo dovuto installare nessuna macchina aggiuntivo e senza hardware speciale. Sulla nostra produzione front-end macchine, SSL / TLS rappresenta meno dell'1% del carico della CPU, a meno di 10KB di memoria per connessione e meno del 2% di overhead di rete. Molte persone credono che SSL prende un sacco di tempo di CPU e speriamo che i numeri sopra (pubblico per la prima volta) contribuirà a dissipare questo.
Mentre l'esatto impatto è discutibile e sicuramente sarà diverso da caso a caso, l'esempio di Google mostra che TLS è dovunque realizzabile in quasi assenza di sovraccarico delle prestazioni.

TLS rottura

Come ogni difesa che applichiamo nella sicurezza informatica, TLS sé non è immune da essere rotto o sovvertita. Abbiamo esaminato i meccanismi per aggirarlo andando a monte di richieste sicuro e attaccando a livello HTTP, ma per quanto riguarda l'infrastruttura di certificazione stessa?
Solo qualche mese fa abbiamo visto come TLS vulnerabili può essere per gentile concessione di DigiNotar . L'autorità di certificazione olandese ha dimostrato che un crollo sistemico nei loro sicurezza interna potrebbe aprire la strada ad un malintenzionato di rilasciare certificati perfettamente legittimo per artisti del calibro di Google e Yahoo! Non è la prima volta che una CA è stata compromessa; Comodo sofferto un attacco all'inizio di quest'anno nella ormai famigerata Comodo-gate incidente in cui è stato violato uno dei loro affiliati e dei certificati rilasciati per Skype e GMail, tra gli altri.
Intorno allo stesso tempo come la situazione DigiNotar, abbiamo visto anche l'emergere di BESTIA , il Browser Exploit contro SSL / TLS. Quale bestia ci ha mostrato è che una vulnerabilità insita nella versione corrente accettato di TLS (1,0), potrebbe consentire a un utente malintenzionato di decifrare i cookie criptati del calibro di PayPal. Non era un attacco semplice con qualsiasi mezzo, ma ha dimostrato che i difetti esistono in luoghi che nessuno si aspettava potesse essere effettivamente sfruttate.
Ma la realtà è che ci rimane diversi modi per rompere TLS e non devono sempre coinvolgere il compromesso di una CA. Questo lo rendono "insicuro"? No, lo rende imperfetto, ma nessuno è in procinto di sostenere che non offre un vantaggio significativo rispetto pianura comunicazione vecchio HTTP. Al contrario, TLS ha un sacco di sinistra vita e continuerà ad essere una pietra angolare della sicurezza Web per molti anni a venire.

Riassunto

Corretta attuazione strato di protezione di trasporto all'interno di una web app è un sacco di informazioni per prendere a bordo e non ho nemmeno toccare molti degli aspetti importanti dei certificati stessi, forza la crittografia (128 bit, 256 bit), Extended Validation , la protezione privata chiavi, ecc
Sicurezza dei trasporti resta una di quelle misure che, pur indubbiamente vantaggiosa, è anche lontana dal infallibile. Questo commento da Moxie Marlinspike nel video sulla pagina Striscia SSL è testimonianza di quanto sia fragile HTTPS può effettivamente essere:
Un sacco di volte che la sicurezza di HTTPS scende per la sicurezza di HTTP e HTTP non è sicuro
Qual è la soluzione? Molte persone stanno dicendo la responsabilità dovrebbe ricadere DNS in modo che i siti che dovrebbero essere serviti solo su connessioni sicure sono designate al di fuori dello strato di trasporto e quindi meno soggetto a manipolazioni. Ma allora DNS non è infallibile.
In definitiva noi, come sviluppatori, può funzionare solo con gli strumenti a nostra disposizione e certamente ci sono molti modi si può ridurre il rischio di protezione insufficiente livello di trasporto. Ma, come per gli altri posti di questa serie, non è possibile ottenere le cose perfette e più si capisce su tali vulnerabilità potenziale, meglio attrezzati si sta per trattare con loro.
Per quanto riguarda il sito web ASafaWeb, avrete ora osservare un certificato gratuito StartSLL sulla pagina di login che, naturalmente, viene caricato su TLS. Inoltre ho sempre navigare direttamente verso l'indirizzo HTTPS tramite segnalibro prima autenticazione. E non è poi così difficile.