Portál AbcLinuxu, 20. května 2024 19:25
Znáte XSS? Ano? A CSRF?
Obě zkratky označují slabinu webového prostředí, na kterou lze zaútočit. Obě vyžadují obětního uživatele, který funguje jako jakýsi hostitel. Obě zneužívají důvěru mezi uživatelem a webovým serverem. Dále se však rozcházejí. Ta první, cross-site scripting, je postavena na tom, že uživatel věří serveru. Ta druhá, cross-site request forgery, funguje naopak: Server věří uživateli.
Uživateli je obvykle nabídnuta stránka, která kromě jiného obsahuje kód, který přinutí prohlížeč odeslat HTTP požadavek na napadaný (chce se mi říci útočený) server. Tento požadavek je formálně zcela v pořádku, neobsahuje žádné zákeřnosti ve stylu XSS. On jen způsobuje vykonání akce v kontextu obětního uživatele. Akce, po které dychtí útočník, ale nebohý uživatel by s ní nikdy nesouhlasil.
Zaslechl jsem následující historku: V jedné organizaci probíhala volba mezi dvěma kandidáty za pomoci hlasovaní kliknutím na patřičný odkaz. Hlasovací aplikace byla uschována v informačním systému, do kterého byl přístup umožněn jen po úspěšné autentizaci.
Jeden z kandidátů rozeslal zprávu prostřednictvím právě toho informačního systému, který obsahoval odkaz na stránku s jeho volebním programem. Když zvědavý volič klikl, zobrazil se pouze rýpavý text: Hádejte, kdo tohle kolo vyhraje! Ve skutečnosti odkazovaná stránka obsahovala v kódu takovýto odkaz na obrázek:
<img src="http://informacnisystem/hlasuju-pro-losnu">
Útok fungoval. V okamžiku, kdy se volič rozhodl přečíst si volební program, byl již do systému přihlášen a následně prohlížeč bez jeho vědomí za něj zahlasoval tím, že se snažil stáhnout neexistující obrázek.
Chyba je v tom, že server slepě věří požadavkům přicházejícím od uživatele. Ochrana proti CSRF útokům spočívá ve vyměnění trvalé autentizace uživatele na tranzitivní (např. předávání tokenu mezi stránkami přes skrytá pole formulářů) nebo vytváření unikátních URL, které nelze předem odhadnout.
Skrytou součástí tohoto článku byl pokus, který měl ověřit funkčnost výše uvedeného útoku na čtenářích Abíčka.
Text článku obsahoval následující kód:
<div class="hidden"> <img src="http://www.abclinuxu.cz/blog/EditMonitor/153095?action=toggle" alt="Proof-of-concept exploit"> </div>
který způsobil, že při každém zobrazení článku byl přihlášenému čtenáři změněn stav Sledování. Tj. při prvním zobrazení mu bylo sledování zapnuto. Za dobu 1 dne článek přečetlo 236 registrovaných uživatelů, přičemž čítač funkce zapnutého sledovaní se vyšplhal na 80. Zdá ze, že po získání prvního komentáře se někteří vrátili k článku, aby vypnuli, již vypnuté sledování. Zároveň prvních 30 minut vedl skrytý odkaz jinam, tudíž první čtenáři (asi 28) byly přihlášeni k jiné diskuzi.
Tímto se všem čtenářům omlouvám, že se nedobrovolně zúčastnili tohoto testu.
Tiskni Sdílej:
Skrytou součástí tohoto článku byl pokus, který měl ověřit funkčnost výše uvedeného útoku na čtenářích Abíčka.
Text článku obsahoval následující kód:
<div class="hidden"> <img src="http://www.abclinuxu.cz/blog/EditMonitor/153095?action=toggle" alt="Proof-of-concept exploit"> </div>
který způsobil, že při každém zobrazení článku byl přihlášenému čtenáři změněn stav Sledování. Tj. při prvním zobrazení mu bylo sledování zapnuto. Za dobu 1 dne článek přečetlo 236 registrovaných uživatelů, přičemž čítač funkce zapnutého sledovaní se vyšplhal na 80. Zdá ze, že po získání prvního komentáře se někteří vrátili k článku, aby vypnuli, již vypnuté sledování. Zároveň prvních 30 minut vedl skrytý odkaz jinam, tudíž první čtenáři (asi 28) byly přihlášeni k jiné diskuzi.
Tímto se všem čtenářům omlouvám, že se nedobrovolně zůčastnili tohoto testu.
hidden
- já ji tam určitě nepřidal.
Krome toho, ze to vypada hnusne?Nic jinýho mě nenapadá...
Pomoci CSS neni mozne testovat, zda element obsahuje nejakeho potomka, ze? INS totiz muze obsahovat blokove elementy. Mas nejaky napad, jak to na nakodit?To bohužel netuším...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.