Podvržení HTTP hlavičky Host – zranitelnost
- Michal S.
- Člen | 3
Zdravím,
měli jsme ve firmě penetrační testy a odhalili zranitelnost v Nette.
Sice máme aktuálně ještě stařičné Nette 2.0 ale koukal jsem že
i v nových verzích jsou požadavky řešeny stejně.
Jde o možnost podvržení HTTP_HOST a které si potom nette bere a používá
ho pro odpověd.
Poté odpověď od serveru přesměruje uživatele na stránku definovanou
v podvržené hlavičce.
Vyřešit se to nechá tím, že se na startu prostě HTTP_HOST smaže, či se bude kontrolovat.
Místo využití HTTP_HOST : Nette\Http\RequestFactory::getServer()
Výsledek z penetračních testů:
Závažnost: střední
Pravděpodobnost: střední
OWASP kategorie: OTG-CONFIG-001 – Test Network/Infrastructure
Configuration
Riziko:
Pokud by útočník byl schopný manipulovat s hlavičkou „Host“, mohl by
zranitelnost zneužít
k přesměrování uživatele na podvodnou webovou stránku.
Přesměrování může předávat citlivá data, např. hesla uživatelů.
Vzhledem k tomu, že
k přesměrování dochází z důvěryhodné aplikace (na URL zadanou
útočníkem), může být
důvěra uživatelů k aplikaci využita k úspěšnějšímu
phishingovému útoku
Doporučení:
Doporučujeme, aby aplikace vždy používala hodnotu ze SERVER_NAME
nastavení
webového serveru namísto hlavičky Host a příchozí dotazy s pozměněnou
hlavičkou Host
zamítla.
Nicméně chci zjistit váš názor na tento problém.
Děkuji za odpověď/názor či smysluplnější řešení.
Michal
- mystik
- Člen | 308
Aby utocnik podvrhl HTTP_HOST musel by uz mit primo kontrolu nad browserem uzivatele, ktery posila request a tim padem by si stejne mohl presmerovavat podle libosti. Pokud teda komunikace probiha pres HTTPS jinak by to bylo realne riziko ze hlavicku zmeni utocnik cestou, ale s HTTPS tam moc riziko nevidim.
- mystik
- Člen | 308
Navic s podvodnou Host hlavickou by server nejspis ani request nezpracooval, protoze by neodpovidal zadne site kterou server zna. Takze by takovy request bud uplne odmitl nebo by to padlo do default site. Pokud tedy server neni nakonfigutovany tak ze aplikace bezi na default site (bez kontroly domeny) tak to taky nelze zneuzit. A pokud by to bezelo na dafault site tak zase nejspis nebudes mit spravne hodnotu v SERVER_NAME pokud nemas nejakou hodne nestandardni konfiguraci.
- Václav Pávek
- Backer | 100
Přikláněl bych se popisu co psal @mystik. Pokud bych chtěl manipulovat s obsahem webu (phishing) tak bych se uživatele snažil dostat na svůj proxy server a obešel tím případné komplikace na straně aplikace či aplikačního serveru. Nicméně jsem se snažil vymyslet různé scénáře a vždy jsem skončil na konfiguraci webserveru. Ve vašem případě musel aplikace běžet jako default site tj. je jedno s jakým hostem jsem se dostal na webserver, třeba i skrze IP adresu.
Ohledně hlavičky HOST, jedná se o standardní hlavičku pro HTTP request kdy na jednu IP mohu dotazovat několik hostů.
- https://developer.mozilla.org/…Headers/Host
- https://curl.se/…manpage.html#…
curl --header 'Host: a.example' https://x.example
Editoval Václav Pávek (12. 1. 13:02)
- Michal S.
- Člen | 3
Běželo to na našem testovacím IIS serveru nad HTTPS.
Hlavičku se jim podařilo podvrhnout a jelikož se používá pro redirect, tak
odpoved ze serveru přesměruje uživatele na podvrženou stránku.
Nicméně nevím jak a jestli je možné v reálném provozu uživateli
podstrčit hlavičku.
Pokusím se tedy ještě podívat na nastavení IIS.
Myslíte tedy že by to mohlo být jen tím, že není na serveru v bindings
nastaveno HOST_NAME a je tam pouze IP adresa serveru a o DN se tedy stará asi
jen DNS a není řešeno v rámci IIS (nebo tak nějak)?
PS: V nastavení IIS se moc nevyznám.
Editoval Michal S. (12. 1. 17:54)
- mystik
- Člen | 308
V realnem provozu na HTTPS hlavicku nepodstrcis a pokud mas nejakou moznost ji podstrcit tak mas soucasne jednodussi moznosti jak ten redirect udelat primo.
Musite mit IIS nastaveny tak, ze prijima jakekoli prichozi spojeni bez ohledu na domenu. V beznem provozu by kazda site mela byt nastavena jen pro konkretni domeny a neprijmat jakekoli pripojeni.