E-shop, školní systém, internetové bankovnictví – všechno jsou webové aplikace. Přijímají data od kohokoli na internetu. Stačí, aby programátor jednou zapomněl, že vstup může poslat útočník, a ten ovládne databázi nebo účty ostatních uživatelů.
Zlaté pravidlo celého tématu: nikdy nevěř vstupu od uživatele.
?hledat=boty v adrese e-shopu.SELECT * FROM uzivatele WHERE jmeno = 'eva'' OR '1'='1."SELECT * FROM uzivatele WHERE jmeno = '" + jmeno + "' AND heslo = '" + heslo + "'". Co se stane, když útočník do jména napíše admin' --?SELECT * FROM uzivatele WHERE jmeno = 'admin' --' AND heslo = '…'. Znaky -- v SQL začínají komentář, takže kontrola hesla zmizí a útočník se přihlásí jako admin. Oprava: parametrizovaný dotaz, např. WHERE jmeno = ? AND heslo_hash = ?, kde data databáze nikdy neprovede jako příkaz.<script>…</script> uložený v diskusi se spustí každému, kdo ji otevře.< na <, > na >, " na "). Prohlížeč je pak zobrazí jako text, nespustí je.Komentář se zobrazí jako text „<script>…“, ale neprovede se.innerHTML. Jak útok funguje a jak ho opravit?textContent místo innerHTML a navíc nastavit Content Security Policy, která zakáže nepovolené skripty.Roztřiď příklady a obrany k útoku, kam patří. Pamatuj: SQL injection míří na databázi, XSS na prohlížeče ostatních.
Vše, co běží v prohlížeči, má útočník pod kontrolou. Kontrola v prohlížeči je jen pohodlí pro poctivé uživatele.
textContent a Content Security Policy. Přehled nejčastějších chyb dává OWASP Top 10.Máš zkontrolovat aplikaci, kterou napsal spolužák, než ji škola nasadí. Kde začít? Pomůže přehled nejčastějších chyb a ke každé jedno hlavní opatření.
session=8f2a… s příznaky HttpOnly; Secure; SameSite=Lax.| Chyba | Příklad | Hlavní obrana |
|---|---|---|
| chybné řízení přístupu | změním v URL /znamky?zak=1024 na 1025 a vidím cizí známky | kontrola oprávnění na serveru u každého požadavku |
| injection (SQL, příkazy OS) | ' OR '1'='1 v přihlášení | parametrizované dotazy, validace vstupu |
| XSS | skript v komentáři | escapování výstupu, Content Security Policy |
| slabá autentizace | neomezený počet pokusů o heslo | MFA, omezení pokusů, bezpečné ukládání hesel (hash se solí) |
| chybná konfigurace | zapnutý ladicí výpis chyb na produkci, výchozí heslo admina | zabezpečená výchozí konfigurace, revize nastavení |
| zastaralé komponenty | knihovna se známou zranitelností | aktualizace, sledování závislostí |
| CSRF | cizí web odešle formulář tvým jménem, když jsi přihlášený | CSRF tokeny, cookie SameSite |
/faktura?id=5521. Přihlášený zákazník změní číslo na 5522 a uvidí cizí fakturu. Jaká je to chyba a jak ji opravit?HttpOnly, Secure a SameSite?HttpOnly – JavaScript na stránce cookie nepřečte, takže ji případné XSS hůř ukradne. Secure – pošle se jen přes HTTPS. SameSite – prohlížeč ji nepošle s většinou požadavků z cizích webů, což brání CSRF.Zkus odpověď říct dřív, než kartu otočíš.
/admin ověřit, že je uživatel administrátor. Skrytý odkaz nic nechrání.Útočník adresu uhodne nebo najde v kódu stránky. Bezpečnost nesmí stát na tom, že něco není vidět.