Testování nesprávného zpracování chyb

Všechny typy aplikací generují různé typy chyb z různých důvodů
Vývojáři často ignorují ošetřování těchto chyb
- Nebo se vyvarují myšlenky, že by se uživatel pokusil vyvolat chybu záměrně
Díky tomu může vývojář zapomenout na některé případy a chyby tak nedokáže zpracovat
Chyby vznikají jako
- stack trace
- network timeout
- nesoulad vstupů (input mismatch)
- výpis paměti (memory dump)
Nesprávné zpracování chyb může útočníkovi umožnit
- porozumět interně používaným API
- zmapovat služby, získat přehled o interních systémech a používaných frameworcích, což otevírá dveře k dalším útokům
- zjistit verze a typy používaných aplikací
- donutit systém k tomu, aby se dostal do slepé uličky (DoS) nebo k tomu, aby došlo k výjimce, která způsobí systémovou paniku
- řídit obcházení systému

Cíle testu

Chyby poskytují diagnostické údaje a zprávy, které pomáhají problém pochopit nebo ho odladit
Systém může prozradit, co se děje na pozadí po odeslání neočekávaných dat nebo zkoušením edge case scénářů
- V případě, že vývojáři nevrátili vlastní chybovou zprávu

Webové aplikace musí zpracovávat a analyzovat HTTP požadavky
Webové servery mají známé chybové zprávy a formáty
- Pokud je neznáte, můžete si je vyhledat na internetu, v dokumentaci nebo si server lokálně spustit a chyby zjistit procházením stránek

Hledejte náhodné soubory a složky, které nebudou nalezeny (404)
Vyžádejte si existující složky a sledujte chování serveru (403, prázdná stránka, výpis adresáře)
Odešlete požadavek, který porušuje HTTP RFC
1. Použijte velmi dlouhou cestu, porušte formát hlaviček, změňte verzi HTTP protokolu
- I když jsou chyby ošetřeny na úrovni aplikace, může porušení HTTP RFC způsobit, že se web server projeví - musí zpracovat požadavek

Jsou náchylné k nejrůznějším chybám od zobrazování stack trace, přes výpisy paměti až po obecné chyby a chybně zpracované výjimky
Důvodem je tvorba aplikací na zakázku, kde musí vývojáři sledovat a ošetřovat všechny možné chyby
- Chyby se mohou objevit například z integrací s cizími službami

Identifikujte vstupní místa, kde aplikace očekává data
Analyzujte očekávaný typ vstupu (řetězce, čísla, JSON, XML)
Fuzzujte každý vstupní bod na základě předchozích kroků
- Tím získáte cílenější testovací scénář
- Fuzzing není nejlepší řešení, pokud nemáte neomezený čas na testování a aplikace nezvládne tolik vstupů
- Fuzzing by měl být prováděn pro každý typ, protože někdy se interprety rozbijí mimo zpracování výjimek
1. Zvolte takové vstupy, které mají největší šanci prolomit určitý parser, pokud fuzzing nepřipadá v úvahu
  - Uzavírací závorka pro JSON, dlouhý text, CLRF injection, speciální znaky
Porozuměte službě, která reaguje chybovou zprávou
1. Vytvořte přesnější seznam fuzzů, čímž získáte více informací nebo podrobnosti o chybě

Chybové služby jsou někdy hlavní slabinou, zejména v rámci mikroslužeb
Pokud služby nejednotně nezpracovávají chyby, mohlo by to útočníkovi pomoct určit, která služba požadavky zpracovává
- Tím může lépe cílit své útoky

Sledujte pozorně typ odpovědi jako tester
- Chyby se někdy vracejí jako úspěch (200), ale tělo obsahuje chybu
- Mohou se také schovat do kódu 302 nebo se reprezentovat vlastním způsobem