O víkendu rozvlnila mediální rybník zpráva o zranitelnosti protokolů OAuth 2.0 a OpenID. Alespoň takto většina médií interpretovala nález studenta Singapurské univerzity Wang Jinga. Bohužel se tato interpretace objevila i v článku na domácím serveru Lupa.cz a tak by stálo za to uvést ji na pravou míru. Faktu, že v protokolech samotných problém není, se obšírněji věnuje například John Bradley, jeden z architektů těchto protokolů. Ve svém blogu Bradley trochu ironicky komentuje touhu médií získat stejnou pozornost, jako v případě nedávno objevené skutečné bezpečnostní hrozby Heartbleed, o které jsme psali i na našem blogu.
Velice stručně se tedy pokusím popsat, o co jde. Všechny autentizační protokoly pracují na principu přesměrování uživatele. Uživatel přistupující na web nějaké služby X je přesměrován na web poskytovatele idenit Y a v tomto přesměrovacím HTTP požadavku je v parametru (např. return_to nebo redirect_uri) uvedeno, kam má server Y uživatele vrátit po úspěšné autentizaci. Součástí tohoto zpětného přesměrování jsou obvykle údaje, které se uživatel rozhodl službě X předat. Tento koncept je celkem přirozeně náchylný k použití některého z těchto serverů pro podvrhnutí přesměrovací adresy a vrácení na útočníkem kontrolovaný server. Tato situace se v OWASP terminologii jmenuje open redirect. Všechny autentizační protokoly ve svých specifikacích zmiňují tuto možnost a důrazně doporučují ověřování adres, na které se systém přesměrovává a to jak na straně X, tak na straně Y. Nejde tedy o nic nového, je to věc známá a mnohokrát diskutovaná. Problém tedy není ve specifikaci, ale může nastat v implementaci v rámci jednotlivých systémů, a to v případě, že se implementátoři nebudou držet základních pravidel pro psaní webových aplikací. Např. v mojeID, dříve než server provede přesměrování uživatele na zadanou adresu, ověří si, zda tato adresa je v seznamu adres pro přesměrování zveřejněných poskytovatelem služby. Tím jsme si na 100 % jistí, že přesměrujeme uživatele na stránku poskytovatele služeb tak, jak to uživatel odsouhlasil. Pokud se toto ověření nepovede, důrazně uživatele upozorníme, že by neměl žádné údaje předávat.
Podobným způsobem chrání svoje systémy poskytovatelé služeb, zejména pokud používají přesměrování pro další zpracování předávaných údajů. Tady, jak zmiňuje Wang Jing, může nastat situace, že systém poskytovatele služby má na zmíněné adrese pro zpětné přesměrování chybně povolený open redirect. Důsledek je ten, že pokud se útočníkovi podaří přimět uživatele, aby inicioval útočníkem podvržené přihlášení, jehož součástí je zpětná adresa obsahující přesměrování na útočníkovu stránku, uživatel se vědomě přihlásí a potvrdí, že takovému poskytovateli důvěřuje. Dojte tedy k tomu, že se předávané údaje ocitnou na serveru útočníka.
Asi není možné se zaručit, že všichni poskytovatelé služeb nemají ve svých systémech slabá místa; po předání údajů do jejich systému už je zpracování požadavku čistě na nich. Ostatně už jen stále rozšířeným nepoužíváním SSL šifrování vystavují uživatele riziku, že dojde k odcizení jejich údajů při přenosu mezi uživatelem a poskytovatelem služby. V mojeID se alespoň snažíme upozornit uživatele, která služba toto šifrování používá a která ne. V konečném důsledku je ale rozhodnutí zda službu použít nebo ne na samotném uživateli.
Pokud se hlasim pres MojeID na email od seznam.cz obdrzim nasledujici hlaseni:
Předání údajů z mojeID
Tento požadavek na přihlášení přes mojeID o sobě tvrdí, že přichází z jiné stránky, než tomu ve skutečnosti je. Zvažte, zda vůbec chcete pokračovat s předáváním údajů z Vašeho mojeID.
Přihlásit k:http://*.szn.cz/
Kdyz tedy ne zcela bezpecne povolim predani informaci jsem skutecne presmerovan na email od seznamu. Kde je tedy chyba? Seznam neni ve vasem seznamu o predavani informaci, nebo se jedna o neporadek s domenami seznamu?
V pripade Seznamu je duvodem te informacni hlasky to ze Seznam neimplementuje moznost overeni toho presmerovani podle specifikace OpenID 2.0. Jde o to ze pokud pouzivaji pro svoji identifikaci URL http://*.szn.cz, pouzije se pro overeni navratove adresy informace ktera se hleda na adrese http://www.szn.cz a to bez redirektu. Ted je na teto adrese redirekt na http://login.szn.cz a podle specifikace v takovem pripade musi overeni selhat – https://openid.net/specs/openid-authentication-2_0.html#return_to_verification
Neni to tak davno co to meli spravne, ale vypada to ze pri nejakych upravach homepage to zmizelo. Resenim je bud zmena identifikace na login.szn.cz nebo zruseni redirektu. Zkusime jim napsat a uvidime. V tomto pripade se tedy nejedna o podvrzene prihlaseni ale nas system to nedokaze z jimi poskytnutych informaci detekovat.
Prima, diky za reakci a osvetleni situace :)
Tak Seznam zareagoval rychle a tato varovná hláška se již při přihlašování na služby Seznamu pomocí mojeID nevyskytuje.
Funguje jeste prihlaseni na seznam.cz pomoci MojeID?
Dnes jsem to poprve zkusil a :
Nepodařilo se ověřit Vaši identitu. return_to does not match return URL. Expected ‚https://login.szn.cz/loginOIVerify?username=…
Chtel jsem si sparovat svuj ucet u seznamu s mojeid.
Napsali jsme do Seznamu a problem vyresili. Ted uz by to tedy melo fungovat stejne jako driv.