Musím sa priznať. Začiatkom víkendu som sa opätovne pohrával s vybrali.sme.sk, aby som ukázal jeho správcom, že je skutočne potrebné aktualizovať na novú verziu. Výsledkom môjho štvorminútového snaženia bol skript, ktorý automaticky hlasoval za vybraný článok pri načítaní môjho blogu.
Z mojej strany však šlo len o potvrdenie koncepcie, že staršie verzie pliggu, teda aplikácie, ktorá poháňa vybrali.sme.sk, nemajú dostatočnú ochranu pred týmito druhmi “útoku”, nazývaného aj CSRF (Cross-site Reuquest Forgery). Reakcia správcu bola veľmi zaujímavá, večer už koncepcia nefungovala, pretože dotyčný pridal overovanie refereru.
Referer, alebo HTTP referer, identifikuje zdrojovú webovú stránku, z ktorej návštevník prišiel. Referer je prenášaný za pomoci prehliadača, pričom každý nový prehliadať túto funkciu má zabudovanú a len u niekoľkých je ju možné vypnúť. Vďaka refereru je potom možné zistiť, z akej stránky užívateľ prišiel a pri vyhľadávačoch, aké kľúčové slová hľadal, keď sa dostal na váš web. Referer je veľmi populárny pri “boji” proti CSRF útokom, čo však výrazne limituje aplikáciu pre tých, ktorí majú túto funkciu vypnutú, alebo ju ich prehliadač nepodporuje.
Zdroj: Wikipedia
Aj na vybrali.sme.sk sa rozhodli využiť referer ako formu obrany proti môjmu “útoku”, čo môj POC v podstate úplne znefunkčnilo. Jeho princíp je veľmi jednoduchý. Keďže pre zvýšenie bezpečnosti pridali prehliadače do pravidiel narábania s ECMA (JavaScript) skriptami “zákaz cross-site práce s webom”, jedinou možnosťou je vytvoriť prakticky normálny web, ktorý užívateľa “na pozadí” presmeruje, aby hlasoval. To som docielil vytvorením bežnej HTML stránky, do ktorej som pridal potrebné informácie pre hlasovanie. Pri tomto mojom malom “výskume” som zistil, že pligg aktívne rozlišuje medzi prihláseným a anonymným užívateľom nielen pridaním ID užívateľa k hodnoteniu, ale aj unikátnym vygenerovaním MD5 hash reťazca, ktorý je potrebný pre overenie. V prípade, že je užívateľ anonymný, je tento reťazec stále rovnaký, čo je chyba. Ak je užívateľ prihlásený, jeho hash sa zmení podľa jeho ID. Ak si pozriete zdrojové kódy webu, tak určite narazíte na funkciu, ktorá má tento stav na svedomí. Nižšie môžete vidieť daný kód, ktorý automaticky hlasoval za konkrétny článok.
<form method='post' action='http://vybrali.sme.sk/hlasuj.php' name="auhm">Keby ste tento kód vložili do vášho webu, automaticky by každý užívateľ, ktorý by vás navštívil, bol presmerovaný na stránky vybrali.sme.sk. Aby sa tak nedialo, respetkíve dialo na pozadí, pridam som jednoduchý skrytý iframe, ktorý s nulovou výškou, šírkou a style=”display:none” robil presne to, čo bolo potrebné. Užívateľa “na pozadí” premseroval na vybrali.sme.sk, pričom o tom samotný užívateľ ani len netušil.
<input type="hidden" name='id' value='32235'>
<input type="hidden" name='user' value='0'>
<input type="hidden" name='md5' value='e635f61424e1acd9a4c1554c82225baf'>
<input type="hidden" name='value' value='10'>
<script language="Javascript">
setTimeout("auhm.submit()", 1);
</script>
</form>
Ako som už spomenul, na vybrali.sme.sk kvôli tomuto môjmu pokusu bola pridaná ochrana v podobe kontrolovaní refereru, ktorá je celkom dosť účinná. Referer je síce možné vygenerovať, ale nie priamo cez JavaScript tak, aby ho bolo možné podať podobným spôsobom, ako som to urobil v tomto prípade. Referer teda nebude zodpovedať tomu, ktorý bol určený (pravdepodobne vybrali.sme.sk). Aj na toto však existuje veľmi elegantné riešenie, ktoré opíšem až po jeho otestovaní. Myslím, že mám riešenia až tri, pričom dve z nich sú z môjho pohľadu prakticky neodhaliteľné, o tom však až inokedy.
Ospravedľňujem sa teda všetkým, ktorí rovnako ako ja majú vypnutú funkciu zasielania refereru a sú momentálne v rozpakoch, prečo im hlasovanie nefunguje. Tiež túto “ochranu” považujem za veľmi obmedzujúcu, pričom je v priamom rozpore s tým, čo som prezentoval na svojej poslednej prednáške. Dúfam však, že sa na mňa páni zo Sme nehnevajú a že celú túto moju iniciatívu správne chápu tak, ako ju myslím a teda dopomôcť im k skvalitneniu bezpečnosti ich webu. Ak máte akékoľvek otázky, môžete ich položiť dole v diskusii.
Zaujal vás článok? Sledujte ma na Twitteri.




