67% dei siti Web ASP.NET hanno gravi vulnerabilità di sicurezza di configurazione relativi

In realtà, è ancora peggio - è davvero 67,37% - ma cerchiamo di non spaccare il capello oltre che in questo momento. Il punto è che è un numero spaventosamente alto per quello che equivale a vulnerabilità di configurazione molto semplici. I numeri sono per gentile concessione di ASafaWeb , l'analizzatore automatico di sicurezza per i siti web ASP.NET, che è uno scanner gratuito on-line su asafaweb.com .

Quando ho costruito ASafaWeb, l'ho progettato dalla terra fino a anonimamente registrare risultati della scansione. L'anonimato significa che non so quali siti vengono scansionati o che sta facendo la scansione, ma io non so il risultato di ogni scansione che mi permette di aggregare questi in alcuni dati significativi.

Lasciate che vi guiderà attraverso questi risultati e offrire un po 'di comprensione da dove le cose vanno male, quando siti Web ASP.NET vengono pubblicati. Speriamo che questo sarà un po 'di "call to action", che aiuta gli sviluppatori a capire dove potrebbero aver bisogno di fare un po' di tweaking nelle loro applicazioni.

Analisi

Per prima cosa, l'analisi esclude quanto segue:

1. Esegue la scansione sul sito di prova ASafaWeb .
2. Esegue la scansione di siti non identificati come un sito web ASP.NET (questo è identificato dalle intestazioni di risposta, tutte le pagine di errore idonei a rivelare il quadro o la presenza dello stato di visualizzazione sul sito). Naturalmente è possibile - anzi è auspicabile - che le intestazioni non esporre queste informazioni, ma è anche estremamente raro.
3. Esegue la scansione eseguito prima 1 gennaio di quest'anno o dal 1 aprile in poi (lo chiamano quarto pulito). Tutti i risultati sono da gennaio / febbraio / marzo.

Quello che voglio fare è dare un quadro di come il vostro sito web media ASP.NET è configurato in modo tale criterio di filtro è molto importante. Portate via queste cose e ora abbiamo un campione di 7.184 scansioni da analizzare.

Una cosa da tenere a mente è che le scansioni ASafaWeb non sono infallibile; falsi positivi accadere. Non molto, intendiamoci, ma è un fattore. Un altro fattore è che le scansioni sono state migliora come vari casi limite o opportunità generali di miglioramento sono identificati.Ad esempio, la settimana scorsa ho aggiunto il supporto per messaggi di errore in altre lingue. Prima di allora - e inclusi nel campione nelle statistiche in questo post è venuto da - uno schermo classico giallo della morte in tedesco non sarebbe stato classificato come un errore.

Allo stesso modo, proprio questo fine settimana ho aggiunto un po 'di intelligenza in giro per il modo in cui si verificano le scansioni contro gli URL con un percorso sotto di loro. Il problema è che quando si vede un URL come http://mysite.com/foo, non so se foo è la radice delle app o se si deve andare tutta la strada al proprio dominio. Se è la radice app, questo è il percorso in cui le risorse, come il tracciamento e l'ELMAH sarà trovato, ma se non lo è, si è salire di un livello. E devi farlo senza fare eccessivi (e molto costoso) le richieste HTTP.Tricky.

Quindi il punto è che questi numeri sono dalla parte conservatrice.

Errori personalizzati e le tracce dello stack

Quando si parla di errori personalizzati in un certo senso di sicurezza, ci sono in realtà due distinte questioni di cui stiamo parlando:

1. L'nodo customErrors del web.config hanno l'attributo mode impostato su "On" o "RemoteOnly". In caso contrario, avremo una schermata giallo della morte con stack completo .
2. L'nodo customErrors del web.config la defaultRedirect impostato su una pagina valida.

