A Hacktivity konferencia előadásait feldolgozó sorozatunk második részében kiderítjük, hogy vajon mennyire biztonságos a majd mindenki által használt, legelterjedtebb fiókhitelesítési módszer, mit veszíthetünk, ha feltörik, és hol húzódnak a korlátjai.
Hacktivity egyetemNemrég ért véget a 20. alkalommal megrendezett, #Hacktivity2023 MOST+NEXT konferencia Budapesten. Ebből az alkalomból rendhagyó cikksorozattal tisztelgünk a kitűnő előadások és értékes tudásanyag előtt, amit igyekszünk hétköznapi nyelvre fordítani, hogy a más területen dolgozó döntéshozók is könnyen megérthessék. A bemutatott izgalmas szoftveres védelmi eszközöket és szolgáltatókat linkeljük is, vagy az előadásról készült videóban található meg az elérhetőségük, így csak pár kattintás a kiberbiztonsági upgrade! A #Hacktivity2023-sorozatba tartozó cikkeinkben a feldolgozott előadások tanulságait több szempontból is vizsgáljuk, így a tárgyalt téma ismertetését az ügyvezető (CEO) és a technológiai vezető (CTO) számára megfogalmazott tanácsok tarkítják. A sorozat cikkei: |
Ebben Alina Boshchenko a JetBrains szoftvermérnöke lesz segítségünkre, aki nagy terhelésű rendszerekkel, pontosabban a beágyazott adatbázisok új tranzakciókezelési koncepcióival, valamint Kotlin/Java alapú szoftverfejlesztéssel és a hálózati biztonsággal foglalkozik. Fő munkaterülete a biztonsági problémák azonosítása és javítása, ami képes biztosítani a rendszerek robusztusságát.
A CEO figyelmébe
Alina Boshchenko előadása a OAuth (azaz OpenAuth) alkalmazás sérülékenységeiről szólt, ami nyílt szabvány a digitális hitelesítési (autentikációs) és jogosultsági (autorizációs) folyamatokra. Mindkét folyamat egy védett informatikai rendszerbe történő belépéskor fontos, az előbbi esetében a rendszer azt vizsgálja, hogy az adott felhasználó létezik-e a rendszerben, valamint rendelkezik-e aktív fiókkal, míg utóbbi esetben a protokoll azt ellenőrzi, hogy az imént beléptetett felhasználó mire jogosult a rendszerben, vagyis a tetszőlegesen konfigurált hierarchia mely fokán áll.
Mindannyian garantált OAuth felhasználók vagyunk, hiszen nagyjából mindegyik nagy online közösségi médiafelület használja valamelyik verzióját: az 500px, Amazon, deviantART, Dropbox, Evernote, Facebook, Fitbit, Flickr, GitHub, Goodreads, Google, Instagram, LinkedIn Microsoft (Hotmail, Windows Live, Messenger, Active Directory, Xbox), Netflix, PayPal, Reddit, Stripe, Trello, X (Twitter), Yahoo! mind ezt használják, és a felsorolásból jóval több szolgáltatást hagytunk ki, mint amennyit említettünk.
Vagyis, ha az OpenAuth folyamatát rosszindulatú hackerek képesek feltörni, akkor a fenti szolgáltatásokban lévő fiókjaink, céges oldalaink is a kezükbe kerülnek, temérdek üzleti adatunkkal egyetemben.
A CTO figyelmébe
A protokoll lehetővé teszi a felhasználók számára azt is, hogy megosszák saját adataikat egy harmadik féllel anélkül, hogy azonosítási adataikat kiadnák, ezt főképp a publikus, online is hozzáférhető alkalmazások védelmére használják.
Ez a folyamat dolgozik a háttérben, amikor a Google- vagy a Facebook-fiókunkkal regisztráljuk magunkat kényelmesen egy harmadik fél szolgáltatásában.
Az OAuth-nak több változata is létezik, van belőle 2.0 is, amelynek fejlesztésekor az egyszerű használhatóság volt a fókuszban. Ez már különleges engedélyezési folyamatokat is lehetővé tesz a webes alkalmazások, desktop alkalmazások és mobil appok számára. Alina Boshchenko a Proof Key for Code Exchange-et (PKCE-et) ajánlotta a hallgatóság figyelmébe, amely az engedélyezési kódfolyam kiterjesztése, és képes megakadályozni a CSRF– és az engedélyezési kód-injektáló támadásokat. A megoldás alapötlete a jogosultság igazolása, melynek során az ügyfélalkalmazásba plusz biztonsági igazolással dolgozó réteg kerül, ami újabb ellenőrzési kört hoz létre a használni kívánt rendszerbe történő belépésre és tevékenységre, a felhasználót erre felhatalmazó kód hitelességét bizonyítandó.
A védekezés módszerei
Mivel mára az OAuth vált az abszolút leggyakoribb hitelesítési mechanizmussá, ahogy említettük, felhasználók sokasága jelentkezik be vele zökkenőmentesen harmadik felek alkalmazásaiba, ám a natív kliensek szabványos OAuth-áramlásainak megvannak a korlátai, kockázatai és potenciális támadási vektorai. A PKCE képes kezelni ezeket a kihívásokat, megerősítve alkalmazásait a potenciális támadásokkal szemben, de ennek is vannak már ismert gyengeségei. Alina erre a Pixie nevű O0 bővítményt ajánlotta, ami szintén a natív ügyfelek védelmét szolgálja, és olyan széles körben elfogadott és támogatott szabvány, ami további védelmet biztosít a kódelfogás és a túlzott jogosultság ellen is. Az előadó ugyanakkor figyelmeztetett arra is, hogy egyetlen rendszer sem lehet tökéletesen biztonságos.
A tárgyalt folyamatokat veszélyeztető kibertámadások egyik jellemző típusát is láthattuk, amelyet lehallgató támadásnak (interception attacknek) hívnak. A támadó ilyenkor egy rosszindulatú alkalmazást telepíthet, amely jogosult felhasználóként regisztrálja őt, és ezzel lehetővé válik, hogy hozzáférést szerezzen a hitelesítésre használt (Google, Facebook, Linkedin stb.) fiókhoz. Ezt elkerülendő Alina Boshchenko nyomatékosan felhívta rá a figyelmet, hogy a felhasználók csak megbízható forrásból telepítsenek alkalmazásokat a rosszindulatú kártevők elkerülése érdekében.
(Aki megnézné teljes előadást – amit jó szívvel javaslunk is – az IDE kattintva teheti meg: 01:26:46-01:48:59)
| A sorozat cikkei |
