A07:2025 Selhání autentizace (Authentication Failures)

Pozadí

Selhání autentizace si udržuje 7. místo s mírnou změnou názvu, aby přesněji odráželo 36 CWE v této kategorii. Navzdory přínosům standardizovaných frameworků (rámců) si tato kategorie udržela 7. místo z roku 2021. Mezi významné CWE patří CWE-259 Use of Hard-coded Password, CWE-297: Improper Validation of Certificate with Host Mismatch, CWE-287: Improper Authentication, CWE-384: Session Fixation, and CWE-798 Use of Hard-coded Credentials.

Tabulka skóre

Počet mapovaných CWE	Max míra výskytu	Průměrná míra výskytu	Max pokrytí	Průměrné pokrytí	Průměrná vážená zneužitelnost	Průměrný vážený dopad	Celkový počet výskytů	Celkový počet CVE
36	15,80 %	2,92 %	100,00 %	37,14 %	7,69	4,44	1 120 673	7 147

Popis

Tato zranitelnost je přítomna, pokud útočník dokáže oklamat systém tak, aby rozpoznal neplatného nebo nesprávného uživatele jako legitimního. K oslabení autentizace může dojít, pokud aplikace:

Umožňuje automatizované útoky, jako je credential stuffing, kdy útočník má k dispozici prolomený seznam platných uživatelských jmen a hesel. V poslední době se tento typ útoku rozšířil tak, že zahrnuje i hybridní útoky na hesla v rámci credential stuffingu (známé také jako password spray útoky), kdy útočník používá variace nebo inkrementy uniklých přihlašovacích údajů k získání přístupu, například zkouší Password1!, Password2!, Password3! atd.
Umožňuje brute force nebo jiné automatizované, skriptované útoky, které nejsou rychle blokovány.
Umožňuje výchozí, slabá nebo dobře známá hesla, jako například Password1 nebo uživatelské jméno admin s heslem admin.
Umožňuje uživatelům vytvářet nové účty s přihlašovacími údaji známými z dřívějších úniků.
Umožňuje používat slabé nebo neúčinné procesy obnovy přihlašovacích údajů a „zapomenutého hesla“, například „odpovědi založené na znalostech“, které nelze učinit bezpečnými.
Používá úložiště hesel v prostém textu, šifrovaná nebo slabě hashovaná (viz A04:2025-Kryptografická selhání (Cryptographic Failures)).
Nemá vícefaktorové ověřování nebo je neúčinné.
Umožňuje použití slabých nebo neúčinných náhradních mechanismů, pokud není k dispozici vícefaktorové ověřování.
Vystavuje identifikátor relace v URL, ve skrytém poli („hidden“) nebo na jiném nezabezpečeném místě, které je klientovi dostupné.
Po úspěšném přihlášení znovu používá stejný identifikátor relace.
Při odhlášení nebo po určité době nečinnosti nesprávně zneplatňuje uživatelské relace nebo autentizační tokeny (zejména tokeny jednotného přihlášení (SSO)).
Nevynucuje správně rozsah oprávnění (scope) a zamýšleného příjemce (audience) poskytnutých pověření (credentials).

Jak tomu zabránit

