Přeskočit na hlavní obsah

Jak na validaci vstupu, jak je to s právem v kyberprostoru a další

Víte, proč validovat vstup a co vám hrozí, když to dělat nebudete? Co je lepší - allow list, nebo blacklist? I jako provozovatel e-shopu nebo online služby máte povinnost mít bezpečnostní opatření a podléháte regulaci.

🏆 Téma: Validace (nejen) uživatelského vstupu

  • Do aplikace proudí velké množství dat z různých zdrojů:
    • Uživatelem zadaná data z formulářů nebo URL parametrů
    • Data ze služeb třetích stran, na které je aplikace napojená (např. synchronizace produktů ze systému pro skladové hospodářství)
  • Tato data mohou obsahovat prakticky cokoli, i přes to, že se očekává, že budou obsahovat něco, co se plánovalo.
    • Uživatel do pole “Jméno” opravdu zadá své jméno a ne kód nebo číslo.
    • Ze skladového hospodářství nám přijde počet kusů daného zboží na skladě a ne prázdná hodnota nebo jméno odpovědné osoby.
  • Svět ale není vždy jen růžový a aplikace se musí k jakémukoli vstupu chovat jako k nedůvěryhodnému.
  • Neprověřený a nezvalidovaný vstup totiž může způsobit řadu závažných problémů:
  • Validace vstupních dat se provádí proto, aby se zajistilo, že do systému vstupují pouze správná data.
    • To zabrání uložení nesprávných dat a následných aplikačních chyb v navazujících komponentách.
  • K validaci by mělo dojít co nejdříve, nejlépe hned po přijetí dat.
  • Validace vstupů by neměla být považována za primární metodu ochrany proti výše zmíněným problémům.
    • Při správné implementaci významně přispívá ke snížení jejich dopadu.
  • Systém by měl aplikovat jak
    • syntaktickou validaci = zajišťuje správnou syntaxi dat (datum, SSN, symbol měny), tak
    • sémantickou validaci = zajišťuje správnost hodnot v daném kontextu (datum zahájení, datum ukončení, cena v očekávaném rozsahu).
  • Validace v některých případech není snadná záležitost - např. kontrola e-mailové adresy.
    • Za platnou adresu se považují například tyto:
      • "><script>alert(1);</script>"@example.org
      • user+subaddress@example.org
      • user@[IPv6:2001:db8::1]
      • " "@example.org
    • Adresu se doporučuje předat mail serveru, který ji buď přijme, nebo odmítne.
    • Pro validaci se vyplatí používat komponenty, které jsou ověřené a hojně používané (např. Apache Commons Validators).
  • Validace by se měla provádět hlavně na serveru a klientská aplikace by měla tu serverovou interpretovat.
    • Klientská validace je považována za nedostatečnou, protože ji lze snadno obejít.
  • V závislosti na kontextu preferujte seznam povolených hodnot (allow list) před seznamem vyloučených hodnot (blacklist).

Jak na validaci textu​

  • Je obtížně validovatelný kvůli množství znaků, které je potřeba povolit.
  • Zajistěte, aby bylo v celém textu použito kanonické kódování a aby se v něm nevyskytovaly žádné nepovolené znaky (normalizace).
  • Aplikujte seznam povolených znaků (regulární výrazy - mohou být značně komplikované).
  • Na základě kontextu povolte ideogramy, apostrofy a další znaky, které jsou potřeba.

Jak na validaci uploadu souborů​

  • Použijte nový název souboru, nepoužívejte uživatelsky definovaný název.
  • Ujistěte se, že nahraný soubor není větší než maximální definovaná velikost souboru (mohlo by vést k DoS).
  • Vyhněte se přijímání .zip souborů.
  • Zajistěte, aby název souboru používal očekávanou příponu.
    • Dejte si pozor na situace typu soubor.jpg.php, kdy může dojít ke špatné interpretaci, že jde o obrázek.
  • Analyzujte soubory na škodlivý obsah (antimalware, statická analýza).
  • Cestu k souboru by nemělo být možné zadat na straně klienta, rozhoduje o ní server.
    • Tím se nestane, že si uživatel zobrazí soubor /etc/passwd.
  • Při podávání obsahu zajistěte, aby soubory měly správný content type (image/jpeg, application/x-xpinstall).

🎓 Učíme se společně

Co jsme se dozvěděli z přednášek, školení, čtení knih a dalších aktivit?

