Tlačítka „Přihlásit se přes Google“ nebo „Continue with Microsoft“ jsou dnes na každém druhém webu. Pro uživatele pohodlí, pro aplikace méně starostí s hesly. Jenže říjnová vlna zranitelností v populárních přihlašovacích knihovnách ukázala, že na pomezí mezi „přihlášením přes někoho“ a vlastním účtem vzniká slepé místo, kterým se dají účty tiše přebírat. Pojďme si nejdřív srozumitelně říct, co to vlastně OAuth je – a pak kde přesně se láme.
Co je vlastně OAuth
OAuth (a na něm postavené OpenID Connect) je standard delegovaného přihlášení. Místo abyste si u každé služby zakládali další heslo, prokážete se u poskytovatele identity, kterému už důvěřujete – třeba u Googlu nebo Microsoftu. Ten pak aplikaci předá podepsané potvrzení: tento člověk je náš uživatel s tímto identifikátorem, má tento e-mail a ten je (nebo není) ověřený. Funguje to podobně jako občanský průkaz: aplikace nezkoumá, jak jste se prokázali úřadu – věří dokladu, který úřad vystavil.
Důležitý detail, na kterém celý dnešní příběh stojí: potvrzení obsahuje stabilní identifikátor uživatele (dvojici „kdo ho vydal“ a „číslo uživatele u vydavatele“) a vedle něj e-mail. Specifikace OpenID Connect výslovně říká, že e-mail se jako jednoznačný identifikátor používat nesmí – e-maily se totiž mění, recyklují a hlavně je může tvrdit kdokoli.
Kde se to láme: spojování účtů podle e-mailu
Většina aplikací řeší praktický problém: uživatel se kdysi zaregistroval heslem a dnes klikl na „Přihlásit přes Google“. Aby neskončil v prázdném novém účtu, aplikace oba účty propojí – a nejjednodušší vodítko je shoda e-mailové adresy. Říká se tomu auto-linking. A právě tady vzniká útočná plocha, protože aplikace dělá rozhodnutí o vlastnictví účtu na základě údaje, který si sama nikdy neověřila.
Typický útok – v literatuře se mu říká „pre-hijack“, tedy únos předem – vypadá takto:
- Útočník se v aplikaci zaregistruje e-mailem oběti a vlastním heslem. E-mail samozřejmě nepotvrdí – ale účet existuje.
- Oběť se později přihlásí tlačítkem „přes Google“ se svým skutečným účtem. Poskytovatel aplikaci potvrdí ověřený e-mail.
- Aplikace najde „existující účet“ se stejným e-mailem a identitu oběti k němu propojí.
- Útočník se kdykoli poté přihlásí svým heslem – do účtu, který oběť považuje za svůj, s jejími daty.
Variant je víc: aplikace nekontroluje, zda poskytovatel e-mail skutečně ověřil; věří ověření od poskytovatele, který pro danou doménu není autoritou; před propojením neporovná adresy; propojení obejde dvoufaktorové ověření; nebo si při něm nechá přepsat uložený e-mail, takže na útočníka začne ukazovat i obnova hesla.
Není to teorie
Jen během letošního roku dostaly tento typ chyby tři rozšířené přihlašovací knihovny a dva WordPress pluginy. Pingvin Share X nekontroloval ověření e-mailu od OIDC poskytovatelů a navíc umožňoval obejít TOTP (CVSS 9,2). Better Auth kontroloval ověření na straně poskytovatele, ale už ne u lokálního účtu – přesně scénář popsaný výše (CVSS 8,3). AshAuthentication před propojením vůbec neporovnával e-maily a propojení navíc přepisovalo údaje účtu, takže útočník získal trvalou kontrolu (CVSS 9,1). A plugin WPO365 měl kontrolu, která nemohla nikdy projít – jenže přihlášení pokračovalo dál. Poučka autorů stojí za zapamatování: ověření, které při selhání nezastaví průchod, je horší než žádné.
Co s tím
Pokud aplikace provozujete nebo vyvíjíte: účty párujte podle stabilního identifikátoru poskytovatele, nikdy podle e-mailu – shoda adres je jen nápověda. Ověření vyžadujte na obou stranách (poskytovatel i lokální účet), tvrzení „e-mail je ověřený“ přijímejte jen od poskytovatelů, kteří jsou pro danou doménu autoritou, při pochybnostech si vyžádejte přihlášení stávající metodou včetně druhého faktoru, propojením nikdy nepřepisujte údaje účtu a o každé nově připojené přihlašovací metodě uživatele informujte e-mailem. A každá kontrola v přihlašovacím řetězci musí při selhání zastavit celý průchod.
Pokud aplikace jen používáte: zapněte dvoufaktorové ověření, zbystřete u každého nečekaného e-mailu o „nově připojené přihlašovací metodě“ a u dodavatelů firemních aplikací se ptejte, podle čeho propojují účty – je to dobrá otázka do bezpečnostního dotazníku. V naší praxi při vyšetřování převzetí účtu začínáme právě historií přihlašovacích metod a auditními záznamy poskytovatele identity: bývá v nich vidět přesně ten okamžik, kdy se k účtu připojil někdo cizí.
Poučení: tlačítko „Přihlásit přes…“ je bezpečné jen tolik, kolik je bezpečné propojování účtů za ním. E-mailová adresa není identita – a aplikace, která na shodě e-mailů staví vlastnictví účtu, dříve či později někomu ten účet předá.
Zdroj: WorkOS – OAuth auto-linking by email: account takeover (říjen 2026).