HTTP Parameter Pollution (HPP)

Úvod – krátce o problematice a historii HPP

V dnešní době je velké množství komponent webových aplikací na internetu spouštěno přímo na počítači návštěvníka webové stránky (jako např. JavaScript), místo toho, aby se spouštěly na straně serveru, na kterém je webová stránka hostována, jedna se tak nejčastěji z důvodů náročnosti a vytížení hostujícího serveru. S průběhem času se webové aplikace přirozeně stávají složitějšími a jsou na ně čím dál tím větší nároky ze všech možných ohledů, to často způsobuje, že i na pohled velmi jednoduchá webová aplikace bude pracovat s velkým množstvím HTTP parametrů. Samozřejmě platí, že s čím větším množstvím proměnných pracujeme, tím větší je pravděpodobnost toho, že se něco pokazí, ať už náhodou nebo záměrně. Toto nám nabízí široké spektrum zranitelností, kterých se dá zneužít např. ve formě SQL Injection, Command Injection nebo XSS.

Tyto zranitelnosti jsou však známy již delší dobu a jsou relativně extenzivně prozkoumány, což je činní méně účinnými, než byly v minulosti, tím, že jsou proti nim webové aplikace častěji chráněny. Nic to však nemění na jejich stálé četnosti. Avšak relativním nováčkem ve světě zranitelností je právě HTTP Parameter Pollution (česky znečišťování parametrů HTTP). Přestože tato zranitelnost teoreticky existuje již od samotného počátku zavedení standartu HTTP v roce 1991, tak oficiálně upozorněno na ni bylo až v roce 2009 na konferenci OWASP v Polsku přednášejícími Stefano di Paola a Luca Carettoni. To, že na tuto zranitelnost bylo upozorněno tak relativně pozdě je proto, že její efektivnější využití je velmi ošemetné a nějakou dobu trvalo, než se objevilo dostatek případů, které by z ní udělaly reálnou hrozbu.

Fungování HTTP Parameter Pollution

Jak jsme si již řekli, HTTP Parameter Pollution spočívá ve znečišťování parametrů HTTP. Znečišťování je prováděno za účelem vyvolání nevšední reakce webové aplikace, díky které lze nějak zneužít chování dané aplikace. HTTP funguje na principu žádost-odpověď, náš prohlížeč pošle serveru webové aplikace žádost a server na žádost odpovídá, HTTP Parameter Pollution zneužívá právě toho, že není nijak sjednocen formát žádostí, které zasíláme, protože takové sjednocení není reálně proveditelné díky širokému spektru druhů webových aplikací. Nejčastěji se při HTTP Parameter Pollution pracuje s žádostmi typu GET a POST. GET žádost očekává odpověď ve formě nějakých dat od zdroje a posílá se ve formě URL. POST žádost posílá data, která budou zdrojem zpracována, a nachází se v body HTTP requestu.

Znečištěním parametrů v těchto žádostech získává útočník možnosti:

• obejít WAFs pravidla nebo vstupní validaci
• přizpůsobovat chování protější strany svým požadavkům
• získat skryté informace
• modifikovat proměnné, natvrdo uložené na protější komunikační stráně

Všechny z těchto možností kompromitují zabezpečení webové aplikace, takže umožňují útočníkovi zneužít jejího chování k jeho prospěchu.

Nakládání s parametry

HTTP umožňuje více výskytů jednoho parametru v jedné žádosti, to znamená, že se webová aplikace musí rozhodnout, jak naloží s každou instancí výskytu parametru. To, jak se bude rozhodovat, závisí na použité technologii back-endu webové stránky – druhu webového serveru. Některé mohou brát v potaz pouze první výskyt parametru, některé poslední výskyt a některé výskyty všechny. Příkladový výčet toho, jak technologie zacházejí s více výskyty jednoho parametru, obsahuje následující tabulka, která byla součástí výše již výše zmíněné přednášky na polské konferenci OWASP v roce 2009.

