Tech-Ed 2010 Berlin 3. rész – Webes támadások Q&A

A Tech-Ed-es sorozatom első szakmai cikkének Christian Wenz által tartott Web Applications in Danger: Attacks Against Web Sites and RIAs interaktív szekciójának taglalását választottam. Bár a címből nem látszik, de ez valójában egy kétrészes előadássorozat első fele, melynek a folytatása a Usability, SEO, Security: Common RIA and Ajax Mistakes (and Fixes) nevet kapta. A kettő együtt alkotja a mostani blogbejegyzésem témáját.

 

A biztonságról (kifejezetten a webes alkalmazásoknál, melyeket bárki elérhet, emiatt több lehet köztük a potenciális rosszakaró) órákon és órákon keresztül lehetne (és kéne is) beszélni, de sokan csak úgy gondolnak rá (rendkívül helytelenül), hogy ez csak egy extra szolgáltatás. NEM, az alkalmazásoknak ugyanúgy a szerves részét képezi a biztonság, mint például az adatelérési réteg. Ebben a bejegyzésben nem a téma létjogosultságáról és az alapjairól szeretnék értekezni, hanem (mint ahogyan az előadásokon is) néhány érdekesebb és mostanság „divatos” támadási technikát és ellenszert (countermeasure-t) szeretnék Nektek bemutatni, Veletek megosztani.

Az SQL Injection-ről (1,2,3) és a Cross-Site Scripting-ről (1,2,3) (remélhetőleg) már mindenki hallott és tudja, miként kell ellenük védekezni. Viszont a Cross-Site Request Forgery-ről (1,2,3,4) vagy a Clickjacking-ről (1,2,3,4) már annál kevesebben. Kezdjük először a CSRF kivesézésével kérdez-felelek formában.

– Mi is az a Cross-Site Request Forgery?
– Ez egy olyan webes támadási technika, amelynek az alapja pont az XSS alapjának ellentéte. Míg ott a felhasználó bízik meg az adott oldal tartalmában, addig itt a weboldal fogadja bizalmába a klienst és hajt végre a nevében a nem kívánt műveletet. A CSRF-et szokás még XSRF, illetve session riding néven is emlegetni.

– Hogyan működik a CSRF?
– Az áldozatnak be kell jelentkezve lennie egy adott rendszerbe, ahol az authentikációs információk egy részét a sütiben tárolják. Ezeket az értékes adatokat a böngésző egy GET http utasítás ellenében minden további nélkül rendelkezésére bocsájtja a rendszernek. Az URL-be be lehet csomagolni GET paramétereket, amelyek segítségével az oldalon meg lehet hívni bizonyos műveleteket. Íme, egy egyszerű példa:

https://ourbank.com/withdraw?from=you&to=me&amount=1000000

Ha mindezt mondjuk egy kép src attribútumába helyezzük el, akkor az áldozat számára az egész művelet mind addig láthatatlan marad, amíg meg nem érkezik a hó végi számlakivonata a banktól.

– Miként lehet ellene védekezni?
– Kliensként javaslott kijelentkezni a rendszerekből, ha már nem használjuk őket és elkerülni az „emlékezzen rám” lehetőségeket. Fejlesztőként használjuk a Synchronizer Token Pattern-t, melynek lényege, hogy egy extra véletlen generált token-t is utaztatunk az oldalon, melyet a sessionid-val együtt mindig megvizsgálunk oldalkéréskor. További lehetőségek az alábbi oldalon találhatóak.

 

– Mi is az a Clickjacking, vagy klikkeltérítés?
– Ez is egy olyan webes támadási technika, mely a weboldal felhasználó iránti bizalmára épül. Itt a kliens a tudta nélkül kattint egy olyan gombra, mely olyan http üzeneteket küld el, melyekkel saját magáról adhat ki információkat, vagy rosszabb esetben akár a gép fölötti irányítást ruházza át másra. Szokás ezt a támadást még UI redressing-nek is hívni.

– Hogyan működik?
– A technika lényege, hogy a támadó rávegye az áldozatot arra, hogy rákattintson egy olyan linkre, amire esze ágába nem klikkelne, ha tudna róla. Általában egy iframe segítségével két réteget hoznak létre egymás fölött, ahol a felső réteg nem feltétlenül fedi teljesen az alsót. Amikor a felhasználó azt hiszi, hogy rákattint a felső rétegen egy gombra, akkor valójában az alsó rétegen lévőre kattint és annak a kódját hajtja végre a rendszer. Az elmúlt pár évben ez eléggé nagy port kavart, ugyanis ily módon a flash webkamera funkcióját is be lehetett aktiválni. Néhány érdekes cikk a témával kapcsolatban(1,2,3,4).

– Miként lehet ellene védekezni?
– Kliensként egyrészt ne kattintgassunk mindenféle reklámra, mely valamilyen banális dolgot kínálnak számunkra INGYEN. Másrészt használjuk a FireFox-os NoScript kiegészítést, mely CleanClick-nek elnevezett funkciója meggátolja, hogy clickjacking áldozattá váljunk. Fejlesztőként használjuk a framekiller nevezetű js kódot, mely meggátolja, hogy az oldalunkat mások beágyazhassák frame-ekbe, vagy használjuk az X-Frame-Option header tag-et.

 

– További webes támadásokról és ellenszereikről, hol olvashatok bővebben?
– Egyrészt az alábbi MSPress könyvben: Developing More-Secure ASP.NET 2.0 Applications, másrészt pedig az OWASP és a Seven Deadliest WebAttacks oldalakon.

– A jövőben szívesen olvasnál a blogon hasonló témájú cikkeket?
– Ha igen, akkor kérlek, jelezd valamilyen úton-módon.