A04:2025 Kryptografická selhání (Cryptographic Failures)

Pozadí

Tato slabina, která se v žebříčku posunula o dvě pozice níže na 4. místo, se zaměřuje na selhání související s nepoužitím kryptografie, použitím nedostatečně silné kryptografie, únikem kryptografických klíčů a dalšími souvisejícími chybami. Tři z nejčastějších CWE (Common Weakness Enumerations) v rámci tohoto rizika souvisely s použitím slabého pseudonáhodného generátoru čísel: CWE-327 Use of a Broken or Risky Cryptographic Algorithm, CWE-331: Insufficient Entropy, CWE-1241: Use of Predictable Algorithm in Random Number Generator, a CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG).

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
32	13,77 %	3,80 %	100,00 %	47,74 %	7,23	3,90	1 665 348	2 185

Popis

Obecně řečeno by všechna přenášená data měla být šifrována na transportní vrstvě (vrstva 4 modelu OSI). Dřívější překážky, jako je výkon CPU a správa soukromých klíčů a certifikátů, jsou dnes řešeny jednak procesory s instrukcemi určenými k urychlení šifrování (např. podpora AES) jednak zjednodušenou správou soukromých klíčů a certifikátů prostřednictvím služeb, jako je LetsEncrypt.org, přičemž hlavní poskytovatelé cloudových služeb nabízejí pro své konkrétní platformy ještě těsněji integrované služby správy certifikátů.

Kromě zabezpečení transportní vrstvy je důležité určit, která data vyžadují šifrování v klidu a která data vyžadují dodatečné šifrování při přenosu (na aplikační vrstvě, 7. vrstvě modelu OSI). Například hesla, čísla kreditních karet, zdravotní záznamy, osobní údaje a obchodní tajemství vyžadují zvláštní ochranu, zejména pokud se na tato data vztahují právní předpisy na ochranu soukromí, např. obecné nařízení EU o ochraně osobních údajů (GDPR), nebo standardy jako PCI Data Security Standard (PCI DSS). Pro všechna taková data (je třeba posoudit následující skutečnosti):

Nejsou používány zastaralé nebo slabé kryptografické algoritmy či protokoly, a to buď ve výchozím nastavení, nebo ve starším kódu?
Nejsou používány výchozí kryptografické klíče, nejsou generovány slabé kryptografické klíče, nejsou klíče znovu používány a nechybí řádná správa a rotace klíčů?
Nejsou kryptografické klíče commitovány do repozitářů zdrojového kódu?
Je šifrování vynucováno (tj. nechybí některé bezpečnostní direktivy nebo hlavičky HTTP (prohlížeče))?
Je přijatý serverový certifikát a řetězec důvěry správně ověřován?
Nejsou inicializační vektory ignorovány, znovu používány nebo generovány nedostatečně bezpečně pro použitý režim činnosti kryptografického algoritmu? Není používán nezabezpečený režim činnosti, jako je ECB? Není používáno neautentizované šifrování v případech, kdy je vhodnější autentizované šifrování?
Nejsou hesla používána jako kryptografické klíče bez použití funkce pro odvození klíče z hesla (KDF)?
Není používána náhodnost, která nebyla navržena tak, aby splňovala kryptografické požadavky? Pokud je zvolena správná funkce, nevyžaduje seedování ze strany vývojáře, a pokud ano, nebyl mechanismus silného seedování přepsán seedem s nedostatečnou entropií/nepředvídatelností?
Nejsou používány zastaralé hashovací funkce, jako MD5 nebo SHA1, nebo nejsou používány nekryptografické hashovací funkce v případech, kdy jsou vyžadovány kryptografické hashovací funkce?
Nejsou kryptografické chybové zprávy nebo informace z vedlejších kanálů zneužitelné, např. formou útoků typu padding oracle?
Nelze kryptografický algoritmus downgradovat nebo obejít?

Viz reference ASVS: Cryptography (V11), Secure Communication (V12) a Data Protection (V14).

Jak tomu zabránit

Proveďte alespoň následující kroky a prostudujte odkazy:

Klasifikujte a označujte data, která aplikace zpracovává, ukládá nebo přenáší. Identifikujte, která data jsou citlivá, podle zákonů na ochranu soukromí, regulatorních požadavků nebo byznysových potřeb.
Nejcitlivější klíče ukládejte do hardwarového nebo cloudového HSM (Hardware Security Module).
Používejte dobře důvěryhodné implementace kryptografických algoritmů, kdykoli je to možné.
Neukládejte citlivá data zbytečně. Zahoďte je co nejdříve nebo použijte tokenizaci v souladu s PCI DSS, nebo i trunkaci. Data, která nejsou uchovávána, nemohou být ukradena.
Ujistěte se, že jsou všechna citlivá data v klidovém stavu šifrována.
Zajistěte, aby byly používány aktuální a silné standardní algoritmy, protokoly a klíče; používejte správnou správu klíčů.
Šifrujte všechna data při přenosu pouze pomocí protokolů ≥ TLS 1.2, se šiframi s forward secrecy (FS), ukončete podporu šifer cipher block chaining (CBC), podporujte algoritmy pro kvantovou výměnu klíčů. Pro HTTPS vynucujte šifrování pomocí HTTP Strict Transport Security (HSTS). Vše prověřujte pomocí nástroje.
Zakažte ukládání do mezipaměti pro odpovědi, které obsahují citlivá data. To zahrnuje ukládání do mezipaměti ve vašem CDN, webovém serveru a jakékoli aplikační mezipaměti (např. Redis).
Použijte požadované bezpečnostní kontroly podle klasifikace dat.
Nepoužívejte nešifrované protokoly, jako jsou FTP a STARTTLS. Vyhněte se používání SMTP pro přenos důvěrných dat.
Ukládejte hesla pomocí silných adaptivních a solí opatřených hashovacích funkcí s pracovním faktorem (faktorem zpoždění), jako jsou Argon2, yescrypt, scrypt nebo PBKDF2-HMAC-SHA-512. Pro starší systémy používající bcrypt získejte další doporučení v OWASP Cheat Sheet: Password Storage.
Inicializační vektory musí být voleny vhodně pro daný režim činnosti. To může znamenat použití CSPRNG (kryptograficky bezpečného pseudonáhodného generátoru čísel). Pro režimy, které vyžadují nonce, inicializační vektor (IV) nemusí používat CSPRNG. Ve všech případech by IV nikdy neměl být použit dvakrát s použitím téhož klíče.
Vždy používejte autentizované šifrování namísto pouhého šifrování.
Klíče by měly být generovány kryptograficky náhodně a ukládány v paměti jako pole bajtů. Pokud je použito heslo, musí být převedeno na klíč pomocí vhodné heslem založené funkce pro odvození klíče.
Zajistěte, aby byla kryptografická náhodnost používána tam, kde je to vhodné, a aby nebyla seedována předvídatelným způsobem nebo s nízkou entropií. Většina moderních API nevyžaduje, aby vývojář seedoval CSPRNG, aby bylo bezpečné.
Vyhýbejte se zastaralým kryptografickým funkcím, metodám blokové konstrukce a schématům vycpávání (padding), jako jsou MD5, SHA1, Cipher Block Chaining Mode (CBC), PKCS number 1 v1.5.
Zajistěte, aby nastavení a konfigurace splňovaly bezpečnostní požadavky tím, že budou přezkoumány bezpečnostními specialisty, nástroji určenými k tomuto účelu, nebo obojím.
Potřebujete se již nyní připravit na post-kvantovou kryptografii (PQC), viz odkaz (ENISA), aby systémy s vysokým rizikem byly bezpečné nejpozději do konce roku 2030.

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

Scénář #1: Webová aplikace nepoužívá nebo nevynucuje TLS pro všechny stránky, případně podporuje slabé šifrování. Útočník monitoruje síťový provoz (například v nezabezpečené bezdrátové síti), provede downgrade spojení z HTTPS na HTTP, zachytí požadavky a ukradne session cookie uživatele. Útočník tuto cookie následně přehraje (replay) a unese (autentizovanou) relaci uživatele, čímž získá přístup k soukromým datům uživatele nebo je může měnit. Namísto výše uvedeného může také měnit veškerá přenášená data, například příjemce peněžního převodu.

Scénář #2: Databáze hesel používá k ukládání hesel všech uživatelů nesolené nebo jednoduché hashovací funkce. Chyba v nahrávání souborů umožní útočníkovi získat databázi hesel. Všechny nesolené hashe mohou být odhaleny pomocí rainbow tabulky s předpočítanými hashi. Hashe generované jednoduchými nebo rychlými hashovacími funkcemi mohou být prolomeny pomocí GPU, i když byly solené.