co je rozumne pouzit namiesto referreru?
Mna tak z brucha napada to, ze vzhladom na to, ze pristupujem z jednej ‘svojej’ adresy.stranky1 na inu ‘svoju’ adresu.stranku2, tak namiesto toho, aby som na stranke2 kontroloval adresu zo stranky1, si radsej na stranke1 vygenerujem (server side) nieco pseudonahodne a necham ulozene na server side s timeoutom. zaroven to poslem clientovi a nasledne okontrolujem zhodu na stranke2.
Co ty na to?
:) jedna ‘konkurencia’ vybrali sme to riesi tak, ze vzdy ked pridete na stranku je tam iny hash ktory sa posiela … aj sme by mohlo takto, uz sme dlho nepisali ziadne regexp :)
jedina spravna cesta su tokeny kombinovane so session. nic ine nie je funkcne
videli ste uz tie vtipne hlasky co ma sme pri nedostupnosti serverov? :)
http://img389.imageshack.us/my.php?image=smezlyserveric4.jpg
Foxy videli uz davno, tusim sa to riesili pri stahovani serverov
he, vyliezt niekom na nechraneny chrbat a potom vsetkym vykrikovat:”pozrite sa, nema zabezpeceny chrbat. a ja som frajer, co na to poukazal. som bezpecnostny expert” ;-)
roman 2.0
njn, nesmies tolko zavidiet. zavist nie je pekna vlastnost, to uz ta mali doma naucit. nik predsa nebrani ani tebe poukazovat na slabe a nedostatocne zabezpecenie jednotlivych webov
Ten roman podla mna bude prevtelena Trinity, presne ten isty sposob provokacii. Jednoduche prvoplanove, podpasove. IQ niekde tam kde uz gaussova krivka prechadza do prijemnej rovinky.
vsetko je mozne :) ale varoval som azetakov, ked si nedaju pohov, odplatim to. mam aspon dovod :)
podla mna chcel poukazat na problematiku ankiet, co ju sposobuje a jej vyriesenie zo strany sme a nie sa tu vychvalovat.To je aspon moj nazor.
mozes objasnit preco su podla teba potrebne tokeny AJ SESSIONS?
z jednoducheho dovodu. token je retazec, ktory je generovany pri posielani formularu. system tokenu uz pouziva aj stary pligg a je to vlastne ta md5 hash, ktoru som opisoval v clanku. mne vsak nijakym sposobom nezakazala odoslat data, jendoducho som ich poslal a sedeli. aj keby boli nahodne generovane, i tak by som ich vedel vzdy pre kazdeho usera ziskat, takze by to v skutocnosti nemalo ziadny zmysel. ak je vsak user viazany na token a na session, session ziskat neviem (ak nemam xss na webe) pretoze bude pravdepodobne v cookies. ak by bola v url, viem teoreticky vyuzivat referer, ale iste to je len obcas. cize som jendoducho neschopny ziskat session id, cim mi samotny token nijako nepomoze. preto jedina ochrana je session a token zaroven