Přeskočit na hlavní obsah

Validace vstupu

  • 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
  • Data ze všech nedůvěryhodných zdrojů by měla podléhat validaci
    • Nejen uživatelská data, ale také data z jiných systémů, třetích stran, dodavatelů atd.
    • Každý z nich totiž může být kompromitován a odesílat chybná data
  • Validace vstupů by neměla být používána jako primární metoda prevence XSS, SQL injection a dalších
  • Při správné implementaci však může významně přispět ke snížení jejich dopadu

Strategie​

  1. Provádějte validaci jak na syntaktické, tak na sémantické úrovni
  • Syntaktická = zajišťuje správnou syntaxi dat (datum, SSN, symbol měny)
  • Sémantická = zajišťuje správnost hodnot v daném kontextu (datum zahájení, datum ukončení, cena v očekávaném rozsahu)
  1. Předcházejte útokům co nejdříve při zpracování požadavku uživatele
  • K odhalení neoprávněného vstupu lze použít právě validaci

Implementace​

  • Validace lze realizovat pomocí libovolné programovací techniky, která umožňuje vynucení syntaktické a sémantické správnosti
    • Validátory datových typů, které jsou nativně k dispozici ve webových frameworcích (Django validators, Apache Commons Validators, atd.)
    • Validace podle JSON nebo XML (XSD) schématu
    • Konverze typů (Integer.parseInt(), int()) s přísným zpracováním výjimek
    • Kontrola minimálního a maximálního rozsahu hodnot pro číselné parametry a kontrola délky řetězce
    • Pole povolených hodnot pro malé sady string parametrů (dny v týdnu)
    • Regulární výrazy pro jakákoli jiná strukturovaná data pokrývající celý řetězec (^...$) a nepoužívající “libovolný” znak (\S)

Seznam povolených a nepovolených vstupů​

  • Častou chybou je použití validace na základě seznamu nepovolených vstupů ve snaze odhalit nebezpečné znaky a vzory (', 1=1, <script>)
  • Takové filtry je možné triviálně obejít
  • Zároveň tyto filtry brání autorizovanému přístupu, jako je například O'Brian, kde je znak ' legitimní
  • Seznam povolených vstupů je však vhodný pro všechna vstupní data
  • Validace na základě tohoto seznamu zahrnuje definici toho, co je autorizováno s tím, že všechno ostatní autorizováno není
  • Pokud jde o dobře strukturovaná data (rodná čísla, PSČ, emaily), mělo by být snadné definovat silný validační vzor založený na regulárních výrazech
  • Pokud vstupní hodnota pochází ze sady možností (selectbox, radiobutton), pak musí přesně odpovídat jedné z definovaných hodnot selectboxu nebo radiobuttonu

Validace textu ve volném tvaru​

  • Text ve volném tvaru (zejména Unicode) je obtížně validovatelný kvůli velkému množství znaků, které je potřeba povolit
  • Zdůrazňuje důležitost kódování v závislosti na kontextu a ukazuje, že validace není hlavní ochranou proti XSS
    • Pokud uživatelé chtějí do pole pro komentář napsat znaky jako < nebo ', mohou pro to mít legitimní důvod
  • Úkolem aplikace je s textem správně zacházet po celou dobu životního cyklu dat
  • Hlavními zásadami jsou
    • Normalizace - zajistěte, aby bylo v celém textu použito kanonické kódování a aby se v něm nevyskytovaly žádné neplatné znaky
    • Seznam povolených kategorií znaků - Unicode umožňuje zařazení do kategorií, jako jsou čísla, písmena atp.
    • Individuální seznam znaků - na základě kontextu můžete povolit ideogramy, apostrofy, pokud nechcete povolovat celou kategorii interpunkčních znamének

Regulární výrazy​

  1. Při návrhu si dejte pozor na útoky typu ReDoS
    • Způsobují, že program používající špatně navržený regulární výraz pracuje velmi pomalu a dlouho využívá CPU prostředky
  2. Použijte validaci na všechna vstupní data
  3. Definujte povolenou množinu znaků
  4. Definujte minimální a maximální délku dat ({1,25})

Regulární výrazy - seznam povolených znaků

  • Validace US PSČ: ^\d{5}(-\d{4})?$
  • Validace US států ze seznamu (selectbox)
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE|
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|
TX|UT|VT|VI|VA|WA|WV|WI|WY)$
  • Použití v Javě
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");