Zacházení s více výskyty parametru
Technologie	Přebíraný parametr	Příklad
ASP.NET/IIS	Všechny výskyty	par1=val1,val2
ASP/IIS	Všechny výskyty	par1=val1,val2
PHP/Apache	Poslední výskyt	par1=val2
PHP/Zeus	Poslední výskyt	par1=val2
JSP,Servlet/Apache Tomcat	První výskyt	par1=val1
JSP,Servlet/Oracle Application Server 10g	První výskyt	par1=val1
JSP,Servlet/Jetty	První výskyt	par1=val1
IBM Lotus Domino	Poslední výskyt	par1=val2
IBM HTTP Server	První výskyt	par1=val1
mod_perl,libapreg2/Apache	První výskyt	par1=val1
Perl CGI/Apache	První výskyt	par1=val1
mod_perl,lib???/Apache	Přichází jako pole	ARRAY(0x8b9059c)
mod_wsgi(Python)/Apache	První výskyt	par1=val1
Python/Zope	Přichází jako pole	['val1','val2']
IceWarp	Poslední výskyt	par1=val2
AXIS 2400	Všechny výskyty	par1=val1,val2
Linksys Wireless-G PTZ Internet Camera	Poslední výskyt	par1=val2
Ricoh Aficio 1022 Printer	První výskyt	par1=val1
WebcamXP PRO	První výskyt	par1=val1
DBMan	Všechny výskyty	par1=val1~~val2
https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf

Jak vidíme, tak se chování jednotlivých technologií webových serverů od sebe může velmi značně lišit, a právě neobvyklé chování je obvyklým zdrojem bezpečnostních slabin.

Dělení útoků HTTP Parameter Pollution

Útoky HTTP Parameter Pollution můžeme rozdělit podle toho, co je cílem daného útoku. Pokud útočíme na front-end webové aplikace, tedy snažíme se obelstít uživatele webové aplikace tak, aby jeho akce měli jiný účinek, než očekává, tak mluvíme o client-side HTTP Parameter Pollution. Na druhé straně, pokud útočíme na back-end webové aplikace, tedy snažíme se způsobit nezvyklé chování na serverové straně, tak se jedná o server-side HTTP Parameter Pollution. Uvedeme si názorné příklady k oběma přístupům.

Client-side HTTP Parameter Pollution – příklad

Již ošetřená HPP zranitelnost na stránkách Twitter.com umožňovala útočníkovi přimět uživatele stránky k sledování jiného účtu, než který uživatel chtěl vybrat ke sledování.

Zranitelnost zneužívala procesu označení tweetu za oblíbený – uživatel označil tweet za oblíbený, následně mu byla nabídnuta možnost sledovat účet, která daný tweet zveřejnila, a pokud si uživatel vybral účet sledovat, tak začal místo toho sledovat jiný účet, který určil útočník. Útočník totiž vložil parametr screen_name do URL, ve kterém tento parametr původně vůbec neměl být, který se následně přenesl do dalšího URL, pomocí kterého si uživatel vybere sledování účtu původce tweetu.

Server-side HTTP Parameter Pollution – příklad

Také již ošetřená zranitelnost na populární blogové platformě Blogger.com umožňovala útočníkovi převzít vlastnictví nad konkrétním blogem jiného uživatele.

Chyba se vyskytovala v autentizačním mechanismu webové aplikace, kdy bezpečnostní kontrola parametru blogID byla provedena pouze na první instanci výskytu tohoto parametru – blogID útočníka, avšak operace, která měnila parametr authorsList již pracovala s druhou instancí výskytu tohoto parametru – blogID oběti.

Závěr a obrana

Jedná se o technicky jednoduchý ale potenciálně velmi efektivní útok. Zneužívá toho, že HTTP přijímá více parametrů (různými způsoby) a toto v blízké budoucnosti není reálně možné nějak sjednotit. Pomocí HTTP Parameter Pollution lze útočit jak na stranu klienta, tak na stranu serveru – tedy front-end či back-end webové aplikace. Efekt využití dané HTTP Parameter Pollution zranitelnosti velmi úzce souvisí s funkcionalitami dané webové aplikace. Lze kombinovat s ostatními exploity jako např. spouštění JavaScriptů a CSS.

Nejúčinnější obranou je přehled o tom, jak Vaše webová aplikace zpracovává HTTP požadavky, tedy porozumění tomu, jak Vaše stránka funguje a kde by se mohla zranitelnost vyskytnout. Dále je vysoce doporučeno nepoužívání GET requestů při nakládání s citlivými daty, kvůli povaze GET requestu – jsou v otevřené formě URL. Dále je možnost zakázat vícečetné výskyty určitých parametrů, na místech, kde je to proveditelné. Pokročilým přístupem může být i určený Whitelist povolených URL, avšak tento přístup se dá použít jen u hrstky specifických případů a funkcionalit. Také již na trhu existují placené i neplacené softwarové aplikace, které Vaši webovou aplikaci zkontrolují na zranitelnosti druhu HTTP Parameter Pollution.

Související materiály: prezentace

Autoři: Yehor Safonov, Pavel Mazánek

Příspěvek vznikl v rámci studia programu Informační bezpečnost (odkaz).