In altre parole, è lo schermo giallo della morte (YSOD) fare una comparsa. Come di aggiornamento per chi ha familiarità con ASP.NET e una breve introduzione per coloro che non lo sono, ecco quello che una pagina di errore simile quando entrambe le voci di cui sopra non sono configurati correttamente:

Ora il grosso problema con il messaggio di errore è al di sopra che stiamo fuoriuscita di codice interno al mondo esterno. Questo dà un attaccante un enorme vantaggio in quanto possono cominciare a sondare l'applicazione e scoprire come la cosa è mettere insieme che a sua volta equipaggia meglio a identificare le vulnerabilità. In particolare in applicazioni in cui la gestione degli errori è scarsa (come lanciare dati non attendibili a un tipo particolare, senza un "try-parse" approccio style), questo è un grave rischio.

Ma scorrere verso il basso un po 'più e c'è anche questo:

Ora, questo risale a un recente post dal titolo Shhh ... non lasciate che i vostri header di risposta parlare a voce troppo alta . In questo post ho parlato del rischio se la divulgazione di informazioni di cose come IIS, ASP.NET MVC e le versioni tramite le intestazioni. Non importa quanto in silenzio si configurano le intestazioni, se il vostro errore personalizzato non sono configurati si sta andando ad essere fuoriuscita di informazioni sulla versione comunque.

In questo scenario, il web.config è effettivamente dichiarare gli errori personalizzati come questo:

< customErrors mode = " Off " />

Ruotando gli errori personalizzati off, le bolle di errore interni fino al browser e il sito è in senso figurato sorpreso con i pantaloni calati intorno alle sue caviglie. Accensione errori personalizzati sulle cose migliora, ma non da un sacco:

Ok, quindi l'analisi dello stack e implementazione interna del codice è andato, ma stiamo ancora rivelare che l'applicazione non può gestire la richiesta: è un'eccezione in senso letterale e non gestita, e che è solo conoscenze sufficienti per iniziare un ulteriore sondaggio.

Ecco cosa vogliamo veramente vedere:

< customErrors mode = " On " defaultRedirect = " ~ / Error.aspx " />

Quando un reindirizzamento di default è definito, si finisce con qualcosa di più simile a questa:

Ora, naturalmente, che normalmente si basa questo sul modello del tuo sito ed essere un po 'più amichevole su di esso - come ho fatto con ASafaWeb - ma si ottiene l'idea. Definendo la pagina vorremmo l'applicazione di servire quando le cose vanno male, evitiamo di rivelare il fatto che l'errore non viene gestita. Siamo in grado di configurare gli errori personalizzati per servire le pagine di errore diversi in base a diversi codici di stato HTTP (si potrebbe desiderare di gestire una "Pagina non trovata" 404 in modo diverso, per esempio), ma fintanto che YSOD non sta facendo un aspetto, che è quello che stiamo a parlare qui.

Ci sono altri scenari in cui avere gli errori personalizzati avanti senza un default reindirizzare drammi cause. Ad esempio, un paio di anni fa abbiamo avuto l'intera questione padding oracle che conducono a Scott Guthrie fornire indicazioni molto esplicito :

Non è sufficiente per attivare semplicemente CustomErrors o hanno impostato a RemoteOnly.

Anche se l'episodio è ora veramente bene e dietro di noi, serve come un piccolo promemoria che è necessario mantenere le applicazioni bloccate non nel miglior modo possibile solo per proteggere contro le vulnerabilità che conosciamo oggi, ma quelli che devono ancora fare un aspetto. Ho visto anche molti rapporti di penetration tester e gravi aziendali grado dinamici strumenti di analisi di sicurezza che chiamano tutto questo, insistendo sul fatto che non YSODs fanno la loro comparsa indipendentemente dal fatto che sono accompagnati da una traccia dello stack o meno.

Un'ultima cosa: il UX di un YSOD fa schifo! Dare una bella pagina di errore amichevoli e mantenere gli utenti più felice di quello che sarebbe altrimenti quando qualcosa va storto.

