ARCHIV

Bezpečnosť webovej aplikácie III.

Tak, po nejakom období som napísal ďalšiu časť nášho malého seriálu. V tejto časti si ukážeme ako správne spravovať relácie užívateľov, ukradnutie identity a maskovanie identity cez proxy.

11.4.2012 00:00 | Marek Beleščiak | Články autora | přečteno 6572×

Session Management

Session Management je spôsob akým sa spravujú relácie užívateľov. Kedže vďaka http protokolu server nevie identifikovať klienta, ten musí odoslať cookies, aby sa identifikoval. Pokiaľ vám to stále nič nehovorí, zamyslite sa, čo sa asi stane keď sa na nejakej stránke prihlasíte - ako server ďalej vie, že ste to práve VY ? Pri prihlásení vám server poslal identifikátor, ktorý mu pri každej požiadavke posielate naspäť.

Čo ak ale identifikátor, ktorý dostanete je slabý, spätne ľahko vygenerovaľný, popr. zmeniteľný tak aby sa za vás mohol hocikto prihlásiť bez toho aby vedel údaje ?

Ako vždy najlepšie je si uviesť príklad takéhoto zistenia, hacknutia a zmenenia identity.

Frank a Sony boli kamárati. Jedného dňa sa ale strašne pohádali. Frankov koníček bola bola webová bezpečnosť tak sa rozhodol, že sa Sonymu pomstí. Vedel, že Sony najradšej navštevuje stránku example.com a takže tam mal aj veľa osobných a citlivých informácií. Frank tam nikdy nebol, zato však vedel, že Sonyho meno je Sony225.

Frank neváhal ani sekundu. Zaregistroval sa na example.com ako Frank001 a keď sa prihlásil, pozrel si identifikátor:

Tvar mu veľmi pripomínal base64, vedel ale, že bude najskôr obrátený pretože base64 má rovnítka na konci. Preto ho obrátil a skúsil dešifrovať ako base64, jeho výsledok bol nasledujúci:

Vyzeralo to ako hash, a veľa mu to nevravelo. Keď prehodil hex na znaky na nič nové neprišiel. Vytvoril si preto ešte dva nové účty Frank002 a Frank003. Porovnal si hashe všetkých troch účtov:

Hashe boli skoro rovnaké. Nezhodovali sa len v ôsmom byte:

Frankovy bolo hneď jasné, že ten rozdiel robia práve číslice 1,2,3. Vyzeralo to na XOR-ovú šifru, bolo mu hneď jasné, že ten hash je vlastne užívateľské meno prehodené do hexu a každý byte nejak zašifrovaný. Preto si zostavil malý skript, ktorý vyskúšal všetky možné kombinácie šifry (nebolo ich tak veľa je to v rozmedzí 0-255) na znak 0x7F, pokiaľ by daná šifra fungovala aj na ostatné byty, má vyhrané.

Skript ho nesklamal. Vrátil mu hodnotu 0x4E. Keď celý ten hash rozxoroval číslom 0x4E vysledok bol nasledovný:

Teraz už Frank vedel, že je veľmi blízko. Zaxoroval si reťazec "Sony225@example.com", zakódoval do base64 a obrátil. Výsledok bol:

Keď si potom vo svojom prehliadači zmenil cookie na túto hodnotu a navštívil example.com, bol už prihlasený za Sonyho a pomsta mohla začať.

Záver

Session hijack není zrovna najľahší typ útoku ale jeho následky sú drvivé. Identifikátory by mali byť jedinečné, rozhodne by sa nemali zakladať na údajoch používateľa. Ak by sa nejaký užívateľ prihlásil aj viac krát, vždy by mal dostať rozdielny identifikátor. Pokiaľ je to možné, relácia by sa mala zamykať na IP adresu. Takže ak by ste boli prihlasený pod 192.168.1.100 a niekto z adresy 192.168.1.101 by poslal presne váš identifikátor, tak by jednoducho neprešiel.

Proxy a maskovanie identity

Proxy je server ktorý stojí medzi koncovým užívateľom a serverom. Podstata je v tom, že užívateľ pošle požiadavku proxy serveru, ten koncovému serveru, koncový server vráti údaje proxy serveru a ten pôvodnému užívateľovi. Takto sa dá pomerne ľahko "schovať", pretože vy ako užívateľ nekomunikujete so serverom, ten nevie vašu IP ale vie len IP proxy servera. Na internete môžte nájsť tisícky takýchto servrov, dávajte si ale pozor na súkromie. Ľahký postup ako si zapnúť proxy je spustiť terminál nastaviť si http_proxy premennú. Napr. export http_proxy="http://127.0.0.1:8080/" potom si môžte spustiť cez terminál svoj prehliadač a ten už bude bežať cez proxy (overený len chrome).

O čo vlastne ide

Klient pri posielaní požiadavky môže uviesť hlavičku "X-Forwarded-For" kde sú IP adresy počítaču/ov pre ktoré danú požiadavku posiela. Vlastne o sebe tvrdí, že je proxy a posiela adresu originálneho klienta. Táto hlavička sa dá ale veľmi ľahko zmeniť. To znamená, že pokiaľ web používa na zistenie reálnej ip adresy spôsob podobný tomuto, robí veľmi zle. Nemôžete totižto slepo dôverovať dátam ktoré môžu byť fiktívne. V praxi, ale niektoré proxy servery robia to, že adresu v hlavičke X-Forwarded-For si úplne vymýšlajú resp. posielajú náhodne vygenerovanú. Anonymné proxy túto hlavičku vôbec neposielajú.

Keby ste tejto hlavičke dôverovali a brali ju tak ako skript hore, všetky opatrenia ktoré máte napr. 'zablokovanie ip po 100 neúspešných pokusoch o prihlásenie' alebo 'hlasovanie je možné jednej ip adresy!' strácajú zmysel, navyše všetko, kde dáte túto ip môže byť mylné. Veď, čo môže byť lahšie ako si napísať skript, ktorý automatický bude náhodne generovať túto hlavičku a robiť za vás špinavú robotu ? Niekedy však táto hlavička môže byť užitočná. Rozhodne je ale lepšie dôverovať len tej pravej ip adrese, aj ked niekedy je možno lepšie vedieť čo najviac informácií, ak je to tak, osobne by som navrhol ukladať aj ip klienta aj ip v tejto hlavičke - najlepšie čo najkratšie, čize v 4roch bytoch.

Dúfam, že som vám stručne a jasne objasnil problematiku s generovaním uživateľských relacií a taktiež problematiku okolo pracovania, používania a vydávania sa za proxy komunikovanie s proxy servermi.

Verze pro tisk