CyberCast: Vymahatelnost práva se v kyberprostoru blíží k nule​

  • Kyberbezpečnost je brána jako povinnost, kterou firma nechce řešit, a právní úprava tomu nahrává.
  • Odpovědný za škodu je statutární orgán.
  • Právní úpravu definuje zákon o kybernetické bezpečnosti.
  • Aktuálně povinnost dopadá na cca 400 subjektů, NIS2 to rozšíří na cca 6000.
  • NIS2 by se měla dotknout i dodavatelského řetězce.
    • Minimálně v případě, že se něco dodává orgánu veřejné moci.
  • Pokud jsem provozovatel e-shopu nebo digitálního produktu, tak na mě regulace dopadá už teď, protože jsem poskytovatel digitální služby.
    • Měl bych mít bezpečnostní opatření a měl bych hlásit bezpečnostní incidenty.
    • Problém je, že to nikdo moc nekontroluje, proto se o tom tolik neví.
  • Napříč EU bude jednotný systém certifikace, který ověří splnění podmínek na kybernetickou bezpečnost (jednotný rámec pro certifikaci kybernetické bezpečnosti).
    • O určité službě, procesu nebo produktu bude možné říct, že na určité úrovni splňuje požadavky na kybernetickou bezpečnost.
    • Certifikace se vydává na 5 let a bude možné ji prodloužit.
  • Jak by se měla firma zachovat v případě, že je napadena ransomwarem?
    • Mít zálohu, obnovit ji a kontaktovat útočníka.
    • Doporučuje se nevyjednávat (2 z 10 případů data obnoví).
  • Jako je Software as a Service, tak je i Ransomware as a Service, který si můžu objednat.
  • Právníci doporučují školit zaměstnance a smluvně si podchytit dodavatele, aby nevznikly problémy na jejich straně a nepodcenit bezpečnost - pokud jste statutární orgán, odpovědnost je na vás (ve výsledku se to vždy dostane k vám, nejde to outsourcovat).

📰 Co je nového

  1. Přednáška: Nejčastější API a aplikační zranitelnosti 2023
    • Poslechněte si moji hodinovou přednášku z minulého týdne.
    • Na webu je k dispozici seznam API zranitelností včetně jejich mitigace.
    • Nově nabízím službu whitebox API audit.
  2. Přednáška: Nepropalte miliony díky nezabezpečené aplikaci (Nauč mě IT)
    • Přednášel jsem na téma nejčastějších zranitelností, se kterými se v praxi setkávám + jak na nich klienti propálili nemalé peníze.
    • Ve druhé části přednášky se věnuju GitHubu a jeho security funkcím, které můžete používat i vy.
  3. Miliony zranitelných GitHub repozitářů
    • Repozitáře se potýkají se zranitelností RepoJacking (dependency repository hijacking).
    • Ovlivněny jsou například repozitáře Googlu a dalších firem.
    • Když vlastník repozitáře změní uživatelské jméno, vytvoří se mezi starým a novým jménem spojení pro každého, kdo si stáhne závislosti ze starého repozitáře.
    • Je však možné, aby kdokoli vytvořil staré uživatelské jméno a toto propojení porušil.
    • Případně může scénář nastat, když je repozitář převeden na jiného uživatele a původní účet je smazán - to umožní útočníkovi vytvořit účet se starým uživatelským jménem.
    • Tím se způsobí, že kód, který má tento projekt jako závislost, načte obsah z repozitáře ovládaného útočníkem, čímž poškodí dodavatelský řetězec.
  4. Zero day vulnerability Apple patch
    • Chyba umožnila útočníkům spustit libovolný kód při zpracování speciálně vytvořeného webového obsahu.
    • Podle výzkumníků je možné, že chyba byla pravidelně zneužívána.
    • O dané zranitelnosti nebylo zveřejněno více informací ani vyjádření.
  5. Revolut ztratil 20 milionů dolarů kvůli zneužití platebního systému
    • Problém spočíval mezi nesrovnalostmi v americkém a evropském systému společnosti.
    • Při odmítnutí některých transakcí byly prostředky chybně vráceny z peněz Revolutu.
      • Útočníci prováděli drahé nákupy, které by byly dále odmítány, a vrácené částky pak byly vybírány z bankomatů.
    • Chyba byla odhalena už v roce 2021, ale než se začala řešit, využili toho zločinecké organizace.
    • Přesné detaily zatím nebyly zveřejněny.

😂 Závěrečný ftípek: What do you call a group of math and science geeks at a party? Social engineers.

🔔 Sledujte nás na LinkedInu, kam pravidelně sdílíme další novinky a know-how.

🆘 S bezpečností vám rádi pomůžeme, klidně nám napište - školíme vývojáře i management, nastavujeme procesy, vyvíjíme bezpečné aplikace a poskytujeme další služby.