Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Yahoo! Mail és a HPP

2009.05.25. 12:00 | buherator | 1 komment

Nem rég írtam a Stefano Di Paola és Luca Carettoni áltla közelmúltban bemutatott HTTP Parameter Pollution módszerről, amely megpróbál kiemelkedni a mára már unalomig ismételt webes sérülékenységek hosszú sorából. Annak megítélésére, hogy ez a törekvés mennyire sikeres, eddig kevés információ állt rendelkezésre, most viszont a kutatók a szélesebb közönséggel is megosztották az egyik, Yahoo! Mail Classic szolgáltatásával kapcsolatban felvetődött probléma részleteit. A módszer hatékonyságát az alábbi videó szemlélteti:

De mi is történik itt pontosan?

A támadó ráveszi az áldozatot, hogy kattintson rá egy, a sebezhető rendszer által felkínált linkre. A linkben található egyik GET paramétert az alkalmazás a generált HTML oldalban is felhasználja, mégpedig egy másik link GET paramétereként, dekódolva. Így ebbe, az alkalmazás által generált linkbe egy támadó által meghatározott paraméter kerül. Ebben az esetben ez a paraméter arra utasítja a szolgáltatást, hogy törölje a felhasználó leveleit. A videón ezen kívül látható még egy csavar: a "szennyezésként" bevitt paraméterbe egy másik, duplán kódolt paramétert helyeztek, amely az első link aktiválása után kerül bele (érvényes, önálló paraméterként) az oldalba - ez a paraméter üríti a kukát, ahová előzőleg elvándoroltak a levelek - már ha a felhasználó erre a másik linkre is rákattint*.

A Yahoo! Mail Classic minden parancs esetében anti-CSRF módszereket használ, a fenti módszerrel azonban ezek sikeresen megkerülhetők (voltak, a problémát azóta javították). Hagyományos értelemben vett Cross-Site Scriptingről azért nem beszélhetünk nyugodt szívvel, mert nem kerültek elhelyezésre új HTML vagy JavaScript elemek az oldalon, csupán egy-egy link bizonyos része egészült ki, és az alkalmazás a saját, legitim parancskészelét használtuk, melyek szerveroldalon futottak le. Emiatt a hagyományos XSS-védelmi megoldások is haszontalanokká válnak az ilyen trükkökkel szemben.

Ezek fényében még mindig nehezen tudnám megmondani, hogy hogyan is lenne érdemes értékelnünk a HPP-t. Az ilyen jellegű problémák kihasználhatósága jól láthatóan nagyrészt az implementációtól, annak is sokszor a legapróbb elemeitől függ, így nehéz olyan definiciót találni, amely alapján álalánosságban következtethetnénk a probléma súlyosságára. A napi böngészések során mindazonáltal jónéhány potenciálisan szennyezhető oldallal hoz össze a sors, a tapasztalatszerzésre így legalább megvan a lehetőség...

* Vajon az első műveletett miért nem lehetett elvégezni rögtön a levélben küldött linkkel?

Címkék: yahoo videó hpp

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

tarjáni 2010.01.29. 21:20:51

Eltünt a levél megjelölését mutató zászló. Ki tud segíteni a visszaállításában ?
Köszi : bzavarko@yahoo.com