Quando si parla per la nostra sicurezza personale, siamo cresciuti tutti un po 'abituati amantenere le cose sul down-bassa . Ad esempio, coprire la tastiera del bancomat quando si entra il nostro PIN e distruggere i nostri documenti sensibili piuttosto che gettarli direttamente nella spazzatura.
Noi non farlo perché ogni pezzo unico di informazione sta per portarci annullata, ma piuttosto cerchiamo di non trasmettere tutto ciò che può essere utilizzata per trarre vantaggio da noi.Questo PIN può essere utilizzato con la carta per prelevare contanti se qualcuno prende le mani su di esso (o ha un dispositivo di skimming ) e che estratto conto si gettano nella spazzatura potrebbe essere utilizzato da qualcuno come leva per il furto di identità.
E così è con le intestazioni di risposta, quei piccoli bocconcini di informazioni la vostra applicazione è sciolto lasciando in libertà che probabilmente non aveva nemmeno dato un secondo pensiero. Sulla superficie, si tratta di dati innocui non serve a nessuno, ma scavare un po 'più profondo e all'improvviso diventa molto utile per i malvagi.
Perché è importante?
Lasciatemi fare un esempio: si sta crociera con il vostro sito nella sua configurazione di default per quanto riguarda gli header sono il che significa che un mucchio di informazioni sul sito viene inviato in ogni risposta. Sembra probabilmente come qualcosa di simile (catturati utilizzando Fiddler ):
Questo è da una delle pagine demo su telerik.com ma potrebbe benissimo essere da quasi qualsiasi sito web là fuori esegue la configurazione predefinita di MVC 3 e. NET 4 utilizzando IIS 7.5. Ma appendere - questo è in realtà un sacco di informazioni da sapere su un sito, soprattutto quando è tutto implicitamente comunicate (vale a dire non è mai stato probabilmente l'esplicita intenzione degli sviluppatori di divulgare questo).
Continuando il nostro esempio ipotetico, un giorno, un ricercatore si apre a una conferenza sulla sicurezza e mostra come un nuovo zero-day attacco può essere utilizzata per sfruttare IIS. Cosa c'è di più, la vulnerabilità è specificamente con IIS 7.5. E solo quando è in esecuzione ASP.NET 4.
Suona troppo ipotetico? Una cosa molto simile è accaduto proprio l'altro giorno , ed è successo un certo numero di volte prima che troppo. Il livello di specificità è spesso diversa (potrebbe essere semplicemente "tutto IIS" che è vulnerabile), ma probabilmente si può vedere da dove questo sta iniziando ad andare ora: i siti web che pubblicizzano la loro scelta di server web e application framework anche pubblicizzare la loro sensibilità quando le vulnerabilità si trovano.
Ma è qualcosa di più che semplici vulnerabilità, come si potrebbe sfruttare alcune caratteristiche di una versione di un quadro può essere diversa a un'altra versione. Ad esempio, modifiche nella richiesta di convalida. NET 4,5 significherà l'angolo si potrebbe prendere per testare le vulnerabilità XSS potrebbe cambiare. Conoscere la versione del framework in anticipo ti dà un grande inizio ha avuto in termini di quale approccio si potrebbe prendere quando si ha il cappello sul malfattore.
Contention e altre implicazioni
Molte persone contestare che questo non è necessario, "security through obscurity", faranno gridare. Non proprio - questo termine di solito è usato per suggerire che una determinata pratica di mantenere qualcosa dal punto di vista è l'unica cosa in piedi tra un sistema "sicuro" e un crollo totale della cauzione di cui sopra. Mettere tutti i contenuti di amministrazione sotto "/ MyHiddenAdmin" poi non l'implementazione dei controlli di accesso - ora che è oscuro!
Non broadcasting intestazioni ci riporta a quella originale esempio di come gestiamo gli aspetti della nostra sicurezza personale. Non si tratta di fare una applicazione web "sicura" come se fosse una pratica per domarli, no, non si tratta di mantenere le informazioni che potrebbero essere utilizzati come parte di un più ampio attacco un po 'tranquillo.
L'altro pro-header-offuscamento argomento è che semplicemente non è necessario trasmetterà queste informazioni. Voglio dire, non viene utilizzato in alcun modo funzionale dal browser e, alla fine della giornata sei solo l'invio di ulteriori byte lungo il filo che nessuno ha veramente bisogno. Oh - e lo si invia giù con ogni singola risposta il server invia. E 'piccola, ma è inutile e che sta per avere un impatto negativo sulle prestazioni piccola.
Non siete ancora convinti? Date un'occhiata a ciò che l'IETF (Internet Engineering Task Force) ha da dire in RFC 2068 :
Rivelare la versione specifica del software del server possono consentire che la macchina server a diventare più vulnerabili agli attacchi contro il software che è noto per contenere buchi di sicurezza. Implementers dovrebbe rendere il campo di intestazione Server un'opzione configurabile.
In più troverete anche la IIS Lockdown strumento di formulare raccomandazioni per trasformare queste intestazioni off. Chiaramente la guida dalle persone che dovrebbero conoscere è quello di mantenere le cose un po 'tranquillo.
Ma alla fine della giornata, una delle ragioni convincenti per non trasmettono le intestazioni è che è morto facile per spegnerli. Forse sarà utilizzata in un attacco contro il vostro sito un giorno non, forse si, ma se si tratta di pochi minuti per spegnerli e si risparmia qualche byte in ogni risposta, cosa c'è da perdere?
Headers non è intestazioni
Non tutte le intestazioni sono stati creati uguali e il modo in cui li spegne all'interno dello stack Microsoft è diverso. Ricapitoliamo su quelli che abbiamo visto in precedenza su:
- Server: Il software del server web in esecuzione dal sito. Esempi tipici sono "Microsoft-IIS/7.5", "nginx/1.0.11" e "Apache".
- X-Powered-By: La raccolta (ci possono essere molteplici) dei quadri di applicazioni in esecuzione dal sito. Tipici esempi sono: "ASP.NET", "PHP/5.2.17" e "UrlRewriter.NET 2.0.0".
- X-aspnet, Version: Ovviamente un colpo di testa solo ASP.NET, tipici esempi includono "2.0.50727», «4.0.30319» e «1.1.4322».
- X-AspNetMvc-Version: Ancora una volta, si vedrà solo questo nello stack ASP.NET e gli esempi tipici sono "3.0", "2.0" e "1.0".
Cominciamo con il server e in questo caso, il valore viene ovviamente direttamente tramite IIS. Ora tenere a mente IIS non devono essere in esecuzione ASP.NET, si potrebbe essere in esecuzione PHP o node.js o anche solo pagine html direttamente vecchi. Chiaramente non stiamo andando a disabilitare l'intestazione del server in qualsiasi punto all'interno la nostra configurazione di ASP.NET se vogliamo disattivarlo per tutti questi quadri.
Ma prima di iniziare a provare a cambiare le cose fuori, creiamo una linea di base, qui sono le intestazioni di un nuovo ASP.NET MVC 3 app installato e funzionante sul mio IIS locale:
Ora, di nuovo al server. Il modo più semplice per sbarazzarsi di tale intestazione server di fastidioso e di garantire che rimanga andato in tutti i vari quadri IIS verrà eseguito è quello di installare UrlScan . Questo strumento farà un sacco di cose diverse per voi in giro come IIS gestisce le richieste, ma per oggi, dobbiamo solo di accendere un editor di testo e dare un'occhiata al file di configurazione che si trova in C: \ Windows \ System32 \ inetsrv \ urlscan \ UrlScan.ini. Quello che vogliamo fare è trovare l'impostazione "RemoveServerHeader" e configurarlo per essere "1". Diamo un'occhiata a queste intestazioni ora:
Non più server!
Quando si tratta di X-Powered-By, questa è in realtà facilmente configurabile direttamente fuori dalla scatola in IIS 7.x, salta a destra nella configurazione di IIS del sito web e individuare la voce "le intestazioni HTTP di risposta":
E da lì è abbastanza auto-esplicativo:
Passando alla versione di ASP.NET, questo è un pezzo di torta, perché è semplicemente un elemento di configurazione nel file web.config:
< system.web > < httpRuntime enableVersionHeader = " falso " /> </ system.web >
La versione MVC è anche facile, anche se ci richiede di toccare il codice. Nel corso del Global.asax, vogliamo saltare l'evento Application_Start e aggiungere il seguente:
MvcHandler DisableMvcResponseHeader =. true ;Molto semplice, e con tutti questi a posto ora abbiamo tagliato le intestazioni giù quindi non c'è assolutamente nulla di eventuali interessi a sinistra:
Un po 'side-nota prima di procedere: ci sono molti modi diversi di fare la stessa cosa. Ad esempio, alcune cose un po 'diverse in IIS 6. Poi ci sono approcci come Howard van Rooijen di "CloakIIS" che avvolgono il tutto in un unico gestore (anche se ho personalmente avuto risultati contrastanti con questo approccio). Alcuni di questi possono essere più difficile o più facile a seconda della versione di IIS, ASP.NET e il modello di hosting si utilizza (per esempio se UrlScan è ancora disponibile). In definitiva però, è un mezzo per un fine, e se questo fine significa che queste intestazioni non vengono trasmesse, poi però ci si avvicina è bene.
Controllo delle intestazioni con ASafaWeb
Perché questa è una di quelle vittorie facili in lo "sforzo contro ricompensa" ROI della sicurezza, sono andato avanti e costruire una scansione delle intestazioni eccessivi in ASafaWeb . Che cosa significa è che la scansione di un sito come l'esempio Telerik da prima ora restituisce un avviso in questo modo:
Perché un avvertimento? Non è semplicemente alla stessa stregua dei rischi di configurazione gravi come esporre le tracce dello stack o tronchi ELMAH. Infatti, in termini di gravità è più come l'ASafaWeb altro avviso raccoglie attualmente up - il reindirizzamento HTTP a HTTPS.In entrambi i casi, essere consapevoli del rischio, capire, tentare di attenuare, ma se non puoi, non è un biggie.
Un breve commento sul ASafaWeb perché ho appena sanno che una persona da qualche curioso alzerà questo: asafaweb.com restituisce un colpo di testa server. Il problema in questo caso è che ASafaWeb risiede sul molto eccellente AppHarbor servizio di hosting e di essere un vero modello di cloud hosting, ha alcuni elettrodomestici intelligenti di rete bilanciamento del carico seduti di fronte a dei server web. Per quanto mi sforzassi di rimuovere o modificare l'intestazione server, è in fase di aggiunta di nuovo a valle del server web che presumo che sta accadendo verso l'apparecchio di fronte dei server.
Riassunto
Tutto questo ci riporta al mantra di applicare la protezione a strati. Si tratta di mitigazione del rischio in ogni occasione e nel caso di queste intestazioni, è morto facile rimuoverli fornendo così un vantaggio piccolo ma tangibile. Ci saranno quelli che respingere questa pratica (anzi, mi sono imbattuto in molti quando cerca di materiale per questo post), ma francamente, a meno che non può articolare un rovescio della medaglia (che io non ho visto espresso), non c'è alcun motivo per non mettere a nudo queste intestazioni fuori.
