Nella parte finale di questa serie vedremo il rischio di un redirect non convalidati o in avanti.Poiché questo è il rischio ultimo della Top 10, è anche il minimo rischio. Mentre per nulla innocuo, la metodologia OWASP Valutazione del rischio ha determinato che si svolge l'ultima in ordine.
La pratica del redirect non validati e indietro, spesso indicato come un "open redirect", appare piuttosto benigno sulla superficie. Tuttavia, può facilmente essere impiegato in combinazione con una combinazione di ingegneria sociale e altre attività dannose come ad esempio un sito web fraudolento progettato per ottenere informazioni personali o servire malware.
Che unvalidated reindirizzamento non fa altro che permette ad un aggressore di sfruttare la fiducia che un utente in un dominio particolare utilizzando come trampolino di lancio per un altro arbitrario, sito probabilmente dannoso. Anche se questo ha il potenziale per fare danni considerevoli, è anche una vulnerabilità contenzioso che alcune organizzazioni consapevolmente scelgono di lasciare aperta. Diamo un'occhiata a come funziona, come sfruttarlo quindi come proteggersi.
Definizione unvalidated redirect e in avanti
Questo è in realtà un rischio estremamente semplice da rilevare e gli exploit contro di essa può verificarsi in un certo numero di modi diversi. In qualche modo, sfruttando in realtà è molto simile a come si potrebbe affrontare un sito che è vulnerabile alle falle XSS abbiamo guardato indietro nel parte 2 di questa serie.
Ecco come OWASP riassume:
Applicazioni web spesso in avanti e reindirizzare gli utenti ad altre pagine e siti web, e utilizzare i dati attendibili per determinare le pagine di destinazione. Senza la corretta convalida, gli aggressori possono reindirizzare le vittime di phishing o siti di malware o utilizzare in avanti per accedere alle pagine non autorizzate.
Infatti la radice del problema è esattamente quello che stavamo guardando indietro nelle prime due parti della serie: dati non attendibili. Diamo un'occhiata a questa definizione daparte 1 di nuovo:
Dati non attendibili provengono da qualsiasi fonte - diretto o indiretto - in cui l'integrità non è verificabile e intenti potrebbe essere dannoso. Ciò include l'inserimento manuale utente, come i dati dei moduli, l'input dell'utente implicita come intestazioni di richiesta e l'input dell'utente costruita come le variabili stringa di query. Considerare l'applicazione di una scatola nera e tutti i dati che entrano per essere non attendibili.
OWASP definisce il rischio come segue:
| Minaccia agenti | Attacco di Vettori | Debolezza di sicurezza | Tecnico Impatti | Affari Impact | |
| SfruttabilitàMEDIA | PrevalenzaUNCOMMON | RilevabilitàFACILE | ImpattoMODERATO | ||
| Considerare chi può ingannare i tuoi utenti in presentazione di una richiesta al tuo sito web.Qualsiasi sito web o altra alimentazione HTML che gli utenti utilizzano potrebbe fare questo. | Link attaccante non validati per reindirizzare le vittime e trucchi in clic su di esso.Le vittime sono più propensi a cliccare su di esso, dato che il link è a un sito valido.Attaccante obiettivi pericoloso in avanti per bypassare i controlli di sicurezza. | Applicazioni più reindirizzare gli utenti ad altre pagine, oppure utilizzare avanti interno in un modo simile. A volte la pagina di destinazione è specificato in un parametro non convalidati, che consente agli aggressori di scegliere la pagina di destinazione.Rilevare redirect incontrollato è facile. Cercare redirect dove è possibile impostare l'URL completo.Avanti incontrollato sono più difficili, dal momento che obiettivo pagine interne. | Redirect ad esempio può tentare di installare malware o ingannare le vittime a rivelare password o altre informazioni sensibili.Pericoloso in avanti può permettere il controllo di bypass di accesso. | Si consideri il valore di business di mantenere la fiducia degli utenti '. Che se ottengono di proprietà di malware? Che cosa succede se gli aggressori possono accedere a funzioni interne solo? | |
Quindi stiamo cercando una combinazione di dati non attendibili con l'inganno, o ciò che comunemente conosciamo come ingegneria sociale. Il risultato di tutto questo potrebbe essere il malware, furti di dati o la divulgazione di altre informazioni a seconda degli obiettivi dell'attaccante. Diamo uno sguardo a come tutto questo avviene.
Anatomia di un attacco non convalidati redirect
Facciamo un requisito abbastanza tipico: si sta costruendo un sito web che contiene collegamenti ad altri siti fuori al di fuori del vostro controllo. Nulla di strano in questo, ma si desidera tenere traccia di quali effettivamente collegamenti sono seguiti e registrare i click-through.
Ecco cosa la prima pagina del sito si presenta così:
Ci sono un paio di cose degne di nota sottolineare;
- Il dominio: supponiamo noi riconosciamo e la fiducia il fittizio mytrustedsite.com (ho aggiornato il mio file hosts per puntare a un sito Web IIS locale) e che vedendo questo nome host in un discorso ci dà fiducia la legittimità del sito e dei suoi contenuto.
- L'URL di destinazione del collegamento ipertestuale: potete vedere in basso nella barra di stato che lo lega al largo di una pagina chiamata Redirect.aspx con un parametro stringa di query denominata URL e un valore di http://troyhunt.com
Quello che sta succedendo qui è abbastanza auto-esplicativo, in realtà questo è il motivo per cui tutto è così facile rilevabilità. Ovviamente una volta che fai clic sul collegamento ci aspettiamo di vedere qualcosa del genere:
Ora immaginiamo che abbiamo visto un link a questo dominio attraverso un canale, come Twitter. Potrebbe sembrare qualcosa di simile:
Al meglio un osservatore casuale può dire, questo è un collegamento perfettamente legittimo. Esso stabilisce la fiducia e la credibilità del nome di dominio è riconoscibile, non c'è motivo di sfiducia e di tutti gli effetti, cliccando sul link verrà caricato contenuti legittimi sul mio sito di fiducia. Tuttavia:
Vedi il problema? E 'molto sottile e in effetti è lì che il cuore dell'attacco si trova: La barra degli indirizzi mostra che anche se abbiamo cliccato su un URL che chiaramente aveva il nome host del mytrustedsite.com , siamo ora in myuntrustedsite.com . Cosa c'è di più, c'è un modulo di accesso che chiede le credenziali che ci si aspetta naturalmente sarebbe stato gestito correttamente date le circostanze. Chiaramente questo non sarà il caso, in questo caso.
Bingo. Un unvalidated redirect ha appena permesso di rubare le credenziali di qualcuno.
Ciò che ha reso possibile tutto questo?
Si tratta di un attacco semplice e chiaramente è stato reso possibile da un URL artigianale come questo:
http://mytrustedsite.com/Redirect.aspx?Url=http://myuntrustedsite.com
Il codice dietro la pagina prende semplicemente il parametro URL dalla stringa di query, esegue alcune registrazione arbitrario quindi esegue un redirect che invia una risposta HTTP 302 al browser:
var url = Request.QueryString [ "Url" ]; LogRedirect (url); Response.Redirect (url);
L'attacco è stato reso più credibile dal sito maligno avere un URL simile a quello di fiducia e il visual design essere coerente (anche se entrambe le implementazioni del campione). Non c'è niente che si può fare per l'URL simili o il branding coerente, tutto quello che resta è il controllo del comportamento nel codice sopra.
Assunzione di responsabilità
Prima di entrare bonifica, c'è un argomento che la sequenza di attacco al di sopra non è proprio la responsabilità del sito attendibile. Dopo tutto, non è il sito maligno che sta rubando le credenziali?
In primo luogo, l'attacco di cui sopra è soltanto una realizzazione di un redirect non convalidati. Una volta che è possibile controllare dove un URL legittima può atterrare un utente innocente, un intero mondo di altre opzioni aprirsi. Per esempio, che potrebbe facilmente essere stato un collegamento a un file eseguibile maligno. Un utente fa clic sul collegamento viene poi chiesto di eseguire un file. Anche in questo caso, stanno facendo clic su un noto, l'URL di fiducia così la fiducia di legittimità è alto. Tutte le UAC in tutto il mondo non cambia questo fatto.
La capacità di eseguire questo tipo di attacco tramite il vostro sito è la vostraresponsabilità, perché è il tuo marchio che poliziotti il peso di eventuali ricadute. "Ehi, ho caricato un link da mytrustedsite.com ora il mio PC è infetto." Non è una buona occhiata e si ha un interesse in questo scenario non giocare sul tuo sito.
Whitelist sono ancora importanti
Tornando a quella prima parte della serie di nuovo, ho fatto una dichiarazione molto enfatico che ha dichiarato: "Tutti gli input devono essere convalidati contro una whitelist di intervalli di valori accettabili ". Questo è ancora valido per i reindirizzamenti non validati e indietro ed è la chiave di come stiamo andando a mitigare questo rischio.
In primo luogo, il codice nel frammento precedente su eseguita alcuna convalida dei dati non attendibili (la stringa di query), sorta. Il primo porto di scalo dovrebbe essere quello di garantire che il parametro URL è infatti un URL valido:
var url = Request.QueryString [ "Url" ], se (! Uri IsWellFormedUriString (url,. UriKind Assoluto).) { / / Con garbo uscita con un messaggio di avviso }
In realtà questa è la prima parte della nostra convalida whitelist perché siamo confermando che i dati non attendibili è conforme al modello previsto di un URL. Più su quello posteriore nella parte 2.
Ma naturalmente questo non fermerà l'attacco da prima, anche se attenua notevolmente il rischio di XSS. Ciò di cui abbiamo veramente bisogno è una whitelist di URL ammissibile che i dati non attendibili possono essere convalidati. Ciò esistere da qualche parte nella memoria persistente, come un file XML o un database SQL. In quest'ultimo caso, la convalida whitelist con Entity Framework sarebbe simile a questa:
var db = nuovo MyTrustedSiteEntities (), se (!. db.AllowableUrls.Where (u => u.Url == url) Qualsiasi ()) { / / Con garbo uscita con un messaggio di avviso }
Questo è abbastanza autoesplicativo, se l'URL non esiste nel database, la pagina non lavorati. Nella migliore delle ipotesi, tutto un aggressore può fare è manipolare la stringa di query con altri URL già nella whitelist, ma ovviamente assumendo questi URL sono affidabili, non c'è alcun vantaggio da guadagnare.
Ma c'è anche un altro approccio che possiamo prendere, che offre un maggior grado di offuscamento dell'URL per essere reindirizzati alla manipolazione ed esclude del tutto.Tornato a parte 4 ho parlato insicuro riferimenti oggetto diretto e ha mostrato il rischio creato utilizzando identificatori interni in modo pubblicamente visibile. La risposta è stata di utilizzare le mappe di riferimento indiretto che sono semplicemente un modo di esporre un identificatore pubblico di nessun significato logico che ha risolto di nuovo ad un identificatore privato internamente l'applicazione. Ad esempio, invece che inserire un numero di conto corrente in una stringa di query, una stringa temporanea e crittograficamente casuali potrebbe essere usato che poi mappata sul conto internamente bloccando così a chiunque di manipolare i numeri di conto semplicemente nella stringa di query (cioè loro incremento).
Nel caso di reindirizzamenti non convalidati, non abbiamo bisogno di avere l'URL nella stringa di query, proviamo in questo modo:
http://mytrustedsite.com/Redirect.aspx?Id=AD420440-DB7E-4F16-8A61-72C9CEA5D58D
L'intero codice sarebbe quindi simile a questa:
var id = Request.QueryString [ "Id" ]; Guid idGuid, se (! Guid . TryParse (id, fuori idGuid)) { / / Con garbo uscita con un messaggio di avviso } var db = nuovo MyTrustedSiteEntities (); var = allowableUrl db.AllowableUrls.SingleOrDefault (u => u.Id == idGuid), se (allowableUrl == nullo ) { / / Con garbo uscita con un messaggio di avviso } LogRedirect (allowableUrl.Url); Response.Redirect (allowableUrl.Url);
Quindi siamo ancora convalidando il tipo di dati (non più di tanto sarebbe successo con un GUID non valida in ogni caso!) E stiamo ancora controllando contro una whitelist, l'unica differenza è che c'è un po 'più di protezione contro la manipolazione e la divulgazione prima ancora di risolvere l'ID di un URL.
Implementazione referente verifica
In un caso come l'esempio in precedenza, l'unica volta che il redirect ha alcun tipo di finalità è legittima quando è utilizzato all'interno del sito, che è un'altra pagina sui link dello stesso sito ad esso. Lo scopo maligno abbiamo visto coinvolti accedere alla pagina di reindirizzamento dal di fuori del sito, in questo caso seguendo un link da Twitter.
Un meccanismo molto semplice, possiamo implementare il redirect è quello di verificare l'intestazione del referrer il browser aggiunge ad ogni richiesta. In questo caso suona un po 'estero, ecco le informazioni di intestazione il browser invia quando facciamo click che link originale sulla prima pagina del sito, quello legittimo, che è il seguente:
Questo è stato catturato con Fiddler e si può vedere qui che il sito che di cui questa richiesta è stato il nostro sito attendibile. Ora diamo un'occhiata a quel referrer dal nostro attacco dannoso via Twitter:
L'indirizzo referrer è URL shortener di Twitter sul dominio t.co. Il nostro sito di fiducia riceve questa intestazione e, di conseguenza, si può leggere e agire di conseguenza. Facciamo una prova:
var referer = Request.UrlReferrer; var = thisPage Request.Url; se (referente == nulla ! | | referrer.Host = thisPage.Host) { / / Con garbo uscita con un messaggio di avviso }
Questa è una soluzione molto semplice che le regole immediatamente qualsiasi ulteriore opportunità di sfruttare il reindirizzamento non convalidato rischio. Ovviamente significa anche che non potrà mai deep link direttamente alla pagina di reindirizzamento da una risorsa esterna, ma in realtà, questo non è qualcosa che stai normalmente andando a voler fare comunque.
Offuscamento di intenti
In precedenza abbiamo guardato al seguente URL:
http://mytrustedsite.com/Redirect.aspx?Url=http://myuntrustedsite.com
Hai solo bisogno di leggere il singolo parametro di stringa di query e l'intento malizioso abbastanza rapidamente diventa chiaro. Supponendo, naturalmente, è possibile visualizzare l'URL completo e non è stato tagliato come nell'esempio Twitter precedenti, non dovrebbe essere abbastanza facile per gli utenti finali a identificare che qualcosa non è giusto?
Andiamo un po 'più creativo:
http://mytrustedsite.com/Redirect.aspx?Foo=xLv8WUcipP6WQLnNyA6MQzyFfyFNqCcoe&Bar=deyZWmQ4dbRtFTEDWczt72D&Url=%68%74%74%70%3a%2f%2f%6D%79%75%6E%74%72%75%73%74%65%64%73%69%74%65%2E%63%6F%6D&Foo2=CMVDnzwpWzp3PtMFJUvCwX6bxr8ecFyy&Bar2=UYuu2XRcQUKzt3xYfemWHM6HNKt
Questo eseguirà nella esattamente allo stesso modo come l'URL precedente, ma l'intento è stato offuscato da una combinazione di parametri ridondanti stringa di query che distogliere l'attenzione da quello maligno combinato con codifica URL di reindirizzamento valore che lo rende completamente illeggibile. Il punto è che non si può aspettare anche gli utenti più diligente per individuare un potenziale invalidato riorienta l'attacco incorporato in un URL.
Nel caso in cui questo suona molto teorico, è proprio l'attacco che è stato montato contro di eBay qualche tempo fa. In realtà questo attacco particolare rispecchiato il mio esempio da più indietro in termini di utilizzare un URL offuscato con il dominio eBay per poi reindirizzare ad un sito arbitrario con marchio eBay e chiesto le credenziali (si noti l'URL). Prendete questo indirizzo:
http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&DomainUrl=http%3A%2F%2F%32%31%31%2E%31%37%32%2E%39%36%2E%37%2FUpdateCenter%2FLogin%2F%3FMfcISAPISession%3DAAJbaQqzeHAAeMWZlHhlWXS2AlBXVShqAhQRfhgTDrferHCURstpAisNRqAhQRfhgTDrferHCURstpAisNRpAisNRqAhQRfhgTDrferHCUQRfqzeHAAeMWZlHhlWXh
Che reindirizzato a questa pagina:
E il gioco è fatto: non convalidati redirect sfruttati in natura.
Unvalidated contesa redirect
Nonostante il potenziale sfruttamento e l'impatto di questo rischio è ampiamente noto, continua a verificarsi in molti siti che dovrebbero conoscere meglio. Google è uno di questi e di una ben congegnata URL come questo resta vulnerabile:
http://www.google.com/local/add/changeLocale?currentLocation=http://troyhunt.com
Ma abbastanza interessante, Google sa su questo ed è felice di lasciarlo. In realtà essi esplicitamente escludere reindirizzamento URL dal programma di vulnerabilità la loro ricompensa . Vedono alcuni vantaggi nel apertamente permettendo non validati redirect e chiaramente non percepiscono questo come un rischio vale la pena preoccuparsi:
Di conseguenza, il pannello ricompensa sarà probabilmente ritengono report URL di reindirizzamento come non-qualifica: mentre noi preferiamo mantenere il loro numero sotto controllo, riteniamo che i benefici usabilità e la sicurezza di un piccolo numero di ben implementati e redirector URL attentamente monitorati tendono a prevalere i rischi percepiti.
L'attuale caso d'uso di Google che consente questa pratica non è chiaro: è possibile che ci sia un motivo legittimo per consentire esso. Google gestisce anche un vasto impero dei servizi consumati in tutti i tipi di mode e, mentre ci possono essere usi di nicchia per questa pratica, lo stesso può essere detto di rado maggior parte delle applicazioni web.
Eppure, la loro difesa della pratica sembra anche un po 'debole, soprattutto quando sostengono un exploit di successo dipende dal fatto che dell'utente "non sarà sufficiente essere attenti a esaminare il contenuto della barra degli indirizzi dopo la navigazione avviene". Come abbiamo già visto, URL simili o quelli offuscati con gli altri parametri stringa di query può facilmente ingannare anche gli utenti diligente.
Redirect unvalidated tendono a manifestarsi più spesso di quanto ci si aspetterebbe per un tale rischio facilmente mitigato. Ho trovato uno su hp.com proprio la settimana scorsa, ironia della sorte, mentre a seguito di un link al loro strumento di sicurezza WebInspect :
http://www.hp.com/cgi-bin/leaving_hp.cgi?cc=us&lang=en&exit_text=Go%20to%20troyhunt.com&area_text=Newsroom&area_link=http://www.hp.com/hpinfo/newsroom/index.html&exit_link=http://troyhunt.com
Non so se HP prendere la stessa posizione come Google o no, ma chiaramente questo non sembra essere loro preoccupante (anche se il rischio XSS potenziale del parametro "exit_text" probabilmente dovrebbe).
Riassunto
Completamento della Top 10 con la vulnerabilità più basso rischio che anche Google non prende sul serio è quasi un po 'deludente. Ma è chiaro che c'è ancora possibilità di utilizzare questo vettore di attacco per ingannare gli utenti a rivelare informazioni o l'esecuzione di file con il presupposto che sta eseguendo questa attività su un sito legittimo.
La posizione di Google non dovrebbe farti compiacenti. Come con tutti i precedenti 9 rischi che ho scritto su, la sicurezza continua ad essere di circa stesa in strati di difesa per l'applicazione. Spesso, uno strato da solo presenta un singolo punto di guasto che possono essere evitati in modo proattivo l'attuazione difese multiple, anche se olisticamente possano sembrare ridondante.
In definitiva, unvalidated redirect sono facili da difendere. È probabile che la vostra applicazione non sarà nemmeno presentano questo comportamento per cominciare, ma se lo fa, la convalida whitelist e referenti controllo sono entrambi meccanismi molto semplici per fermare questo rischio morto nella sua tracce.
Nessun commento:
Posta un commento