Questa lunga introduzione è stato quello di impostare il contesto, perché non configurato correttamente gli errori personalizzati è dove la parte del leone dei problemi mentire. Diamo un'occhiata:

Relativamente questo ritorno al preambolo su come funziona errori personalizzati, il 16% dei siti li hanno spenti del tutto, mentre un altro 32% li hanno acceso, ma non hanno una pagina di reindirizzamento di default definito. Questo è enorme - stiamo parlando di quasi la metà di tutti i siti web ASP.NET che hanno una tale configurazione di base fondamentalmente sbagliato.

Richiesta di convalida

Avanti è la convalida della richiesta o, come mi piace fare riferimento ad esso, . NET piccola rete di sicurezza XSS . La convalida delle richieste così com'è oggi (e cambia un po 'domani), significa che una richiesta con un carico potenzialmente dannoso, ad esempio che si può trovare in un attacco XSS riflettenti (di solito) il divieto di esecuzione. Ad esempio:

Nota: la stringa di query nell'URL - ASP.NET ha intrappolato così presto e ha deciso che è una cattiva notizia quindi la pagina di errore (anche se ovviamente questo sarebbe normalmente reindirizza a una pagina di errore amichevole). La cosa grandiosa di convalida della richiesta è che anche se si sa assolutamente niente di XSS (che è uno scenario allarmante comune), c'è un certo livello di difesa offerti dal framework.

Prima che qualcuno diventi troppo arrogante sui meriti di convalida richiesta, non è un sostituto per il tipo di pratiche mi parla in parte 2 della mia serie di OWASP. sviluppatori NET , vale a dire la convalida whitelist e la codifica di uscita corretta. Ciò che fa è esattamente quello che ho accennato in precedenza, ti dà una rete di sicurezza se altre buone pratiche vengono ignorati.

Richiesta di convalida è attivata per impostazione predefinita e si deve esplicitamente disattivare nel file web.config per disattivarlo:

< pagine validateRequest = " falso " />

Oppure disattivare a livello di pagina:

<% @ Pagina Language = "C #" ValidateRequest = "false" %>

Perché fate questo? Uno dei casi d'uso più comuni per farlo è quello di permettere tag HTML per essere inviati al server, ad esempio quando si utilizza un editor di testo RTF.Naturalmente questo è un caso d'uso perfettamente valido, ma si tratta di rischi ...

Il che ci porta direttamente al DotNetNuke. Vedete DNN si spegne tutto il sito, perché ogni singola pagina è un po 'mini sistema di gestione dei contenuti. Ottengo che - c'è un comprensibile caso d'uso per questo - ma significa anche che ricevono i loro asini proverbiali consegnato loro da vulnerabilità XSS semplici che altrimenti sarebbero catturati da la convalida delle richieste.

Allora, qual è la risposta a un problema come DNN di? Utilizzare ASP.NET 4.5. Aspetta - che cosa?! Stiamo per ottenere alcuni miglioramenti molto importanti in tutto il supporto per le richieste non convalidate il che significa che un prodotto come DNN sarà in grado di lasciare la convalida della richiesta acceso ma richiesta di accedere ai dati specifici di una chiamata "non validati", che non invoca la convalida delle richieste. Questo significa che possono lasciarlo acceso e ottenere che la tutela implicita grazie a caratteristiche come la ricerca, ma non ho capito nel modo del loro CMS.

Ma ci sono molte, molte occorrenze di sviluppatori poco ripieno up. Essi spegnerlo attraverso il sito, perché una caratteristica admin poco è stato bloccato o che ripetono ciecamente la guida forum senza capire l'impatto. Per questo motivo i risultati simile a questa:

