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.

  1. 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.
  2. 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.