Full Path Disclosure (FPD)

Jak již samotný název zranitelnosti napovídá, jedná se o odhalení celé cesty v adresářové struktuře na webovém serveru, kde jsou uloženy soubory webové aplikace. Samotná hrozba spočívá v odeslání takového vstupu webové aplikaci, který povede k vyvolání chybové hlášky, jež bude cestu ke skriptu, v němž došlo k chybě, obsahovat. Nejlepší představu o výsledku zdárného útoku podá následující screenshot.

Můžete si všimnout, že z chybové zprávy se útočník může dozvědět mnohem více informací, než jen samotnou cestu na filesystému. Útočník se dozví například také to, že

• Soubory webové aplikace jsou uloženy v adresáři C:\wamp\www\nette\pokus\;
• adresářová struktura webu obsahuje mimo jiné adresáře www a app;
• samotný skript, ve kterém došlo k chybě, se jmenuje index.php;
• z názvu souboru je možné určit, že je použit skriptovací jazyk PHP;
• první z adresářů wamp prozrazuje použití Apache, PHP a MySQL;
• adresář nette a adresářová struktura prozrazuje použití oblíbeného stejnojmenného frameworku;
• forma zápisu cesty začínající na C:\ prozrazuje, že server běží na operačním systému Windows;
• na serveru je povoleno zobrazování chybových hlášek;
• funkce, která vyvolává chybu (případně přebírá od uživatele parametry) je require(). Některé funkce mohou útočníkovi umožnit další útoky, takže je pro útočníka dobré vědět, která funkce jeho vstup převzala, a jakým způsobem se jej snaží zpracovat;
• výpis zásobníku prozrazuje nadřazené skripty, které skript zobrazující chybovou zprávu inkludovaly.

Jak FPD vyvolat

Je vidět, že z jedné jediné chybové zprávy se toho útočník může dozvědět poměrně hodně. Pojďme si tedy uvést některé možnosti, jak lze podobné zprávy v aplikaci často vyvolat.

Neočekávaný vstup

Pokud aplikace přebírá od uživatele nějakou proměnnou, přičemž je jedno, zda ji obdrží metodou GET, POST, nebo například z HTTP hlaviček, a tuto proměnnou předává některé funkci ke zpracování, pak je dobré otestovat například následující hodnoty vstupů:

• Prázdný vstup
• Dlouhý vstup
• Nepovolený vstup (řetězec místo čísla, bílý znak, chybný unicode znak)

Pokud totiž cílová funkce obdrží jinou hodnotu, než jakou očekává, vrátí s největší pravděpodobností chybovou zprávu.

Přetypování proměnné na pole

Očekává-li funkce jedinou hodnotu a vy jí namísto toho předáte pole, pak se jí to také pravděpodobně nebude líbit a dá vám to patřičně najevo ve formě chybové hlášky. Přetypování proměnné na pole přitom provedete velice jednoduše přidáním hranatých závorek za její název, například:

• http://www.example.cz/search?query=foo
• http://www.example.cz/search?query[]=foo

Hodnota sessionid

Funkce session_start(), která je v PHP běžně využívána, očekává, že jí prostřednictvím cookie předáte smysluplnou hodnotu sessionid, která nebude prázdná a bude obsahovat pouze povolené znaky. Při odeslání prázdné hodnoty sessionid, nebo při vložení nepovolených znaků, proto také často dochází k zobrazení chybové zprávy:

Přímé volání includovaných souborů

Pokud se pokusíte načíst napřímo soubory, které jsou určené k inkluzi, budou jim možná chybět některé údaje nebo objekty definované v nadřazených skriptech, což může opět vyvolat chybové oznámení.

Další možnosti vyvolání FPD

Aplikace může od uživatele přebírat také například XML data, která jsou následně předána XML parseru. Pokud nebude XML obsah zcela validní, může to opět vést k poměrně rozsáhlé zprávě, viz XXE. Pokud můžete vložit vstup, který bude použit jako parametr ve funkci header(), můžete se zase pomocí znaků pro přechod na nový řádek pokusit o vložení více response hlaviček (HTTP response splitting), což je v novějších PHP interpretech zakázáno a váš pokus proto rovněž skončí chybou.

Možností vyvolání FPD existuje nepřeberné množství, takže vždy bude potřeba správně odhadnout, co je na serveru zodpovědné za zpracování vašeho vstupu, a které metaznaky by tak mohly rozhodit synataxi výsledných příkazů. U SQL dotazů to bude například apostrof nebo uvozovka, u Command Execution například středník, ampersand nebo pajpa. V .net aplikacích povede k FPD nezřídka také pokus o vložení HTML kódu do URL.

Redirect a zdrojový kód

Chybové zprávy nemusí být vždy viditelné na první pohled v obsahu webové stránky. Někdy je v prohlížeči objevíte teprve při zobrazení zdrojového HTML kódu stránky, nebo bude potřeba využít lokální proxy (například Burp Suite), přes který necháte komunikaci přesměrovat. Chybová zpráva totiž může být obsažena i ve stránce, která uživatele při výskytu chyby přesměrovává na stránku jinou. V prohlížeči, který bude toto přesměrování následovat, byste proto nebyli schopni takovou chybovou zprávu zachytit.

Už to opravili, ale to nevadí

Ve chvíli, kdy testujete webovou aplikaci, a nebude se Vám dařit žádnou chybovou zprávu tohoto typu vyvolat, nemusíte stále házet flintu do žita. Aplikace mohla podobné chybové zprávy zobrazovat někdy dříve a teprve následně byl jejich výstup ošetřen. Zprávy se mohou vyskytovat také pouze v určitých situacích (například při výpadku databáze), které nejsme schopni explicitně vyvolat. Je ale možné, že Google udělal jednu zásadní věc, totiž, že stránky s chybovými hláškami zaindexoval a zakešoval pro budoucí použití. Přesto, že tedy nejste schopni aplikaci přesvědčit k vydání informací, stále je zde možnost, že znění chybových zpráv naleznete přes Google. Určitě tedy stojí za zkoušku položit mu dotaz podobný následujícímu:

Proč se bát FPD

Znalost celé cesty v adresářové struktuře uplatní útočník například při následných útocích typu SQL injection, XXE, nebo LFD, během nichž se pokusí o čtení lokálních souborů ze serveru (například zdrojových kódů aplikace). Znalost cesty se útočníkovi ale bude hodit také v případě útoků LFI kdy se pokusí o spuštění vlastního kódu uloženého na stejném serveru, nebo bude-li skze SQL injekci či na nesprávně nakonfigurovaném sdíleném webhostingu chtít zapisovat soubory do vašich adresářů.

V tomto odstavci uvedu ještě jednu důležitou věc týkající se chybových hlášení. Se samotnou zranitelností FPD má sice jen pramálo společného, ale když už se bavíme o chybových hlášeních, tak proč to nezmínit. Jedná se o skutečnost, že mnoho interpretů posílá na výstup chybové zprávy včetně vstupu uživatele, a to bez jejich předchozího ošetření potenciálně nebezpečných metaznaků, které mohou vyvolat XSS. Když už se Vám tedy podaří nějakou tu chybu na serveru vykřesat, a ta obsahuje vámi zadaný vstup, určitě nezapomeňte ověřit také to, zda skrze ni není možné spustit kód javascriptu.

Které aplikace jsou náchylné

Ač by se z výše uvedeného textu mohlo zdát, že se tato zranitelnost dotýká pouze aplikací napsaných v PHP, není to tak. Chybové hlášky se vyskytují v libovolném jazyce a i jejich vyvolání bude často obdobné. Následující screenshoty zobrazují ukázky několika FPD z různých prostředí.

Obrana

Jako obrana proti zranitelnosti Full Path Disclusion se běžně uvádí zakázání výpisu chybových hlášek. S tím samozřejmě nezbývá než souhlasit, ale měla by to vždy být až druhá vrstva vícestupňové ochrany. Důležité je věnovat dostatečnou pozornost hlavně validaci vstupů a správnému ošetřování výjimek, aby k podobným chybám vůbec nedocházelo. Pokud například některá funkce očekává na vstupu číslo, neměli bychom jí bezhlavě předat řetězec, pokud jej uživatel vloží.

Závěrem

Co napsat závěrem: Ačkoliv jde o zranitelnost pouze informačního charakteru, protože bez návaznosti na další zranitelnosti serveru nebo aplikace ji není možno účinně zneužít, viděli jste, že není radno ji podceňovat. Útočníkům totiž dokáže poskytnout mnoho relevantních informací a kdo vám zaručí, že se ve vaší aplikaci nenachází místo, kde by se znalost těchto informací mohla hodit…