La prima cosa che si può notare qui è che la dimensione del campione è più piccolo - quasi la metà. Questo si spiega in parte nel titolo e causa del modo in forme siti web di gestire la convalida della richiesta, è facile solo per aggiungere un payload maligno per la stringa di query come ho fatto a immagine del browser in precedenza. Questo viene processato e richiesta di convalida (si spera) incendi. Non così con MVC (o, ovviamente, un sito web HTML puro), quindi a meno che ci sia stato di visualizzazione in formato sorgente del sito, questo test non viene eseguito.

Hash DoS

Chi si ricorda DoS hash ? Solo un po 'più di tre mesi fa, questo era il exploit dimostrato da ricercatori in Germania, oltre che significava un ben fatto richiesta HTTP POST con una grande collezione di variabili form appositamente costruiti potrebbe causare alcuni piuttosto gravi collisioni hash. Il problema con le collisioni hash è che sono computazionalmente costosi e se è possibile causare abbastanza di loro, il server inizia ad avere problemi a fare le cose in realtà è destinata a fare. La linea di fondo era che appena un singolo cura artigianale richiesta HTTP potrebbe chiudere le cose. Ouch!

Microsoft ha reagito rapidamente e rilasciato e rilasciato MS11-100 , un critico out-of-bandpatch. Ora che po '"out-of-band" è importante, in genere Microsoft rilascia una serie di patch per il secondo Martedì di ogni mese che è diventato noto come Patch Martedì . Le organizzazioni IT si aspettano questo e si organizzano attorno a gestire queste versioni. Per Microsoft di rilasciare una patch out-of-band significa che ci vuole molto, molto seriamente, tanto che non vedono l'ora possibile fino a quando la patch Martedì prossimo.

Questo rende il grafico che segue un po 'straordinario:

Ci sono alcune avvertenze con questo risultato in quanto è un po 'difficile da provare: in primo luogo, la scansione viene eseguita inviando 1.001 variabili di form sul sito, più di quanto la soglia è prima la patch calci e causa un errore di uno che è quello che noi' stavi cercando di accertare è stato installato. In secondo luogo, l'oggetto Request.Form deve essere accessibile in modo che questo evento si verifichi. Questo avverrà in modo implicito in una web app forme, ma in un'applicazione MVC, è dipendente dalla realizzazione del sito.

In breve, le scansioni MVC significano un sacco di avvertimenti, dove ASafaWeb essenzialmente scuse e dice: "Io non sono sicuro" così ho in base ai risultati puramente intorno ai siti web delle forme. Dato che si siede su un modello identico ad altri siti di hosting ASP.NET e abbiamo una buona dimensione del campione, l'elevata percentuale di computer senza patch dovrebbe riflettersi su tutta la linea comunque.

Ma naturalmente ci aspettiamo un sacco di siti a fallire molto presto come padroni di casa si precipitò per rattoppare i loro sistemi. Dopo tutto, questa è stata rilasciata proprio alla fine di dicembre quando le macchine di patching di solito non è la prima cosa nella mente degli amministratori maggior parte dei server. Vediamo come il tasso di fallimento è cambiato nel tempo:

Così abbiamo avuto il ritrovamento era inizialmente previsto ad alto contenuto di Jan, ma la cosa sorprendente è che nei due mesi successivi il tasso di fallimento di questa scansione è ancora molto elevata - 42% in realtà. In realtà c'è anche un incremento infinitamente piccolo da febbraio a marzo (circa 0,2%), così chiaramente ci sono un sacco di server restanti senza patch. Un po 'la gente di richiesta HTTP, che è tutto quello che serve ...

ELMAH

