Zranitelnost - Chyba v aplikace, která je předpokladem pro hrozbu
Útok - Akce využívající zranitelnost k poškození zdrojů
Opatření - Ochrana proti hrozbě
Zajištění bezpečnosti
Znát hrozby
Zabezpečit všechny kanály - Síť, hostitel, aplikace
Detekovat hrozby - Logovat, zpracovat
Vyvíjet bezpečně - Myslet na bezpečnost už při návrhu
Rizika a jejich opatření
OWASP(Open Worldwide Application Security Project) vydává pravidelně seznam 10 nejkritičtějších bezpečnostních hrozeb
OWASP 2017:
Injection
Broken Authentication
Sensitive Data Exposure
XML External Entities (XXE)
Broken Access Control
Security Misconfiguration
Cross-Site Scripting (XSS)
Insecure Deserialization
Using Components with Known Vulnerabilities
Insufficient Logging & Monitoring
SQL Injection
Riziko: Útočník vkládá škodlivá data do vstupů aplikace, která jsou následně interpretována jako příkazy.
Opatření:
Používání prepared statements (předpřipravených parametrizovaných dotazů), ORM,
Důsledná validace a sanitizace vstupů
Princip nejmenších oprávnění pro databázového uživatele.
Remote Code Execution
Riziko: Umožňuje spuštění libovolného kódu na serveru. Často způsobeno nebezpečným zpracováním uživatelských vstupů v dynamických jazycích (např. eval(), nebezpečné použití include s uživatelským vstupem).
Opatření:
Neumožňovat klientovi spouštět jeho kód
Validovat a omezovat cesty k souborům při include/require
Whitelist povolených akcí
XSS (Cross-Site Scripting)
Druh JavaScript injekce
Důvěra uživatele ve stránku
Riziko: Vykonání skriptu v bezpečnostním kontextu aplikace. Může vést ke krádeži session cookies, phishingu, přesměrování, modifikaci obsahu stránky.
Opatření:
Escapování vstupu od uživatele před zobrazením v HTML, JS
CSP (Content Security Policy) - HTTP header definující whitelist zdrojů, ze kterých může prohlížeč načítat obsah (skripty, styly, obrázky)
Cookie HttpOnly - zabraňuje přístupu pomocí JavaScriptu
CSRF (Cross-Site Request Forgery)
Riziko:
Útočník donutí (např. přes skrytý odkaz nebo obrázek na svém webu) prohlížeč přihlášené oběti odeslat škodlivý HTTP požadavek (typicky POST) na zranitelný web.
Oběť to udělá nevědomky a s jejími platnými cookies.
Opatření:
Cookie SameSite=Strict nebo SameSite=Lax
CSRF Token - Server vygeneruje unikátní token, vloží ho společně do vykresleného formuláře a při odeslání formuláře zkontroluje
Session Stealing
Riziko:
Získání platného Session ID jiného uživatele, což umožní převzít jeho identitu
Může být provedeno odposlechem sítě (pokud není HTTPS), pomocí XSS nebo uhodnotím/prolomením
Opatření:
Používat dlouhá, náhodná, nepředvídatelná ID
Regenerovat Session ID po každém přihlášení, při změně oprávnění, po změně hesla apod.
Přenášet pouze v HttpOnly (proti XSS) a Secure (pouze přes HTTPS) cookies, ne v URL
Autentizace
Proces ověření identity uživatele. Cílem je zjistit KDO uživatel je.
Metody autentizace
Něco, co víte (Something you know): Hesla, PINy, bezpečnostní otázky. Nejběžnější, ale náchylné k phishingu, brute-force útokům, slabým heslům.
Něco, co máte (Something you have): Fyzické tokeny (USB klíče, čipové karty), mobilní telefony (SMS kódy, autentizační aplikace), certifikáty.
Někým jste (Something you are): Biometrické údaje (otisk prstu, sken duhovky, rozpoznání obličeje, DNA).
Implementace
HTTP Basic Authentication
Jednoduchý mechanismus, jméno a heslo jsou posílány v hlavičce Authorization jako base64 kódovaný řetězec.
Není bezpečné bez HTTPS, protože údaje jsou přenášeny v podstatě v čitelné formě.
HTTP Digest Authentication
Vylepšení Basic autentizace, heslo se neposílá v čitelné formě, ale používá se mechanismus výzva-odpověď s hashem.
Stále se doporučuje HTTPS, protože MD5 (používaný v Digest) je považován za slabý.
Přihlašovací formuláře
Nejběžnější metoda. Uživatel zadá přihlašovací údaje do HTML formuláře, ty jsou odeslány na server (typicky metodou POST přes HTTPS).
Server ověří údaje a pokud jsou správné, vytvoří session.
Ukládání hesel na serveru
Hesla by nikdy neměla být ukládána v plain textu.
Musí být použity silné hashovací funkce (např. bcrypt, scrypt, Argon2) s unikátní solí (salt) pro každého uživatele.
API klíče
Používají se pro autentizaci aplikací nebo služeb, které přistupují k API.
Měly by být náhodné, neuhodnutelné, odvolatelné a přenášené přes HTTPS.
Často umožňují nastavení specifických oprávnění.
Token-based Authentication (např. JWT)
Alternativa k server managed session autentizaci. (server si zde nic neukládá)
Server po úspěšné autentizaci vygeneruje token (např. JWT), který je odeslán klientovi.
Klient tento token přikládá ke každému dalšímu požadavku na chráněné zdroje (typicky v hlavičce Authorization: Bearer <token>).
JWT jsou bezestavové na straně serveru (server si nemusí pamatovat vydané tokeny, stačí mu klíč k ověření podpisu), což je výhodné pro škálovatelnost a mikroslužby.
Kombinuje dvě nebo více různých autentizačních metod (např. heslo + SMS kód, heslo + autentizační aplikace).
Výrazně zvyšuje bezpečnost.
Autorizace
Proces ověření, zda má autentizovaný uživatel oprávnění k přístupu ke konkrétnímu zdroji nebo k provedení konkrétní akce.
Cílem je zjistit, co uživatel smí dělat.
Autorizace typicky následuje po úspěšné autentizaci.
RBAC (Role-Based Access Control)
Uživatelům jsou přiřazeny role (např. admin, editor, viewer).
Oprávnění jsou definována pro role, nikoli pro jednotlivé uživatele.
Implementace zahrnuje kontrolu, zda má uživatel požadovanou roli (např. user->hasRole(ROLE_ADMIN)).
Role mohou být hierarchické.
ACL (Access Control List)
Seznamy oprávnění přiřazené k objektům (zdrojům) - když role nestačí
ACL specifikuje, kteří uživatelé nebo skupiny mají jaký typ přístupu (čtení, zápis, smazání) k danému objektu.
Může být velmi granulární, ale také složitější na správu.
Ke každému jednotlivému záznamu v databázi (např. ke každému z milionu článků) je v jiné, speciální tabulce připojen seznam, který přesně říká, kdo s ním může co dělat (Jan: Číst-Ano, Zápis-Ne. Eva: Číst-Ano, Zápis-Ano)
Voter
Vzor, kde o oprávnění rozhoduje jeden nebo více "voličů".
Řeší "obří databázi" z ACL pomocí rozhodování v kódu aplikace
Každý voter může vyjádřit svůj názor (povolit, zamítnout, zdržet se) na základě specifických kritérií nebo kontextu (např. zda je uživatel autorem článku, který chce upravit).
Konečné rozhodnutí je pak agregováno specifickou metodou (majority, unanimous).