Dříve nebo později se v penetračním testování webových aplikací dostanete k testování vstupů. V dnešním příspěvku si vysvětlíme, co je to rozhraní, jak vypadají vstupní body webové aplikace a jak je provolat.
Rozhraní aplikace
Webová aplikace zpracovává nebo prezentuje data přes jedno nebo více rozhraní. Každé rozhraní má svoji formu a vynucuje si přenos dat určitým způsobem. Pojďme si představit základní typy rozhraní:
- webové – grafické rozhraní, které vyžaduje interakce s uživatelem pomocí webového prohlížeče (HTTP),
- programové API – volání využívá klient nebo další služba v roli klienta,
např. REST API (HTTP) nebo Webové Služby (HTTP+SOAP). - příkazová řádka – uživatel nebo jiná služba komunikuje s aplikací pomocí příkazové řádky operačního systému.
Z pohledu bezpečnosti musíme vždy testovat všechna rozhraní, která aplikace nabízí. Webová aplikace může mít například jedno grafické rozhraní pro webové uživatele, druhé grafické rozhraní pro administrátora a třetí může být rozhraní pro webové služby. Bezpečnostní chyba na jednom rozhraní může položit celou aplikaci.
Vstupní body aplikace
Aplikace na svém rozhraní nereaguje pouze na uživatelské datové vstupy. V aplikaci najdeme i další vstupy, které mohou ovlivnit chování dílčích komponent. Například nečekaný vstup může vyvolat chybu ve frameworku nebo v aplikačním serveru. Mezi vstupní body aplikace patří také různé konfigurační parametry nebo data z externích systémů se kterými aplikace komunikuje.
Jako penetrační tester budete chtít otestovat všechny interakce, které jsou v aplikaci možné a k tomu potřebujete identifikovat všechny vstupní body na každém rozhraní. Je potřeba si uvědomit, že některé vstupní body vyžadují jiný stupeň oprávnění, abyste je mohli provolat. Z tohoto důvodů se hodí mít testovací účty s různými právy.
HTTP požadavek
Není překvapením, že webové aplikace fungují nad protokolem HTTP a proto budeme vstupní body aplikace hledat v HTTP požadavcích. Každý takový požadavek má HTTP hlavičku a tělo zprávy.
V HTTP hlavičce zaostříme na tyto vstupní body:
- URL adresa s parametry za otazníkem, tzv. “QueryString” parametry,
- HTTP metoda – zkoušíme zaměnit GET, POST, PUT, DELETE,
- HTTP hlavičky Cookie, Referer, User Agent.
V těle zprávy pak najdeme datové vstupy specifické pro webovou aplikaci, které odchytíme během testování. Typicky jde o různé uživatelské datové vstupy z formulářů doplněné o parametry prezentace dat, jako na následujícím příkladě.
V celém HTTP požadavku najdeme několik vstupních bodů. Hlavička a tělo zprávy jsou odděleny prázdným řádkem.
V HTTP hlavičce na prvním řádku vidíme metodu POST spolu s URL adresou. Všimněte si, že součástí URL adresy jsou i další parametry, které následují za otazníkem: page a size.
Za zmínku stojí HTTP hlavička User-Agent, která identifikuje webový prohlížeč, který požadavek vyslal. Dále tu máme HTTP hlavičku Referer, která ukazuje na předcházející URL adresu, ze které jsme přišli. V samotném těle zprávy HTTP požadavku najdeme vstupní parametry v JSON formátu: text, searchAll a finished.
Poznámka: Přítomnost JSON formátu v HTTP většinou znamená, že součástí webové aplikace je JavaScript frontend, který neustálé zasílá HTTP požadavky na server a zpracovává příchozí HTTP odpovědi v JSON formátu. Následně aktualizovaná data dynamicky prezentuje v HTML dokumentu. V ostatních případech najdete v těle HTTP odpovědi klasické HTML.
Testujeme vstupní body
Když už jsme identifikovali vstupní body, zkusíme si jeden z nich „provolat“. K tomu budeme potřebovat testovací proxy, která nám umožní HTTP požadavek zachytit a změnit.
Mezi oblíbené testovací webové proxy patří Burp Suite a jeho open source kolegyně OWASP ZAP. Bez ohledu na testovací nástroje se dostáváme k samotnému postupu testování vstupního bodu aplikace.
Představte si, že máme uložený HTTP požadavek a na označený vstupní bod zasíláme svoje testovací data, jak ukazuje následující obrázek.
- Nejdříve na vstupní bod posíláme správná (očekávaná) data. Tím se ujistíme, že lze vstupní bod správně „provolat“ a navíc se dozvíme, jak vypadá správná reakce aplikace. To nám později umožní rychle zjistit, že naše další testy jsou „mimo“ a aplikace data zahazuje.
- Následně posíláme úmyslně špatné vstupy a zkoumáme v HTTP odpovědích stavové kódy a jednotlivé zprávy.
HTTP odpověď – analýza status kódu
Stavový kód nalezneme v hlavičce HTTP odpovědi hned na prvním řádku. Stavový kód nás informuje o tom, jak dopadla obsluha našeho HTTP požadavku. Následující obrázek ukazuje typickou HTTP odpověď se stavovým kódem „200 OK“.
Zkoumání stavového kódu se můžeme o testovaném vstupu a jeho datech ledasco dozvědět. Následující tabulka shrnuje, co se může stát.
Zaslaná data | stavový kód HTTP odpovědi | Reakce aplikace | Poznámka |
správná | 200 | přijala vstup | OK |
úmyslně špatná | 200 | zobrazuje chybu uživateli | Aplikace poznala, že je něco špatně a snaží se uživatele poučit. |
úmyslně špatná | 500 | „Server error“ | Zaslaná data do aplikace nejspíš ani nedorazila. Poškodili jsme strukturu HTTP požadavku a web server odmítl požadavek zpracovat. |
úmyslně špatná | jiný | odmítla vstup | Aplikace se nezmohla na uživatelsky přívětivou hlášku, protože se nepředpokládá, že by normální uživatel něco takového posílal. |
Poznámka: V praxi budou některé HTTP požadavky vyžadovat, že se musíte v aplikaci dostat do nějakého konkrétního stavu a mít potřebný stupeň oprávnění pro provedení operace.
HTTP odpovědi – analýza těla zprávy
Analýza těla zprávy HTTP odpovědi je specifická pro každou webovou aplikaci. Pro jednoduchost předpokládejme, že se námi zaslaný vstup „odrazí“, tj. webová aplikace jej prezentuje hned v odpovědi.
Začneme-li v HTTP odpovědi hledat zaslaná data, dojdeme k těmto závěrům.
Objevila se zaslaná data v odpovědi? | Změnil se jejich podoba? | Dedukce | Poznámka |
ano | ne | aplikace přijala vstup | zkoušíme najít důkaz zneužití (popsat zranitelnost) |
ano | ano | aplikace používá pro daný vstup filtr, který data očistil | musíme zjistit, jak filtr funguje a zde je možné jej obejít |
ne | – | aplikace používá pro daný vstup filtr, který data odmítl a zahodil | musíme zjistit, jak filtr funguje a zde je možné jej obejít |
chyba | – | chybový stav | zkoumáme pečlivě popis chyby a znaky, které chybu způsobily |
Analýzou HTTP odpovědí pomalu odkrýváme, jak funguje validace vstupů pro jednotlivé vstupní body aplikace. Nakousli jsme pojem filtru, který čistí nebo zahazuje datové vstupy.
Záměrně zde nemluvíme o tom, jak vhodně tvořit testovací data, protože bychom museli zvolit konkrétní test a webovou aplikaci. Asi tušíte, že vstupní filtr, který má bránit zneužití formulářového pole na XSS bude jiný, než filtr na ochranu proti SQL injektáži. Tímto se dostáváme k závěru.
Závěr
V dnešním příspěvku jsme zabrousili do rozhraní webových aplikací a jejich vstupních bodů. Ukázali jsme si na příkladu HTTP požadavku vstupní body webové aplikace a analýzou HTTP odpovědi jsme nastínili úvahy, které pomáhají odkrýt implementaci validace vstupů.
To je pro dnešek vše. Budu se těšit na vaše komentáře. Napište mi, co vám vrtá hlavou a na co jsem v příspěvku zapomněl. Diskuzi k článku najdete na našem facebooku.