Pokud je to možné, implementujte a vynucujte používání vícefaktorového ověřování, abyste zabránili automatizovaným útokům typu credential stuffing, brute force a opětovnému použití odcizených přihlašovacích údajů.
Pokud je to možné, podporujte a umožňujte používání správců hesel, aby uživatelům pomáhaly dělat lepší volby.
Nezavádějte ani nenasazujte žádné výchozí přihlašovací údaje, zejména pro administrátorské účty.
Implementujte kontroly slabých hesel, například porovnáním nových nebo změněných hesel se seznamem 10 000 nejhorších hesel.
Při vytváření nových účtů a změnách hesel ověřujte vůči seznamům přihlašovacích údajů známých z úniků (např. pomocí haveibeenpwned.com).
Slaďte délku hesla, složitost a zásady rotace hesel s doporučeními National Institute of Standards and Technology (NIST) 800-63b's guidelines in section 5.1.1, nebo s jinými moderními, na důkazech založenými zásadami pro hesla.
Nenuťte uživatele rotovat (měnit) hesla, pokud nemáte podezření na únik/kompromitaci. Pokud máte podezření na kompromitaci, okamžitě vynuťte reset hesel.
Zajistěte, aby registrace, obnova přihlašovacích údajů a API cesty byly zajištěny proti útokům typu enumerace účtů tím, že pro všechny výsledky použijete stejné zprávy („Neplatné uživatelské jméno nebo heslo.“).
Omezte nebo postupně prodlužujte zpoždění při neúspěšných pokusech o přihlášení, ale dávejte pozor, abyste nevytvořili scénář denial of service. Zaznamenávejte všechna selhání a upozorněte správce, pokud jsou útoky typu credential stuffing, brute force nebo jiné útoky detekovány nebo je na ně podezření.
Používejte vestavěný serverový správce relací, který je bezpečný a po přihlášení generuje nové náhodné ID relace s vysokou entropií. Identifikátory relací by neměly být v URL, měly by být bezpečně uloženy v zabezpečené cookie a zneplatněny po odhlášení, po vypršení nečinnosti (idle timeout) a po vypršení absolutního časového limitu (absolute timeout).
V ideálním případě používejte předem připravený, široce důvěryhodný systém pro zpracování autentizace, identity a správy relací (session management). Toto riziko přeneste, kdykoli je to možné, nákupem a využíváním hardenovaného (zpevněného/zabezpečeného) a dobře otestovaného systému.
Ověřte zamýšlené použití poskytnutých pověření, např. u JWT ověřte hodnoty aud, iss, a scopes.

Příklady scénářů útoků

Scénář #1: Credential stuffing, tedy použití seznamů známých kombinací uživatelských jmen a hesel, je dnes velmi běžný útok. V poslední době bylo zjištěno, že útočníci hesla „inkrementují“ nebo je jinak upravují na základě běžného lidského chování. Například změní „Winter2025“ na „Winter2026“ nebo „ILoveMyDog6“ na „ILoveMyDog7“ či „ILoveMyDog5“. Toto upravování pokusů o zadání hesla se nazývá hybridní útok credential stuffing nebo útok typu password spray a může být ještě účinnější než tradiční verze. Pokud aplikace neimplementuje obranu proti automatizovaným hrozbám (brute force, skripty nebo boty) ani proti credential stuffingu, může být použita jako password oracle k určení, zda jsou přihlašovací údaje platné, a k získání neoprávněného přístupu.

Scénář #2: Většina úspěšných útoků na autentizaci nastává v důsledku pokračujícího používání hesel jako jediného autentizačního faktoru. Požadavky na rotaci hesel a na jejich složitost, které byly kdysi považovány za osvědčené postupy, vedou uživatele jak k opětovnému používání hesel, tak k používání slabých hesel. Organizacím se doporučuje tyto postupy podle NIST 800-63 ukončit a vynucovat používání vícefaktorového ověřování na všech důležitých systémech.

Scénář #3: Časové limity relací aplikace nejsou správně implementovány. Uživatel používá veřejný počítač k přístupu k aplikaci a místo toho, aby vybral možnost „odhlásit se“, jednoduše zavře kartu prohlížeče a odejde. Dalším příkladem je situace, kdy SSO relaci (Single Sign-On) nelze ukončit pomocí SLO (Single Logout). To znamená, že jedno přihlášení vás přihlásí například do poštovního klienta, systému dokumentů a chatovacího systému, ale odhlášení se týká pouze aktuálního systému. Pokud útočník použije stejný prohlížeč poté, co se oběť domnívá, že se úspěšně odhlásila, ale v některých aplikacích je stále autentizována, může získat přístup k účtu oběti. Stejný problém může nastat v kancelářích a podnicích, když citlivá aplikace nebyla správně ukončena a kolega má (dočasný) přístup k odemčenému počítači.