6.5 Denial of Service (DoS) na aplikační vrstvě

Když se mluví o DoS (Denial of Service), lidé si často představí zaplavování sítě falešnými pakety z botnetů (DDoS na síťové/transportní vrstvě). Z hlediska etického hackování je ale obrovskou zranitelností také DoS na aplikační vrstvě.

Application Layer DoS
Představuje situaci, kdy útočník pomocí velmi malého, specifiky upraveného payloadu, způsobí masivní zpracování na straně serveru, což vede k vyčerpání výpočetních zdrojů (CPU, paměti), zaplnění disků či k pádu služby. Často je tento problém ignorován coby "pouze výkonnostní nedostatek", ačkoliv reálně ohrožuje byznys.
Příklady vektorů pro aplikační DoS
  • Absence horního limitu na data: Server se pokouší načíst miliony znaků do jednoho JSON objektu z HTTP body. Odesláním 10 MB souboru s nesmyslnými daty pro parametr "message" dojde ke zpracování a parsování, zkonzumuje se veškerá paměť backendu.
  • Absence dolního limitu u vyhledávání (Query parameter): Odeslání vyhledávacího požadavku bez specifikace, či naopak obřího nespecifického filtru, nutí databázi k full-scan dotazům, zátěž vyletí na 100%.
  • File Upload dekomprese (Zip of Death): Dekompresní bomby a snahy extrahovat miliony vnořených souborů.
  • Skenování na virus s obřími soubory: Pokud WAF či antivirus musí parsovat masivní nestandardně tvarované požadavky.
Response Filter Denial of Service (RFDoS)
Někdy zasahuje WAF (Web Application Firewall) a u odpovědí, kde nalezne "citlivá" slova (jako např. verze databáze ORA-12345, Microsoft OLE DB Provider), vrací uživateli blokující chybovou hlášku 403 Forbidden na místo originálního obsahu.

Co když ale útočník vloží klíčové slovo (vyvolávající WAF trigger) do svého profilu, e-mailu nebo příspěvku (např. jméno do registrace)? Jakmile jiný, např. legitimní proces aplikace, obdrží tuto stránku (tento komentář či záznam), uvidí "citlivý text" a stránka (nebo účet) bude zablokována pro samotného (legitimního) provozovatele či uživatele, jelikož se mu WAF ohlásí s chybou 403 Forbidden. To efektivně odepře přístup ke službám samotné společnosti. Podobně funguje umístění testovacího řetězce "EICAR" do HTTP hlavičky (např. User-Agent). Infrastruktura pak může odstřihnout celou komunikaci či logovací systémy zkolabují.