PHP - mikroslužby - autentizace

[vesterna12]

Čas opustit monolit.
Chtěl bych aplikaci rozložit do několika mikroslužeb kvůli škálování. Pro autentizaci k mikroslužbám bych rád použil "cookie", která by obsahovala info o autentizaci a autorizaci. Cookie by byla šifrována certifikátem. Přijde mi to jaké dobré řešení. Taky se vyhnu bombardování databáze pro každý dotaz na autorizaci. Pro nucené odhlášení všech uživatelů bych vynutil zneplatnění všech "cookie", které nemají id administrátora a časové razítko starší XY.
Jsem úplně mimo? Existuje elegantnější řešení?

[Reklama]

[PanVP]

Cookie mohou být samostatně chráněné certifikátem?

Já myslel, u Cookie můžeš nastavit, že se musí přeposílat jen skrz HTTPS spojení.
To je dobrý požadavek, aby nedocházelo k posílání cookie přes nešifrované spojení a případné krádeži Cookie.

Ale samostatně chránit Cookie vlastním certifikátem?
Zajímavé, umí to všechny prohlížeče?
Máš nějaký odkaz? Asi blbě googluju, samostatný certifikát pro cookie nedokážu najít.

[Filip Jirsák]

Existuje (víceméně) standardní řešení – JSON Web Token. Je to podobné jako to, co jste vymyslel – údaje zapsané v JSON struktuře a to celé podepsané (buď jen hash nebo certifikát). Nucené odhlášení se řeší tak, že samotný JWT používaný při komunikaci má krátkou dobu platnosti a klient si ho musí relativně často obnovovat – při obnovení komunikuje s autorizačním serverem a ten má možnost token neobnovit.

Token se pak obvykle předává standardní hlavičkou Authorization, ve webovém prohlížeči není uložen v cookies ale v sessionStore, odkud si ho musí klientská webová aplikace explicitně vyzvednout a předat do hlaviček. Je to bezpečnější než cookies, které prohlížeč předává automaticky. Pokud se útočníkovi podaří vyvolat nějaký požadavek z prohlížeče na vaše API, prohlížeč přiloží cookie automaticky. Když se musí token načítat ze sessionStore, musel by útočník spustit JavaScript v rámci příslušné webové aplikace na dané doméně, čemuž se dá mnohem lépe bránit.

[Filip Jirsák]

Cookie mohou být samostatně chráněné certifikátem?

Obsah cookie může být podepsán veřejným klíčem. Třeba úplně stejně, jako je podepsán obsah JWT. Klidně může být obsahem cookie i přímo JWT. Ale jak jsem psal, z bezpečnostních důvodů je lepší se cookie vyhnout, protože nad jejím odesíláním nemáte takovou kontrolu – teď se SameSite je to už výrazně lepší, ale podpora v prohlížečích ještě není 100%, o jiných klientech nemluvě.

[PanVP]

To je velmi zajímavé!

Zběžně jsem prolítl i obsah https://jwt.io/introduction

Jinými slovy, i když něco kouká do samotného spojení (něco podvrhuje certifikát a provádí HTTPS inspekci), tak obsah je tajný.

[Reklama]

[okalousek]

Existuje (víceméně) standardní řešení – JSON Web Token. Je to podobné jako to, co jste vymyslel – údaje zapsané v JSON struktuře a to celé podepsané (buď jen hash nebo certifikát). Nucené odhlášení se řeší tak, že samotný JWT používaný při komunikaci má krátkou dobu platnosti a klient si ho musí relativně často obnovovat – při obnovení komunikuje s autorizačním serverem a ten má možnost token neobnovit.

Token se pak obvykle předává standardní hlavičkou Authorization, ve webovém prohlížeči není uložen v cookies ale v sessionStore, odkud si ho musí klientská webová aplikace explicitně vyzvednout a předat do hlaviček. Je to bezpečnější než cookies, které prohlížeč předává automaticky. Pokud se útočníkovi podaří vyvolat nějaký požadavek z prohlížeče na vaše API, prohlížeč přiloží cookie automaticky. Když se musí token načítat ze sessionStore, musel by útočník spustit JavaScript v rámci příslušné webové aplikace na dané doméně, čemuž se dá mnohem lépe bránit.

no problém je že JWT se nedá revokovat a platí pořád pokud jsou platné klíče.

[oss]

Token se pak obvykle předává standardní hlavičkou Authorization, ve webovém prohlížeči není uložen v cookies ale v sessionStore, odkud si ho musí klientská webová aplikace explicitně vyzvednout a předat do hlaviček. Je to bezpečnější než cookies, které prohlížeč předává automaticky. Pokud se útočníkovi podaří vyvolat nějaký požadavek z prohlížeče na vaše API, prohlížeč přiloží cookie automaticky. Když se musí token načítat ze sessionStore, musel by útočník spustit JavaScript v rámci příslušné webové aplikace na dané doméně, čemuž se dá mnohem lépe bránit.

Ja som myslel, ze uz ten nejaky rok sa localStorage neodporuca pouzivat ako ulozisko pre JWT tokeny.

[Filip Jirsák]