Il tutto ELMAH situazione della sicurezza è interessante. Per il familiare, lo stesso ottimi moduli Errore di registrazione e la biblioteca gestori è un modo popolare di catturare e rivedere gli errori che si verificano sul tuo sito web ASP.NET. Io lo uso molto in ASafaWeb me (tra l'altro).

Pochi mesi fa ho scritto su di sessione ASP.NET dirottamento con Google e ELMAH che, in breve, ha mostrato che vi sono stati molti, molti siti che espongono i registri ELMAH - che naturalmente, sono individuabili da Google - che contengono informazioni sufficienti per consentire di prendere sulla sessione di un altro utente autorizzato. In realtà, questo è solo l'inizio, perché non c'è abbastanza informazioni nei registri ELMAH a fare ogni sorta di altre cose nefasti.

C'è una panoramica completa di ciò che è in ELMAH nel link sopra, ma questa istantanea vi dà un senso rapido del livello di dettaglio che si può ottenere:

Comunque, la cosa che rende questo uno particolarmente interessante è che la guida di sicurezza sul sito ELMAH era sbagliato (da allora è stato posto rimedio), e se seguite lascerebbe comunque il ELMAH registra accessibile. Ovviamente si tratta di una situazione molto spiacevole e di conseguenza ci sono un sacco di siti web ELMAH abilitati là fuori che pensano di essere sicuro, ma non lo sono. Poi di nuovo, ci sono molti che non solo molto nemmeno pensato!

Ecco cosa ASafaWeb ha trovato:

Il numero totale di scansioni è un po 'inferiore rispetto a risultati precedenti, come il test ELAMH è stato aggiunto un certo punto del 4 gennaio% assomiglia ad un piccolo numero, ma si consideri anche che nel grande schema delle cose, ELMAH è installato solo in una piccola numero di siti web ASP.NET. Quale percentuale di questi non sono sicuri? 20%? 30%? Non sono sicuro, ma so che è una significativa parte dei siti che implementano ELMAH.

Tracciato

Se devo essere onesto, sono piacevolmente sorpreso da questo risultato:

Mentre è arrotondato a 0%, ci sono stati in realtà 34 scansioni che trovate lasciato su.Tracing è la sicurezza aziendale piuttosto seria saggia, che si presenta ogni sorta di succosi pezzi di informazioni, molte delle quali abbiamo visto di nuovo durante la scansione ELMAH:

Variabili del server, web form controllo della struttura, versione quadro e la tempistica degli eventi. Cose utili sia ai buoni e cattivi, ma per fortuna molto raramente esposta, secondo le statistiche.

Riassunto

Ecco la cosa con ogni singolo delle risultanze di cui sopra: sono assolutamente morto semplice da risolvere. Non si tratta di riscrivere il codice o ri-architecting siti web, si tratta di ottenere un paio di piccole impostazioni di configurazione di destra (e di assicurare il vostro ospite mantiene il loro ambiente patch nel caso di hash DoS).

Questo è uno di quelli " da grandi poteri derivano grandi responsabilità "scenari; ASP.NET è un ambiente incredibilmente potente che permette di fare cose incredibili con facilità, ma che la facilità si estende anche alla configurabilità e crea l'opportunità di lasciare buchi nei siti web senza neanche accorgersene.

Questo è un altro tema comune che vedo - gli sviluppatori che completamente e assolutamente capire tutto quello scritto sopra, ma ancora hanno siti vulnerabili. Ci vogliono solo un piccolo errore nelle trasformazioni di configurazione o di qualche distrazione quando il test e basta, lei è spalancata. Inoltre non c'è prova visiva della vulnerabilità esposta - si deve andare a cercare questi specificamente nel sito e la realtà è che questo non sempre avviene.

ASafaWeb è stato costruito per identificare le vulnerabilità in modo rapido e automatico e da tutti gli account, è trovato un sacco di loro. Ma c'è molto di più a venire - siti web non rimanere statica e controllare il vostro sito con un una tantum di scansione è buono per oggi, ma domani? Io non ho intenzione di rivelare troppo in questo momento, ma ci sara 'una soluzione molto elegante a questo proprio dietro l'angolo. Per ora, controllare il vostro sito e assicurarsi che nessuno di coloro po 'semplice - ma potenzialmente gravi - le configurazioni sono mancanti.

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla