3.3 Autentizace a správa relací

Autentizace (Authentication)

Protokol HTTP je sám o sobě bezstavový (stateless). To znamená, že každý HTTP dotaz je zpracován nezávisle na těch předchozích. Pokud se uživatel na webu přihlásí, server by při dalším kliknutí nevěděl, že jde stále o toho stejného uživatele. Proto webové aplikace potřebují mechanismy autentizace a správy relací (session management).

Běžné autentizační mechanismy
  • Založené na cookies (Cookie-based): Server po přihlášení vydá uživateli unikátní identifikátor relace uložený v cookie, který prohlížeč automaticky zasílá s každým dalším dotazem.
  • Založené na tokenech (Token-based): Např. JWT (JSON Web Tokens) nebo API klíče, běžné u moderních SPA (Single Page Applications) a REST API.
  • Založené na certifikátech: mTLS (Mutual TLS), oboustranné ověření pomocí klientských certifikátů.
  • HTTP Autentizace: Zabudované formy do HTTP standardu, např. Basic, Digest, NTLM nebo Negotiate.
Časté zranitelnosti a slabiny autentizace
  • Výchozí přihlašovací údaje (Default credentials): Použití nezměněných přednastavených hesel (např. admin/admin).
  • Přenos údajů po nešifrovaném HTTP: Při POST požadavcích v těle, případně při použití Basic Auth, kdy je dvojice jmeno:heslo pouze kódována přes Base64 a není šifrována.
  • Enumerace uživatelů (User enumeration): Útočník může zjistit existenci účtu tím, že server vrací např. "Uživatel Alice neexistuje" vs. "Chybné jméno nebo heslo". Enumeraci lze provádět i formou časové odlišnosti (Timing difference), např. když ověření existujícího uživatele trvá déle než u neexistujícího.
  • Slabé mechanizmy proti zablokování (Weak lock-out): Absence dočasného uzamčení účtu usnadňuje útoky hrubou silou.
  • Obejití autentizace: Možnost vyhnout se kontrole například přes SQL Injection (vložení ' OR 1=1--) nebo využitím PHP "magic hashů" typu juggling.
  • Slabá pravidla pro tvorbu hesla (Weak password policy): Umožnění krátkých nebo snadno uhodnutelných hesel.
  • Zranitelnosti při změně a resetu hesla.

Správa relací (Session Management)

Pokud se autentizace opírá o cookies (tzv. session cookies), jejich nastavení tvoří hranici mezi bezpečnou aplikací a zranitelnou infrastrukturou. Za nastavení atributů cookie je zodpovědný server při zasílání hlavičky Set-Cookie.

Základní bezpečnostní atributy cookies
  • Secure: Přikazuje prohlížeči, aby tuto cookie posílal výhradně přes šifrovaný protokol HTTPS. Zabraňuje krádeži cookie zachycením na nezabezpečené síti.
  • HttpOnly: Znemožňuje přístup k hodnotě cookie ze skriptů běžících v prohlížeči (JavaScript). Poskytuje efektivní obranu proti zneužití cookie v případě XSS útoku (Cross-Site Scripting).
  • SameSite: Určuje prohlížeči situace, za kterých má cookie přikládat k dotazům posílaných mezi různými doménami (Origin):
    • None: Cookie je odesílána i s cross-site requesty.
    • Lax: Výchozí bezpečné chování v dnešních prohlížečích (pokud atribut chybí). Bude se sdílet u cross-site požadavků, ale pouze pro bezpečné HTTP metody (GET).
    • Strict: Cookie nebude nikdy odeslána při dotazu inicializovaném z jiné domény.
Možné útoky na správu relací
  • Session fixation: Útočník předvygeneruje a podvrhne platný identifikátor relace oběti. Pokud po přihlášení oběti aplikace tento token neobnoví, útočník je také přihlášen, protože má stále k dispozici stejný token.
  • Exposed session variables: Únik relačních parametrů v URL nebo chybových hláškách.
  • Slabé odhlášení (Logout functionality): Nedostatečné zneplatnění relace na serveru (odhlášení vymaže cookie jen v prohlížeči, ale stará cookie zůstává platná).
  • Session timeout: Absence automatického odhlášení při delší neaktivitě nechává prostor pro ukradení fyzicky opuštěné obrazovky.