Jinými slovy, i když něco kouká do samotného spojení (něco podvrhuje certifikát a provádí HTTPS inspekci), tak obsah je tajný.

JWT může být šifrované, ale běžně se to nepoužívá. Běžný JWT je jenom podepsaný.

no problém je že JWT se nedá revokovat a platí pořád pokud jsou platné klíče.

Nikoli, viz druhá věta mého komentáře.

[Filip Jirsák]

Ja som myslel, ze uz ten nejaky rok sa localStorage neodporuca pouzivat ako ulozisko pre JWT tokeny.

Co použít jiného? Cookies jsou horší řešení a žádná další alternativa podle mne není. Jaký by byl důvod toho nedoporučení?

[oss]

Ja som myslel, ze uz ten nejaky rok sa localStorage neodporuca pouzivat ako ulozisko pre JWT tokeny.

Co použít jiného? Cookies jsou horší řešení a žádná další alternativa podle mne není. Jaký by byl důvod toho nedoporučení?

To, ze ku local storage ma pristup vsetok javascript, aj ten od tretich stran.
Lepsie je na tom same site & http only cookie, ale to JWT degraduje na obycajnu autentifikacnu cookinu.

Preto sam neviem co pouzit.

[Filip Jirsák]

To, ze ku local storage ma pristup vsetok javascript, aj ten od tretich stran.
Lepsie je na tom same site & http only cookie, ale to JWT degraduje na obycajnu autentifikacnu cookinu.

Preto sam neviem co pouzit.

Ovšem jen JavaScript vložený do mé stránky. Pokud bych se bál toho, že použité knihovny budou dělat neplechu, mám mnohem větší problém, než že získají JWT token. Ten škodlivý kód pak ale stejně může vyvolat HTTP požadavek, ke kterému prohlížeč přiloží i tu HTTP only cookie. Takže to si moc nepomůžu. Jediný rozdíl je v tom, že v případě sessionStorage může škodlivý kód unést JWT pryč (předá ho útočníkovi), zatímco v případě coookies musí útočník pracovat „online“, tj. musí škodit přímo ten vložený kód. Z mého pohledu to není tak vážný problém, abych kvůli tomu používal cookies. Zejména když webová aplikac emusí být zabezpečena tak, aby v jejím kontextu nikdo nemohl psouštět svůj JavaScript, a když tohle splněné není, je už skoro všechno jedno.

[Johnny]

Tady máte shrnutí všech důvodů, proč k tomu nepoužít JWT.
tl;dr; špatně navržený standard.
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid.

[vesterna12]

Když se musí token načítat ze sessionStore, musel by útočník spustit JavaScript v rámci příslušné webové aplikace na dané doméně, čemuž se dá mnohem lépe bránit.

Čistě teoreticky. Útočník podvrhne DNS a přesměruje klienta na svůj server. Tam mu vnutí JS a k tomu tokenu se stejně dostane. Je to tak? To stejné platí o cookies. Klidně by tak mělo jít přečíst PHP_SESSION_ID.
Jedině kdyby klient kontroloval certifikační autoritu, která podepsala certifikát web serveru. Pak by útočník musel napadnout přímo server kde aplikace běží. 

[Filip Jirsák]

Tady máte shrnutí všech důvodů, proč k tomu nepoužít JWT.
tl;dr; špatně navržený standard.
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid.

Což se ovšem nevyřeší tím, že se použije samo-domo řešení, které je v zásadě založené na stejných principech, jako JWT, akorát je podstatně méně promyšlené. (Což není nic proti vesterna12, vymyslet dobré autorizační schéma není nic jednoduchého – proto je také daleko lepší použít něco hotového a ověřeného, byť třeba nedokonalého, než vymýšlet vlastní řešení).

K samotnému článku – to nejsou důvody, proč nepoužívat JWT. Je to pár věcí, které lze s JWT udělat špatně nebo pro které JWT nepoužívat.

[Filip Jirsák]

Čistě teoreticky. Útočník podvrhne DNS a přesměruje klienta na svůj server. Tam mu vnutí JS a k tomu tokenu se stejně dostane. Je to tak? To stejné platí o cookies. Klidně by tak mělo jít přečíst PHP_SESSION_ID.
Jedině kdyby klient kontroloval certifikační autoritu, která podepsala certifikát web serveru. Pak by útočník musel napadnout přímo server kde aplikace běží.

Pokud útočník ovládne doménu, nemáte jak se mu bránit – prohlížeč si bude myslet, že komunikuje s legitimním serverem a dovolí mu všechno – číst sessionStorage, bude mu odesílat cookies, dovolí vložit do formuláře uložená hesla.

Dneska už to ale reálně nebude fungovat přesměrováním DNS, protože jakýkoli rozumný web jede přes HTTPS s certifikátem od důvěryhodné certifikační autority. HTTP klienti certifikáty kontrolují, takže útočník, který by přesměroval přes DNS jednoho klienta, má smůlu. Pokud by se ovšem útočníkovi podařilo přesměrovat DNS globálně (nejspíš tak, že získá přístup do správy DNS příslušné domény), nechá si vygenerovat i důvěryhodný certifikát.