public void doPost( HttpServletRequest request, HttpServletResponse response) {
  try {
      String zipCode = request.getParameter( "zip" );
      if ( !zipPattern.matcher( zipCode ).matches()  {
          throw new YourValidationException( "Improper zipcode format." );
      }
      // Do what you want here, after its been validated ..
  } catch(YourValidationException e ) {
      response.sendError( response.SC_BAD_REQUEST, e.getMessage() );
  }
}

Client side vs server side validace​

  • Útočník, který zakáže javascript nebo použije proxy, může obejít jakoukoli validaci prováděnou na klientovi
  1. Ujistěte se, že validace prováděná na klientovi je také na serveru

Validace rich user contentu​

  • Rich content je velmi obtížné validovat
  • Více informací najdete v XSS cheat sheetu

Prevence XSS a zásady zabezpečení obsahu​

  • Všechna uživatelská data musí být při vrácení na HTML stránku zakódována
  • Tím se zabrání spuštění škodlivých dat (XSS)
    • Např. <script> by byl vrácen jako &lt;script&gt;
  • Typ kódování je specifický pro kontext stránky
  • Kódování dat, které se vkládají do HTML se bude lišit od kódování při vkládání do javascriptu atd.
  • Více informací najdete v XSS cheat sheetu

Validace uploadu souborů​

Ověření nahrávání​

  1. Zajistěte, aby název nahraného souboru používal očekávanou příponu
  2. Ujistěte se, že nahraný soubor není větší než maximální definovaná velikost souboru
  3. Proveďte kontrolu platnosti před rozbalením souboru v případě ZIP souborů
    1. Zkontrolujte célovou cestu, úroveň komprese a odhadovanou velikost rozbaleného souboru

Úložiště nahraných souborů​

  1. Použijte nový název souboru pro uložení v OS
  2. Nepoužívejte uživatelem zadaný název
    • Např. test.jpg přejmenujte na JAI1287uaisdjhf.jpg (náhodný název souboru)
    • Účelem je zabránění rizika přímého přístupu k souboru a nejednoznačnému názvu souboru
  3. 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

Veřejné podávání nahraného obsahu​

  1. Zajistěte, aby nahrané obrázky byly zobrazovány se správným content type (image/jpeg, application/x-xpinstall)

Dávejte pozor na “speciální” soubory​

  • Funkce nahrávání by měla být založena na seznamu povolených souborů, který povoluje pouze určité typy a přípony
  1. Mějte napaměti, že následující typy souborů mohou vést k bezpečnostním zranitelnostem
    • crossdomain.xml / clientaccesspolicy.xml
      • Umožňuje načítání dat napříč doménami ve Flash, Java a Silverlight aplikacích
      • To může umožnit krádež dat napříč doménami a CSRF
      • Takové soubory je nejlepší zakázat
    • .htaccess a .htpasswd
      • Poskytuje možnost konfigurace serveru pro jednotlivé adresáře
      • Neměl by být povolen
      • Viz dokumentace HTACCESS
    1. Zakažte spusttitelné soubory a skripty - aspx, asp, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi

Validace uploadu obrázků​

  1. Ověřte, zda je obrázek platný a odstraňte z něj cizí obsah pomocí knihoven pro přepisování obrázků
  2. Nastavte příponu obrázku na základě zjištěného typu obsahu (nevěřte pouze hlavičce z nahrávání)
  3. Zkontrolujte, zda je zjištěný typ obrázku v seznamu definovaných typů (jpg, png, atd.)

Validace emailu​

Syntaktická validace​

  • Formát emailových adres je definován v RFC 5321 a je mnohem složitější, než si většina lidí uvědomuje
  • Za platné adresy se považují například tyto
    • "><script>alert(1);</script>"@example.org
    • user+subaddress@example.org
    • user@[IPv6:2001:db8::1]
    • " "@example.org
  • Správné analyzování pomocí regulárních výrazů je složité
  • Ačkoli RFC definuje velmi flexibilní formát, většina implementací (mail serverů) používá mnohem omezenější formát adres
  • Čímž odmítají adresy, které jsou technicky platné
  1. Proveďte základní ověření a poté adresu předejte mail serveru a čekejte, zda ji odmítne nebo ne
    • Emailová adresa obsahuje dvě části oddělené @
    • Neobsahuje nebezpečné znaky (zpětná lomítka, jednoduché a dvojité uvozovky, null bytes)
      • Přesné určení znaků závisí na tom, jak bude adresa použita (zobrazení na stránce, uložení do databáze)
    • Doménová část obsahuje pouze písmena, číslice, pomlčky a tečky
    • Má přiměřenou délku
      • Před znakem @ by nemělo být více než 63 znaků
      • Celková délka by neměla přesáhnout 254 znaků

Sémantická validace​

  • Spočívá v určení, zda je emailová adresa legitimní
  • Nejlepším způsobem je zaslat uživateli email a požadovat, aby kliknul na odkaz v emailu nebo zadal nějaký kód
    • Ověření správnosti adresy
    • Aplikace na něj může odesílat emaily
    • Uživatel má přístup ke schránce
  • Zasílané odkazy by měly obsahovat token, který je
    • alespoň 32 znaků dlouhý
    • generován pomocí bezpečného zdroje náhodnosti
    • na jedno použití
    • časově omezený (např. expiruje po 2 hodinách)

Jednorázové emailové adresy

  • V některých případech uživatelé nechtějí uvádět svou pravou adresu a uvedou jednorázovou
  • Jedná se o veřejně dostupné adresy, které nevyžadují ověření uživatele
  • Používají se ke snížení nevyžádané pošty
  • Zablokování těchto adres je téměř nemožné, protože existuje velké množství stránek nabízejících tyto služby
  • Existuje velké množství seznamů těchto stránek, ale ty budou vždy neúplné
  1. Zobrazte uživateli zprávu s vysvětlením, proč jsou tyto adresy blokovány, pokud tyto seznamy používáte
    • I když si pravděpodobně vyhledá jiného poskytovatele
  2. Povolte registrace pouze některých emailových poskytovatelů, pokud je nezbytné blokování jednorázových adres
    • Např. Google, Yahoo
    • Uživatelé si ale u nich stejně jednoduše vytvoří nový (jednorázový) účet

Sub-addressing

  • Umožňuje uživateli zadat tag v části adresy před @, kterou bude mailserver ignorovat
  • Pokud například doména example.org podporuje sub-addressing (podadresování), pak jsou následující adresy ekvivalentní
    • user@example.org
    • user+site1@example.org
    • user+site2@example.org
  • Mnoho poskytovatelů (např. Microsoft Exchange) takové adresování nepodporuje
  • Nejvýznamnějším poskytovatelem, který sub-addressing poskytuje je Gmail
  • Uživatelé používají pro každou stránku jiný tag, aby v případě, že začnou dostávat nevyžádanou poštu na některou z těchto adres, mohli určit, ze které stránky email unikl nebo kdo jejich adresu prodal
  • Některé weby mohou chtít blokovat sub adresy, protože by uživatel mohl zaregistrovat více účtů na “stejnou” adresu
  • To se obecně nedoporučuje, protože to naznačuje, že
    • majitel webu o sub-addressungu neví
    • chce zabránit identifikaci uživatelů při úniku dat nebo jejich prodeji
  • Navíc to lze jednoduše obejít registrací s jednorázovou adresou

Kam dál​

Checklisty​