Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: vesterna12 30. 07. 2021, 11:41:24

Název: PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 30. 07. 2021, 11:41:24
Č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í?
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: PanVP 30. 07. 2021, 11:59:03
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.

Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 12:06:10
Existuje (víceméně) standardní řešení – JSON Web Token (https://jwt.io). 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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 12:10:08
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 (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite) je to už výrazně lepší, ale podpora v prohlížečích ještě není 100%, o jiných klientech nemluvě.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: PanVP 30. 07. 2021, 12:15:05
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ý.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: okalousek 30. 07. 2021, 12:23:06
Existuje (víceméně) standardní řešení – JSON Web Token (https://jwt.io). 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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: oss 30. 07. 2021, 13:02:57
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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 13:22:09
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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 13:23:37
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í?
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: oss 30. 07. 2021, 14:43:01
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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 15:11:24
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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Johnny 30. 07. 2021, 15:40:57
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 (https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid).
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 30. 07. 2021, 16:21:02
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ěží. 
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 16:25:51
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 (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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 16:58:16
Č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.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 30. 07. 2021, 17:21:07
Č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.

Inu přidaná hodnota sessionStorage vs cookie je pouze ta že token není odeslán při každém požadavku na doménu pokud není získán JS.
Správně?
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 30. 07. 2021, 18:35:59
Inu přidaná hodnota sessionStorage vs cookie je pouze ta že token není odeslán při každém požadavku na doménu pokud není získán JS.
Správně?
Zhruba tak, pro odeslání tokenu uloženého v sessionStorage jej musíte aktivně pomocí JavaScriptu vyzvednout a přidat k požadavku, cookie odesílá prohlížeč automaticky podle stanovených pravidel. Další rozdíl je třeba ten, že cookies jsou společné pro celou instanci prohlížeče, sessionStorage je jen pro jeden konkrétní tab v prohlížeči. Nebo-li při použití sessionStorage můžete být na dvou záložkách v prohlížeči přihlášen jako dva různí uživatelé, v případě cookies to nepůjde.

Proti tomu, že útočník globálně ovládne vaši doménu (bude tedy schopen na ni vystavit důvěryhodný certifikát) se nelze uvnitř webové aplikace bránit. S takovou variantu tedy není nutné při návrhu zabezpečení webové aplikace počítat, řešit se to musí pořádným zabezpečením přístupu k administraci domény (včetně volby důvěryhodného poskytovatele služeb a důvěryhodného registrátora domény).
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 08:47:40
Na JWT sa vykasli, to nie je urcene na komunikaciu browser - server, ale server - server komunikaciu s tym ze server 3 strany ma JWT token ktory mu scvalil uzivatel a dal mu tak pristup k casti svojho uctu. Vytvara sa sice za pomoci browseru ale uklada sa len na servri 3 strany. Regulerne s JWT to vyriesis len redirectom na auth server, kde ak uz nie je prihlaseny tak sa prihlasi uzivatel, server overi ake si mu dal opravnenia, redirectne spat na povodny server a ten si na zaklade secret ktore dostal, vyzdvihne sez api auth servra token ktory si ulozi.

Predpokladam ze ale skor ze ani jeden server nie je servrom 3 strany. V tom pripade sa ti asi skor hodi toto https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04 . Ma to 2 vyhody. 1) na vsetkych servroch bude session id rovnake pre konkretnu session. 2) ak mas horizontalne skalovanu aplikaciu na viacerich servroch za balancerom, tak balanceru bude jedno na ktory server moze poslat poziadavku, session id bude samozrejme na vsetkych rovnake.




Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 08:57:06
Btw, i ked na toto si sa asi nepytal, tak zrusit monolit neznamena ho distribuovat na viacero servrov. Znamena to rozdelit ho na rozumne male baliky. Vzniknu ti tak male kusy kodu, ktore su zavisle na dalsich takychto balickoch, ktore sa omnoho lahsie udrzuju, su znovupouzitelne, a lahko sa pre ne pisu testy( alebo aspom k tym testom nie je taky odpor ako to pisat pre kod ktory ma cez 1000 riadkov). Nasledne ti to zlozi composer bud do aplikacie na jednom servri alebo do aplikacii na viacerich servroch.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 09:13:37
Pletete si JWT s OAuth 2 (kde se JWT také používá, to vás asi zmátlo). vesterna12 chce aplikaci rozdělit na mikroslužby. Vytvořit si závislost mikroslužeb na jednom centrálním serveru pro ukládání session není úplně to nejšťastnější řešení – někdy to samozřejmě dává smysl, ale měl by k tomu být dobrý důvod.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 09:18:42
Existuje elegantnější řešení?

Existuje, ale je trocha narocnejsie. FreeIPA server a prihlasovanie cez kerbera. Tam si nastavis ktory klient moze ku ktorej sluzbe na ktorom servri. Elegancia spociva v tom ze tym pokryjes nie len api pisane v php ale aj ostatne sluzby, ako mail server, db server a kopu dalsieho. Vyhodu to ma tu ze ticket ktory posles, moze server pouzit na autentifikaciu k dalsej sluzbe. Druha vyhoda je ta ze ak ti aj utocnik odchyti ticket tak bez keytab ktora sa neposiela, je mu ten ticket k nicomu.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 09:32:27
Pletete si JWT s OAuth 2 (kde se JWT také používá, to vás asi zmátlo). vesterna12 chce aplikaci rozdělit na mikroslužby. Vytvořit si závislost mikroslužeb na jednom centrálním serveru pro ukládání session není úplně to nejšťastnější řešení – někdy to samozřejmě dává smysl, ale měl by k tomu být dobrý důvod.

Nezmylil, definicia JWT sice popisuje len token ktory je zabezpeceny, ale co sa tyka jeho pouzitia tak su zauzivane praktiky ako ho bezpecne pouzit. A tiez ako ho nie bezpecne pouzit napr v angular aplikacii.

Co sa tyka php session, php nie je standalone aplikacia. Script sa spusti, nacita si session storage podla id ktore dostal, script si tam zapisuje, pri ukonceni scriptu sa session storage serualizuje, ulozi, flushne sa output buffer a skript konci. Pri dalsej poziadavke sa script spusti, nacita su session... a tak stale dokola.
Pri horizontalnom skalovani je zdielanie session jedina moznost ako udrzat aplikaciu funkcnu. A redis alebo memcache, je daleko spolahlivesie ako moutnute zdielane nfs, tam dochadza k oneskoreniam v synchronizacii...
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 09:43:19
Nezmylil, definicia JWT sice popisuje len token ktory je zabezpeceny, ale co sa tyka jeho pouzitia tak su zauzivane praktiky ako ho bezpecne pouzit. A tiez ako ho nie bezpecne pouzit napr v angular aplikacii.
To, co vy jste popsal, je OAuth 2. JWT se ale dají používat i mnoha jinými způsoby. Je to přesně to, k čemu směřoval  vesterna12 na začátku – kus dat, elektronicky podepsaný, který může poslat klient serveru nebo servery mezi sebou, a u kterého se lze po ověření podpisu spolehnot na to, že s nimi nikdo nemanipuloval.

Co sa tyka php session, php nie je standalone aplikacia. Script sa spusti, nacita si session storage podla id ktore dostal, script si tam zapisuje, pri ukonceni scriptu sa session storage serualizuje, ulozi, flushne sa output buffer a skript konci. Pri dalsej poziadavke sa script spusti, nacita su session... a tak stale dokola.
A teď si představte, že ten skript spouštíte na serverech po celém světě. Takže ta session nebude uložená nikde lokálně, ale musí být dostupná globálně. Jakmile server ztratí přístup k tomu globálnímu úložišti session, nemůže obsluhovat požadavky.

Pri horizontalnom skalovani je zdielanie session jedina moznost ako udrzat aplikaciu funkcnu.
To teda fakt není. Sdílená session nejde horizontálně škálovat, pořád je jenom jedna. Právě proto se každý, kdo potřebuje horizontálně škálovat, snaží session vyhnout.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 10:02:09
JWT sa daju sice puzit k vesetkemu moznemu, ale ak maju obsahovat autentizacne udaje, ktore si ukladate v cookie alebo v inom ulozisku prehliadaca, tak to si tam mozete ukladat rovno uzivatelske meno a heslo. To ci niekto manipuloval s autentizacnymi udajmi vam je na dve veci. Ak tie prihlasovacie udaje niekto zmeni, tak sa s nimi nebude dat prihlasit.

Vsimnite si aku ma domenu ten link toho tutorialu, nemyslim ze digitalocean ma jednu serverovnu...

Uvazujte aplikaciu v php, nie v jave. Kazda poziadavka spusta nanovo script ktory netusi kde je sever bez toho aby si nacital premenne zo session storage. Strkat vsetky premenne serializovane do cookie asi nechcete. Session napr z nette ma len v zaklade par kilo...
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 10:23:55
JWT sa daju sice puzit k vesetkemu moznemu, ale ak maju obsahovat autentizacne udaje, ktore si ukladate v cookie alebo v inom ulozisku prehliadaca, tak to si tam mozete ukladat rovno uzivatelske meno a heslo. To ci niekto manipuloval s autentizacnymi udajmi vam je na dve veci. Ak tie prihlasovacie udaje niekto zmeni, tak sa s nimi nebude dat prihlasit.
Mýlíte se. Kdybych z prohlížeče posílal pokaždé na server jméno a heslo, server musí tyhle údaje vzít a ověřit je proti úložišti uživatelů. Jakmile se mu s ním nepodaří spojit, nemůže pokračovat. Když ale klint místo toho pošle podepsaný lístek, o kterém server ví, že se vystavuje jenom přihlášeným uživatelům, s nikým dalším komunikovat nemusí. Podpis ověří server sám, a když podpis sedí, ví, že daný uživatel je autentizován. A může věřit údajům, které jsou na lístku uvedené – např. login uživatele, ale mohou tam být uložena třeba také oprávnění. Autentizační server v tu chvíli vůbec nemusí být dostupný, ale serverová aplikace ho vůbec nepotřebuje, bude fungovat i bez něj.

Vsimnite si aku ma domenu ten link toho tutorialu, nemyslim ze digitalocean ma jednu serverovnu...
To, že Digital Ocean nabízí nějaké služby, neznamená, že jsou všechny ty služby nejvhodnější řešení pro provoz mikroslužeb.

Kazda poziadavka spusta nanovo script ktory netusi kde je sever bez toho aby si nacital premenne zo session storage.
Kde je server si aplikace samozřejmě nebude číst ze session storage ale z konfigurace.

Strkat vsetky premenne serializovane do cookie asi nechcete. Session napr z nette ma len v zaklade par kilo...
Ještě jednou. Když chcete mít aplikaci dobře horizontálně škálovatelnou, nechcete tam mít vůbec žádnou session. Zdá se, že si aplikaci nepoužívající session vůbec nedovedete představit, ale vězte, že to jde. Používá to Google, Facebook, Twitter…
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 11:15:08
JWT sa daju sice puzit k vesetkemu moznemu, ale ak maju obsahovat autentizacne udaje, ktore si ukladate v cookie alebo v inom ulozisku prehliadaca, tak to si tam mozete ukladat rovno uzivatelske meno a heslo. To ci niekto manipuloval s autentizacnymi udajmi vam je na dve veci. Ak tie prihlasovacie udaje niekto zmeni, tak sa s nimi nebude dat prihlasit.
Mýlíte se. Kdybych z prohlížeče posílal pokaždé na server jméno a heslo, server musí tyhle údaje vzít a ověřit je proti úložišti uživatelů. Jakmile se mu s ním nepodaří spojit, nemůže pokračovat. Když ale klint místo toho pošle podepsaný lístek, o kterém server ví, že se vystavuje jenom přihlášeným uživatelům, s nikým dalším komunikovat nemusí. Podpis ověří server sám, a když podpis sedí, ví, že daný uživatel je autentizován. A může věřit údajům, které jsou na lístku uvedené – např. login uživatele, ale mohou tam být uložena třeba také oprávnění. Autentizační server v tu chvíli vůbec nemusí být dostupný, ale serverová aplikace ho vůbec nepotřebuje, bude fungovat i bez něj.
Ten token je nesifrovany, skor ci neskor ta aplikacia bude mat potrebu si siahnut k ulozisku uzivatelov, teda ak nechcete tym tokenom prenasat vsetky udaje o uzivatelovy. Uz len pre to aby dokazala zobrazit pod akym uctom je uzivatel aktualne prihlaseny. Tak isto bude musiet siahat pre dalsie udaje. Teda ak ma robit nieco viac ako ako vypisat "Ahoj uzivatel, vas token obsahuje hodnoty XXXX".
Podstata je v tom ze rovnako ako sa moze utocnik dostat k session id alebo k ulozenemu heslu, tak sa moze dostat aj k tokenu. Session mozete zmazat, heslo zmenit ale pri sposobe overovania ako popisujete mozete akurat tak cakat az ten token strati platnost. A po tu dobu pre istotu zhodit server, nech sa ten preflaknuty token neda zneuzit.
Vsimnite si aku ma domenu ten link toho tutorialu, nemyslim ze digitalocean ma jednu serverovnu...
To, že Digital Ocean nabízí nějaké služby, neznamená, že jsou všechny ty služby nejvhodnější řešení pro provoz mikroslužeb.
A k comu inemu by ste chcel pouzit synchronizaciu uloziska session medzi servermi php. Ono si php session uklada v povodnom nastaveni na disk, ja mam vyskusane ze redis je v tomto pripade daleko efektivnejsi, ako zdielanie adresara kam si php uklada sesion cez nfs.
Kazda poziadavka spusta nanovo script ktory netusi kde je sever bez toho aby si nacital premenne zo session storage.
Kde je server si aplikace samozřejmě nebude číst ze session storage ale z konfigurace.
Tak budeme mat beznu konfiguraciu, a konfiguraciu per uzivatel do ktorej si php scrip pred dobehnutim zapise data potrebne v ramci sedenia pre dalsi dotaz. Mmnt, to uz tam implementovane je, vola sa to session. Funguje to uplne inak ako v jave, flasku, alebo v AWS(ada web server) ked tak tu https://www.php.net/manual/en/book.session.php
Strkat vsetky premenne serializovane do cookie asi nechcete. Session napr z nette ma len v zaklade par kilo...
Ještě jednou. Když chcete mít aplikaci dobře horizontálně škálovatelnou, nechcete tam mít vůbec žádnou session. Zdá se, že si aplikaci nepoužívající session vůbec nedovedete představit, ale vězte, že to jde. Používá to Google, Facebook, Twitter…
Jop, staci im k tomu JWT token. :D Ale vazne, to ako pisat php script bez pouzitia session mozete vysvetlovat tvorcom drupalu, wordpressu, nette a mnohym dalsim co kedy nieco v php napisali. Obavam za ze si z vas budu tak trochu utahovat...
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: cjohn 01. 08. 2021, 11:53:36
mam vyskusane ze redis je v tomto pripade daleko efektivnejsi

Vyzera to, ze vas niekto posluchol nedavno a dal to do toho efektivnejsieho Redisu a zial dosiahol 65k limit :-( https://www.pcgamer.com/the-splitgate-crossplay-beta-is-so-popular-the-developers-had-to-take-it-offline/

Ja by som volil JWT (cez Open ID Connect). Mimochodom aj JWT implementacia umoznuje revokaciu (keyword backchannel sesion revocation/logout).
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 12:03:57
Ten token je nesifrovany
Za prvé to není pravda, má i šifrovanou část. Za druhé jaké údaje byste tam chtěl šifrovat?

skor ci neskor ta aplikacia bude mat potrebu si siahnut k ulozisku uzivatelov, teda ak nechcete tym tokenom prenasat vsetky udaje o uzivatelovy.
Jaké všechny údaje?

Uz len pre to aby dokazala zobrazit pod akym uctom je uzivatel aktualne prihlaseny.
Zobrazí buď login, nebo přímo jméno uživatele. Login bude v tokenu uložen určitě, jméno uživatele tam může být také. Ale když to chcete jenom zobrazovat uživateli, není potřeba to přenášet na server a zpět – stačí to mít uložené v klientské části aplikace.

Tak isto bude musiet siahat pre dalsie udaje.
Které?

Podstata je v tom ze rovnako ako sa moze utocnik dostat k session id alebo k ulozenemu heslu, tak sa moze dostat aj k tokenu.
No a?

Session mozete zmazat, heslo zmenit ale pri sposobe overovania ako popisujete mozete akurat tak cakat az ten token strati platnost.
Opět – čemu to vadí? Token ztratí platnost třeba za 5 minut. Pokud jo chcete umožnit ještě rychlejší odhlášení, můžete mít v mikroslužbách seznam zneplatněných tokenů a když se uživatel odhlásí, všem aplikacím ID toho zneplatněného tokenu rozeslat.

A k comu inemu by ste chcel pouzit synchronizaciu uloziska session medzi servermi php.
Když mám klasickou starou monolitickou aplikaci.

Tak budeme mat beznu konfiguraciu, a konfiguraciu per uzivatel do ktorej si php scrip pred dobehnutim zapise data potrebne v ramci sedenia pre dalsi dotaz. Mmnt, to uz tam implementovane je, vola sa to session. Funguje to uplne inak ako v jave, flasku, alebo v AWS(ada web server)
Vidím, že se v tom neorientujete, pokusím se vám to vysvětlit. Existuje nějaká globální konfigurace aplikace, v ní budou uložené např. adresy serverů (jiných služeb), o kterých jste psal. Vedle toho existuje něco, čemu se říká session – data uložená na serveru, která jsou spojená s přihlášením konkrétního uživatele. Klient posílá s každým požadavkem identifikátor session (obvykle v sookie, ale může být i součástí URL). Server si na zákaldě ientifikátoru dohledá údaje ze session v nějakém úložišti – může to být paměť, disk, SQL databáze, NoSQL databáze… Funguje to úplně stejně v PHP, v Javě, Flasku.


Jop, staci im k tomu JWT token. :D
Ano, stačí. Nevím, co je na tom směšného – tohle je mikroservisová architektura.

Ale vazne, to ako pisat php script bez pouzitia session mozete vysvetlovat tvorcom drupalu, wordpressu, nette a mnohym dalsim co kedy nieco v php napisali. Obavam za ze si z vas budu tak trochu utahovat...
To jsou ovšem monolity. Mezi tím byla ovšem vynalezena architektura microservice, která se pro mnohé služby hodí lépe. Její největší výhodou je to, že je horizontálně vlemi dobře škálovatelná. Proto ji právě používají Google, Facebook, Twitter, Netflix a další. vesterna12 se ptal právě na architekturu mikroslužeb, ostatně je to i v názvu tématu. Takže vaše návrhy, jak byste to dělal „po staru“ jako monolit jsou sice hezké, ale neodpovídají na tazatelův dotaz. („Po staru“ není myšleno nijak pejorativně, monolitická architektura má stále své opodstatnění – mikroservisy nejsou žádný zázračný lék, mají svá negativa a mají zpočátku větší režii, než monolit.)
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 14:10:03
Na toto trolenie fakt dnes nemam cas ani naladu. Mohol by ste apom tie citaty nevytrhavat z kontextu, nechdavaju povodny zmysel a da sa na ne odpovedat v kontexte. Vlastne vy musite, inak by ste neposuval branky tak ako to robite.

Myslim ze vesterna12 si vyberie to co mu bude vyhovovat. Nezavisle na tom ze ako vzdy vytrolite tych co nemaju rovnaky nazor ako vy.

Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 15:08:10
Dobře, odpovím vám v kontextu. Vaše představa, že každá webová aplikace musí mít session, je mylná. Aplikace, které mají být dobře horizontálně škálovatelné, se naopak snaží sdílenému stavu maximálně vyhýbat. Stejně tak je mylná vaše představa o JWT. JWT může mít (a obvykle má) podepsanou část, může mít i šifrovanou část (která se ale moc nepoužívá, obvykle není potřeba). Do JWT je možné uložit libovolná data, omezen jste jen velikostí hlavičky, ve které se JWT přenáší. Nicméně v praxi u aplikace založené na mikroslužbách těch údajů, které potřebujete přes JWT přenášet, obvykle není mnoho, často stačí jen login a expirace tokenu.

Výsledek mého komentáře je úplně stejný. Problém totiž nebyl v tom, že bych něco vytrhával v kontextu, ale že vy píšete nesmysly.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 01. 08. 2021, 15:16:32
Cílem je opustit kompletně php_session().
Chci co nejsnadnější škálování.
Možná Docker/Kubernetes, ale to mi přijde jako zbytečná další abstrakce (a spotřeba HW + další údržba). Automatizací posílám "Git release" na příslušné stroje. Stroje mám škálované pomocí skriptů. Do 10 minut je server vzhůru.
Replikace relací je další zbytečná komplikace.
Je vyloučeno, aby klient při každém dotazu posílal znovu jméno a heslo uložené v nějakém objektu.
Nechci ani cache autentizace a autorizace na koncových bodech api.
Co nejméně volání do DB,AD,Kafky,AMQ, nebo Redisu.
Žádné sdílené disky mezi servery. Výjimku mají pouze CDN segmenty.
Funkci si chystám tak aby byla schopná dotazování AD, protože jeden zdroj pravdy už mám. Jako druhý autentizační poskytovatel bude MYSQL databáze a poslední CURL volání do extérního systému.
Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče. Pokud se klient pokusí data podvrhnout je vyloučeno data podepsat důvěryhodným klíčem (uložen na HSM), který má pouze autentizační server.
Autorita je chráněná. Jen tak si někdo certifikát nepodepíše...

Programuju příležitostně a nevěděl jsem jestli není moje teorie zastaralá.
Děkuji panu Jiráskovi za jeho trpělivost a vysvětlení.

Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: hurvajs spejbl 01. 08. 2021, 15:17:53
@Death Walker: jediný kdo tu plácá hlouposti, jste vy. Pokud neumíte používat JWT, je to Váš problém. JWT si nikdy nehrálo na to, že nejde přečíst (ve standardní verzi) jde normálně dekódovat do čitelné podoby. Jak píše p. Jirsák, uložit si tam můžete co chcete. Samozřejmě validace tokenu je také na Vás, jak se poperete s invalidací vypršeného či revokovaného tokenu.

Ale na to, že obyvatelé tater, jsou ..., jsme my v ČR zvyklí :-)
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 15:32:30
Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče.
Jenom pro přesnost, tohle je podepisování, ne šifrování. Šifrování by fungovalo opačně – to, co má být tajné se zašifruje veřejným klíčem, takže to následně může dešifrovat jen majitel privátního klíče. To, co vy potřebujete, je podepisování – takže postup jste popsal správně, jen se to jmenuje jinak. (Ano, na úrovni algoritmů je podepisování a šifrování to samé –  když po sobě provedete transformaci nejprve jedním a pak druhým klíčem z páru, dostanete zpět původní vstup.)
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 16:00:52
@Death Walker: jediný kdo tu plácá hlouposti, jste vy. Pokud neumíte používat JWT, je to Váš problém. JWT si nikdy nehrálo na to, že nejde přečíst (ve standardní verzi) jde normálně dekódovat do čitelné podoby. Jak píše p. Jirsák, uložit si tam můžete co chcete. Samozřejmě validace tokenu je také na Vás, jak se poperete s invalidací vypršeného či revokovaného tokenu.

Ale na to, že obyvatelé tater, jsou ..., jsme my v ČR zvyklí :-)

Vazne? Kde som pisal ze nejde precitat, link?
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 16:06:39


Tu mate popis ako sa prihlasuje do Gmailu cez Google account.
https://blog.theodo.com/2019/07/single-sign-on/
To je presne ten pripad ako sa ma JWT pouzivat. Ten token obdrzi len Gmail od GA. Klientovi vobec nedorazi pretoze si ho ukladat koli bezpecnosti nemusi.

Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 16:46:31
Tu mate popis ako sa prihlasuje do Gmailu cez Google account.
https://blog.theodo.com/2019/07/single-sign-on/
To je presne ten pripad ako sa ma JWT pouzivat. Ten token obdrzi len Gmail od GA. Klientovi vobec nedorazi pretoze si ho ukladat koli bezpecnosti nemusi.
Na tom odkazu není popsáno konkrétně přihlášení ke Google účtu, je tam obecný popis přihlášení tak, jak je definován např. v OAuth 2 (přičemž Google opravdu používá tento standard). A v tom popisu ten token ke klientovi vždy dorazí. Všimněte si, že je tam vždy přesměrování prohlížeče na adresu poskytovatele služeb s tokenem připojeným v URL. V tomto okamžiku tedy prohlížeč vidí přihlašovací token, a je jenom na provozovateli té služby (v textu www.service-provider-1.com a totéž s 2), jestli si ten token uloží v prohlížeči nebo ne. No a pokud provozovatel služby chce provozovat mikroslužby a chce se tudíž vyhnout sdílené session, je logické zapamatovat si ten token v klientské aplikaci a autorizovat jím každý zaslaný požadavek.

Monolitická aplikace která tak jako tak bude používat session samozřejmě ten token u uživatele ukládat nemusí, protože ho nebude používat – server si na základě tokenu vytvoří pro uživatele session a uživatel je nadále identifikován tou session.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 01. 08. 2021, 17:03:14


Ku klientovi sice dorazi, hned na to ale prebehne redirect na ziadanu stranku, pricom sa ten token neulozi  pretoze by bolo mozne ho zneuzit. OAuth2 funguje inak tam este server poziada cez api o token ktori si ulozi.

Vy mate ten dojem ze rozlisovacim znakom pre monolit je pritomnost session? Nie je to nahodou bezstavovost aplikacie? Session do aplikacie stavovost nezanasa. Maximalne si nejaka lopata moze do tej session zacat ukladat stavove premenne, ale to sa da odchytit pri code rewiev.

Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 01. 08. 2021, 17:27:29
Ku klientovi sice dorazi, hned na to ale prebehne redirect na ziadanu stranku, pricom sa ten token neulozi  pretoze by bolo mozne ho zneuzit. OAuth2 funguje inak tam este server poziada cez api o token ktori si ulozi.

Vy mate ten dojem ze rozlisovacim znakom pre monolit je pritomnost session? Nie je to nahodou bezstavovost aplikacie? Session do aplikacie stavovost nezanasa. Maximalne si nejaka lopata moze do tej session zacat ukladat stavove premenne, ale to sa da odchytit pri code rewiev.
Token dorazí ke klientovi, takže uživatel ho může získat a může si ho uložit. Což ale vůbec ničemu nevadí, protože jej nemůže vůbec nijak zneužít – je to jen potvrzení, že se přihlásil opravdu on. Je to asi jako kdyby se někdo pokoušel zneužít svou vlastní občanku.

Nic o rozlišovacích znacích monolitu jsem nepsal. Pouze jsem reagoval na vaše komentáře o monolitické aplikaci používající session. Session samozřejmě stavovost do aplikace zanáší. HTTP protokol jako takový je bezestavový, proto bylo vynalezeno to, že si server uloží stav pod nějakým identifikátorem a ten identifikátor se pak posílá klient s každým požadavkem. Tím se nad bezestavovým protokolem dá vytvořit stavovost. Takže HTTP session se používá právě proto, abyste do aplikace používající nestavové HTTP dostal stavovost. Ve stavu si pak můžete uložit třeba o jakého se jedná uživatele nebo jaké zboží má právě v košíku. Když si server nepamatuje stav, tyhle informace si musí pamatovat klient a předat je serveru pokaždé, když jsou potřeba.

No a tomu principu se začalo říkat session, protože to udržuje stav, ale ne trvale, pouze po dobu práce uživatele s tou aplikací. Což je v angličtině právě „session“, v češtině by tomu bylo asi nejblíž „sezení“ nebo „seance“.

Co je HTTP session (https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session) se dočtete třeba na Wikipedii, kdybyste mi to nevěřil.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: FactChecker 02. 08. 2021, 08:56:55
Nepoužívejte JWT s local storage. Použijte cookie s Secure, HttpOnly, SameSite=Strict. Cookie musíte chránit před CSRF/XSRF, což je triviální. Přístup k local storage získáte přes XSS, před kterým je dobrá ochrana složitá, nadarmo není v OWASP Top Ten.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Jvic V. 02. 08. 2021, 09:14:48
Citace
Chtěl bych aplikaci rozložit do několika mikroslužeb kvůli škálování

Pokud uvažujete o microservisní architektuře, je třeba nekoukat jen na výhody, ale přečíst si i nevýhody... Z osobní zkušenosti bych tutu architekturu doporučil pouze v případě, že

A) Máte velmi velký SW
B) Máte několik týmů o několika vývojářích

Ve většině případu platí A, ale už nikdo nemá/nezaplatí B... V pár lidech microservisní architektura přináší víc nevýhod než výhod.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 02. 08. 2021, 10:30:44
Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče.
Jenom pro přesnost, tohle je podepisování, ne šifrování. Šifrování by fungovalo opačně – to, co má být tajné se zašifruje veřejným klíčem, takže to následně může dešifrovat jen majitel privátního klíče. To, co vy potřebujete, je podepisování – takže postup jste popsal správně, jen se to jmenuje jinak. (Ano, na úrovni algoritmů je podepisování a šifrování to samé –  když po sobě provedete transformaci nejprve jedním a pak druhým klíčem z páru, dostanete zpět původní vstup.)
Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php
V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 10:31:23
Nepoužívejte JWT s local storage. Použijte cookie s Secure, HttpOnly, SameSite=Strict. Cookie musíte chránit před CSRF/XSRF, což je triviální. Přístup k local storage získáte přes XSS, před kterým je dobrá ochrana složitá, nadarmo není v OWASP Top Ten.
Před XSS je potřeba web chránit tak jako tak. Pokud si útočník na vašem webu může spouštět libovolné skripty, nepomůže nic, ani HttpOnly cookie – útočník prostě útočný kód spustí rovnou z aplikace a nepotřebuje cookie znát, přiloží ji za něj rovnou prohlížeč. A ochrana před XSS zas tak složitá není – v první řadě je potřeba vyhnout se používání nebezpečných postupů (které obvykle nejsou k ničemu potřeba), v druhé řadě se dá přidat ochrana na úrovni prohlížeče (která je starší, tudíž více podporovaná, než SameSite cookies). Ochrana před CSRF/XSRF je právě ta SameSite cookie, starší ochrany nejsou „ochrany“ ale rozbíjení aplikace.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 02. 08. 2021, 10:38:53
Citace
Chtěl bych aplikaci rozložit do několika mikroslužeb kvůli škálování

Pokud uvažujete o microservisní architektuře, je třeba nekoukat jen na výhody, ale přečíst si i nevýhody... Z osobní zkušenosti bych tutu architekturu doporučil pouze v případě, že

A) Máte velmi velký SW
B) Máte několik týmů o několika vývojářích

Ve většině případu platí A, ale už nikdo nemá/nezaplatí B... V pár lidech microservisní architektura přináší víc nevýhod než výhod.
  • Transakce, Rollback
  • Error handling
  • Autorizace/authentikace

- používám relační databázi
- i v případě monolitu
- to už tu teď řeším...

Aplikace není zase tak velká. Jde o jeden malý e-shop, ale je to skvělá příležitost a taky je tu potenciál růstu.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 10:49:56
Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php
V tom případě budou opačně ty klíče – autorizační server bude šifrovat veřejným klíčem, služby dešifrovat privátním. Správně by každá služba měla mít svůj privátní klíč. Ale počítejte s tím, že šifrovaná data nezaručují autenticitu. Tedy stejně bude potřeba je podepisovat.


V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".
To mi připadá trošku překombinované. Když se neověří podpis, stejně nemůžete těm údajům věřit. A na to, že je nemohl zašifrovat nikdo jiný, se spoléhat nedá – šifruje se veřejným certifikátem, tj. musíte počítat s tím, že data může zašifrovat kdokoli. Bez ohledu na to, zda si budete hlídat, aby se veřejný certifikát nedostal „ven“.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 02. 08. 2021, 11:10:38
Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php
V tom případě budou opačně ty klíče – autorizační server bude šifrovat veřejným klíčem, služby dešifrovat privátním. Správně by každá služba měla mít svůj privátní klíč. Ale počítejte s tím, že šifrovaná data nezaručují autenticitu. Tedy stejně bude potřeba je podepisovat.


V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".
To mi připadá trošku překombinované. Když se neověří podpis, stejně nemůžete těm údajům věřit. A na to, že je nemohl zašifrovat nikdo jiný, se spoléhat nedá – šifruje se veřejným certifikátem, tj. musíte počítat s tím, že data může zašifrovat kdokoli. Bez ohledu na to, zda si budete hlídat, aby se veřejný certifikát nedostal „ven“.

Šifrovat řetězec můžu privátním klíčem a možné je ho dešifrovat pouze pomocí relevantního certifikátu generovaného z privátního klíče. Je to tak? Psal jsem klíče, ale myslel jsem klíč a certifikát. Pokud to tak je tak když se mi nepovede dešifrování certifikátem tak můžu považovat zdroj za nedůvěryhodný, protože byl šifrován očividně někým jiným.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 12:26:53
Šifrovat řetězec můžu privátním klíčem a možné je ho dešifrovat pouze pomocí relevantního certifikátu generovaného z privátního klíče. Je to tak? Psal jsem klíče, ale myslel jsem klíč a certifikát. Pokud to tak je tak když se mi nepovede dešifrování certifikátem tak můžu považovat zdroj za nedůvěryhodný, protože byl šifrován očividně někým jiným.
Když data transformujete privátním klíčem, fakticky vzato to není šifrování, protože ta data po transformaci nebudou utajená – může je zpět do čitelné podoby transformovat kdokoli, kdo má veřejný klíč. A u veřejného klíče se předpokládá, že je veřejný, tedy že ho může mít kdokoli. (Veřejný klíč je součástí certifikátu.)

Hlavně se vám ale nepodaří žádnou běžně používanou kryptografickou knihovnu přesvědčit k tomu, aby celá vstupní data transformovala (vy píšete „šifrovala“) pomocí privátního klíče. Knihovny umí pomocí privátního klíče buď podepisovat nebo dešifrovat. Pokud byste zkusil pomocí privátního klíče „šifrovat“, nepůjde to. On je totiž rozdíl mezi matematickými algoritmy a praktickou implementací. V matematických algoritmech sice můžete navzájem prohodit obě transformace, takže můžete nejprve vstupní text dešifrovat a výstup dešifrování pak zašifrovat. V algoritmech implementovaných v knihovnách to tak ale nejde, protože tam je toho víc, než jen tranformace veřejným/privátním klíčem dle nějakého alloritmu asymterické kryptografie.

Operace podepisování a šifrování tedy v praxi nejsou k sobě inverzní. Šifruje se tak, že se vygeneruje náhodný klíč, ten se použije v symetrické šifře pro zašifrování dat a asymetrické šifrování se použije jen pro zašifrování toho vygenerovaného klíče. Naopak při podepisování dokumentu se spočítá jeho hash a teprve ten se pak „dešifruje“ privátním klíčem.

Nepokoušejte se kryptografická schémata ohýbat za účelem zvýšení bezpečnosti, takřka určitě byste tím vyrobil akorát bezpečnostní díru. Prostě musíte počítat s tím, že mikroslužba podpis správně ověří. Stejně jako počítáte s tím, že se dívá na oprávnění uživatele (na to také může programátor zapomenout) nebo že bere v úvahu přihlášeného uživatele a nedělá vše pod nějakým administrátorským účtem. Navíc tohle můžete snadno testovat automatizovanými testy – vystavíte službě neplatný JWT, a pokud služba neskončí chybou ale bude něco dál dělat, je evidentně ověření implementováno chybně.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: vesterna12 02. 08. 2021, 13:40:28
Všechny komponenty dostanou certifikát generovaný z klíče. Nevadí, že si někdo stáhne certifikát a řetězec dešifruje, protože neobsahuje nic citlivého.
Pro demonstraci:

Kód: [Vybrat]
<?php

// Encryption

   
$data 'encryption test';
   
openssl_private_encrypt ($data$crypted file_get_contents('key.pem'),OPENSSL_PKCS1_PADDING);


// Decryption

   
openssl_public_decrypt($crypted $output file_get_contents('cert.pem2'),OPENSSL_PKCS1_PADDING );


echo 
$output;


?>



Pokud se komponentně nepovede dešifrování je zdroj podepsaný někým jiným. Konec 403...

Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: FactChecker 02. 08. 2021, 13:55:30
Nepoužívejte JWT s local storage. Použijte cookie s Secure, HttpOnly, SameSite=Strict. Cookie musíte chránit před CSRF/XSRF, což je triviální. Přístup k local storage získáte přes XSS, před kterým je dobrá ochrana složitá, nadarmo není v OWASP Top Ten.
Před XSS je potřeba web chránit tak jako tak. Pokud si útočník na vašem webu může spouštět libovolné skripty, nepomůže nic, ani HttpOnly cookie – útočník prostě útočný kód spustí rovnou z aplikace a nepotřebuje cookie znát, přiloží ji za něj rovnou prohlížeč. A ochrana před XSS zas tak složitá není – v první řadě je potřeba vyhnout se používání nebezpečných postupů (které obvykle nejsou k ničemu potřeba), v druhé řadě se dá přidat ochrana na úrovni prohlížeče (která je starší, tudíž více podporovaná, než SameSite cookies). Ochrana před CSRF/XSRF je právě ta SameSite cookie, starší ochrany nejsou „ochrany“ ale rozbíjení aplikace.

Vtip u XSS je, že stačí libovolný skript načítaný z jakéhokoliv externího zdroje. Takže pokud na stránce používáte JS knihovny z CDN nebo vkládáte např. mapy, reklamy či jiné, tak těm zdrojům musíte věřit a nejen teď, ale i v budoucnu.

Cookie prohlížeč pošle se SameSite jen serveru, který ji nastavil. Pomocí XSS ji prostě nedostanete.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 14:27:43
Všechny komponenty dostanou certifikát generovaný z klíče. Nevadí, že si někdo stáhne certifikát a řetězec dešifruje, protože neobsahuje nic citlivého.
Pro demonstraci:

Kód: [Vybrat]
<?php

// Encryption

   
$data 'encryption test';
   
openssl_private_encrypt ($data$crypted file_get_contents('key.pem'),OPENSSL_PKCS1_PADDING);


// Decryption

   
openssl_public_decrypt($crypted $output file_get_contents('cert.pem2'),OPENSSL_PKCS1_PADDING );


echo 
$output;


?>



Pokud se komponentně nepovede dešifrování je zdroj podepsaný někým jiným. Konec 403...

Počítejte s tím, že asymetrické šifry jsou pomalé, neměl byste tam mít o moc víc dat, než jsou běžné hashe, abyste tím nezpomalil každý požadavek. Jinak to, co děláte, je stále podpis, akorát se nepodepisuje hash, ale celá původní zpráva.

Já bych se tohohle bál, není to takové použití, jaké bylo původně zamýšleno. Může tam být nějaká chyba nebo slabina, kterou nevidím. Nesnažil bych se takhle ošetřit případ, že někdo zapomene ověřit podpis – těch opomenutí může být daleko víc, která takhle stejně nepodchytíte.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 15:49:50
Vtip u XSS je, že stačí libovolný skript načítaný z jakéhokoliv externího zdroje. Takže pokud na stránce používáte JS knihovny z CDN nebo vkládáte např. mapy, reklamy či jiné, tak těm zdrojům musíte věřit a nejen teď, ale i v budoucnu.
Což ovšem platí neustále. Důvěřuji těm skriptům, které mám v CSP.

Cookie prohlížeč pošle se SameSite jen serveru, který ji nastavil. Pomocí XSS ji prostě nedostanete.
Ale já ji nepotřebuji dostat. Mně úplně stačí, že ji pošle s požadavkem automaticky prohlížeč.

Rozdíl mezi cookie a sessionStorage je akorát v tom, že v případě cookie musí útočník provádět neplechu rovnou v rámci XSS, zatímco při použití sessionStorage má možnost poslat si token jinam a neplechu může provádět ze svého počítače. A to ještě předpokládáme, že na serveru není žádná zranitelost, která by umožnila skript získat i odnotu HttpOnly cookie (což je věc, kterou lze velmi těžko zaručit). Za mne je tohle strašně úzký vektor útoku, který nemá smysl samostatně řešit. Prostě pokud někdo může udělat na mé aplikaci XSS, je to samo o sobě obrovský průšvih – a nemá smysl se pak spoléhat na to, že nebude útočit rovnou, ale pouze by se snažil ukrást přihlašovací token. Zejména když ta obrana použitím cookies je závislá na tom, že mi server cookie nepošle zpátky v nějaké odpovědi a také na implementaci SameSite cookie. Za podstatně větší riziko považuju CSRF s prohlížečem bez SameSite než to, že útočník bude schopen XSS útoku ale nedokáže přímo spustit škodlivý kód a bude odkázán jen na ukradení autentizačního tokenu.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: FactChecker 02. 08. 2021, 16:33:13
Tolik zbytečných vět. Local storage neposkytuje žádné bezpečnostní funkce narozdíl od cookies.

Chápu, že nějaký FactChecker nemá potřebnou váhu. Zde je tedy citace z https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html:

Citace
Therefore, it's recommended to avoid storing any sensitive information in local storage where authentication would be assumed.

Do not store session identifiers in local storage as the data is always accessible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.

Ukažte mi podobné prohlášení od nějaké renomované bezpečnostní společnosti, která bude tvrdit opak.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 17:26:48
Tolik zbytečných vět. Local storage neposkytuje žádné bezpečnostní funkce narozdíl od cookies.
Za bezpečnostní funkci považujete to, že prohlížeč přibalí cookie ke každému požadavku, kam to jde?


Do not store session identifiers in local storage as the data is always accessible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.
To ovšem vychází ze dvou mylných předpokladů. První je, že to, co je přístupné JavaScriptu, je automaticky méně bezpečné, než to, co JavaScriptu přístupné není. Za druhé, že když je cookie nedostupná JavaScriptu přímo v prohlížeči, není dostupná žádným jiým způsobem – zejména že se nikdy nemůže stát, že server nevloží cookie do těla odpovědi.

Ta OWASP doporučení jsou bohužel taková nestrukturovaná směska lidové moudrosti, která nebere v potaz vývoj.

Já jsem svoje důvody, proč je podle mne bezpečnější sessionStorage než cookies, napsal. XSS je pro mne nepřípustné, odmítám za bezpečnou považovat aplikaci, u které se připouští možnost napadení XSS. Takže když se bavíme o tomto neprosto nejpravděpodonbějším případu, kdy útočník nemá možnost spustit v doméně aplikace svůj JavaScriptový kód, uložení tokenu do sessionStorage s sebou nenese žádné riziko útoku, použití cookies s sebou nese riziko útoku CSRF. CSRF útoku se lze spolehlivě bránit jen použitím SameSite cookie, což je ale méně podporovaná technologie, než CSP, která brání XSS.

No a když už připustím XSS, pak není prakticky žádný rozdíl mezi použitím sessionStorage nebo cookies.

Takže za mne je postup následující:

Nehledě na to, že same-site politiky (obecně, ne jen cookies) jsou z principu děravé, takže spoléhat se na SameSite cookie jako na 100% ochranu je také dost naivní.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: tomas88 02. 08. 2021, 18:31:18
Ja bych tam dal nejakou krabicku v podobe Identity and Access Management nastroje & API gateway. Nejakou krabicku nad OpenID Connect a ono vas to pak nasmeruje jak to postavit. Napr. tu je pekny seznam https://geekflare.com/api-gateway/

Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 02. 08. 2021, 20:25:16
Všechny komponenty dostanou certifikát generovaný z klíče. Nevadí, že si někdo stáhne certifikát a řetězec dešifruje, protože neobsahuje nic citlivého.

Toto je ale uz implementovane v TLS vrstve, ktoru pouziva jak server tak prakticky kazdy klient v php. Okrem podpisaneho serveroveho cert mate podpisany klientsky cert. Serveru poviete aby prijimal len poziadavky od klienta ktory ma cert podpisany konkretnou autoritou. PHP vidi vlastnosti toho klientskeho certifikatu (vacsinou to treba zapnut v konfiguracii webservra). Ostatne udaje budete mat normalne v tele tej poziadavky napr. ako json.

Btw. asymetricke kryptovanie funguje opacne ako popisujete. Spravu moze zasifrovat ktory kolvek odosielatel na zaklade verejneho kluca, desifrovat ju moze len prijemca na zaklade jeho privatneho kluca. Podpis pre overenie totoznosti generuje vlastnik privatneho kluca a ktokolvek ho moze overit pomocou verejneho kluca. 
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 02. 08. 2021, 20:27:16
Tolik zbytečných vět.

Jj, gish gallop je jeho oblubeny argumentacny klam, nie len tu :D
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 02. 08. 2021, 20:34:42
Ku klientovi sice dorazi, hned na to ale prebehne redirect na ziadanu stranku, pricom sa ten token neulozi  pretoze by bolo mozne ho zneuzit. OAuth2 funguje inak tam este server poziada cez api o token ktori si ulozi.

Vy mate ten dojem ze rozlisovacim znakom pre monolit je pritomnost session? Nie je to nahodou bezstavovost aplikacie? Session do aplikacie stavovost nezanasa. Maximalne si nejaka lopata moze do tej session zacat ukladat stavove premenne, ale to sa da odchytit pri code rewiev.
Token dorazí ke klientovi, takže uživatel ho může získat a může si ho uložit. Což ale vůbec ničemu nevadí, protože jej nemůže vůbec nijak zneužít – je to jen potvrzení, že se přihlásil opravdu on. Je to asi jako kdyby se někdo pokoušel zneužít svou vlastní občanku.

Nic o rozlišovacích znacích monolitu jsem nepsal. Pouze jsem reagoval na vaše komentáře o monolitické aplikaci používající session. Session samozřejmě stavovost do aplikace zanáší. HTTP protokol jako takový je bezestavový, proto bylo vynalezeno to, že si server uloží stav pod nějakým identifikátorem a ten identifikátor se pak posílá klient s každým požadavkem. Tím se nad bezestavovým protokolem dá vytvořit stavovost. Takže HTTP session se používá právě proto, abyste do aplikace používající nestavové HTTP dostal stavovost. Ve stavu si pak můžete uložit třeba o jakého se jedná uživatele nebo jaké zboží má právě v košíku. Když si server nepamatuje stav, tyhle informace si musí pamatovat klient a předat je serveru pokaždé, když jsou potřeba.

No a tomu principu se začalo říkat session, protože to udržuje stav, ale ne trvale, pouze po dobu práce uživatele s tou aplikací. Což je v angličtině právě „session“, v češtině by tomu bylo asi nejblíž „sezení“ nebo „seance“.

Co je HTTP session (https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session) se dočtete třeba na Wikipedii, kdybyste mi to nevěřil.

"komentáře o monolitické aplikaci používající session" - mozete to odcitovat presne kde som o niecom takomto hovoril. Ci zese len zavadzate.

Vy evidentne nepoznate rozdiel medzi bezstavovym protokolom (o ktorom pisete vy) a bezstavovou aplikaciou o ktorej som pisal ja.

Btw. to myslite vazne "Ta OWASP doporučení jsou bohužel taková nestrukturovaná směska lidové moudrosti, která nebere v potaz vývoj."? Dufam ze netvorite nic kde na bezpecnosti naozaj zalezi...
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 20:36:40
Toto je ale uz implementovane v TLS vrstve, ktoru pouziva jak server tak prakticky kazdy klient v php. Okrem podpisaneho serveroveho cert mate podpisany klientsky cert. Serveru poviete aby prijimal len poziadavky od klienta ktory ma cert podpisany konkretnou autoritou. PHP vidi vlastnosti toho klientskeho certifikatu (vacsinou to treba zapnut v konfiguracii webservra). Ostatne udaje budete mat normalne v tele tej poziadavky napr. ako json.
Akorát tenhle způsob autentizace rozhodně nechcete používat na veřejném internetu, a dneska ani v intranetech. Je to uživatelsky velmi nepřívětivé.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 02. 08. 2021, 21:15:42
Toto je ale uz implementovane v TLS vrstve, ktoru pouziva jak server tak prakticky kazdy klient v php. Okrem podpisaneho serveroveho cert mate podpisany klientsky cert. Serveru poviete aby prijimal len poziadavky od klienta ktory ma cert podpisany konkretnou autoritou. PHP vidi vlastnosti toho klientskeho certifikatu (vacsinou to treba zapnut v konfiguracii webservra). Ostatne udaje budete mat normalne v tele tej poziadavky napr. ako json.
Akorát tenhle způsob autentizace rozhodně nechcete používat na veřejném internetu, a dneska ani v intranetech. Je to uživatelsky velmi nepřívětivé.

Vzhladom k tomu ze nieco podobne sa vesterna12 snazi implementovat v PHP(usudzujem podla toho kodu co posielal), je diskutabilna uzivatelska neprivetivost irelevantna.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 02. 08. 2021, 21:28:05
Vzhladom k tomu ze nieco podobne sa vesterna12 snazi implementovat v PHP(usudzujem podla toho kodu co posielal), je diskutabilna uzivatelska neprivetivost irelevantna.
vesterna12 chce implementovat autentizaci uživatele (z webového prohlížeče) vůči mikroslužbám napsaným v PHP. Ten kód v PHP je autentizační server (vydává po přihlášení uživatele token, který se uloží v prohlížeči) a PHP mikroslužba (která dostane token od uživatelova prohlížeče). Takže klient, který se musí mikroslužbě nějak prokázat, je webový prohlížeč.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Death Walker 02. 08. 2021, 22:29:18
Vzhladom k tomu ze nieco podobne sa vesterna12 snazi implementovat v PHP(usudzujem podla toho kodu co posielal), je diskutabilna uzivatelska neprivetivost irelevantna.
vesterna12 chce implementovat autentizaci uživatele (z webového prohlížeče) vůči mikroslužbám napsaným v PHP. Ten kód v PHP je autentizační server (vydává po přihlášení uživatele token, který se uloží v prohlížeči) a PHP mikroslužba (která dostane token od uživatelova prohlížeče). Takže klient, který se musí mikroslužbě nějak prokázat, je webový prohlížeč.

Tak v tom pripade mate pravdu ze ten token netreba sifrovat ale len podpisat privatnym klucom auth servra aby servica overila ze pochadza od auth servra.

Ale aj tak sa mi nechce verit ze niekto pouziva JWT ako user session. Tym sa ten token stane stavovy. Stav 0: uzivatel xy neprihlaseny, Stav 1: uzivatel xy prihlaseny. Je jedno ci stav 0 je reprezentovany informaciou v tokene alebo jeho absenciou. No, ale ako sa hovori, kto chce kam...
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 03. 08. 2021, 08:31:41
Ale aj tak sa mi nechce verit ze niekto pouziva JWT ako user session.
JWT se vždy používá k udržení stavu. K čemu jinému byste ho chtěl použít?

Stav 0: uzivatel xy neprihlaseny, Stav 1: uzivatel xy prihlaseny.
Myslím, že nechápete, co se myslí „stavem“ a „stavovostí“, když se mluví stavových nebo bez stavových službách.
Název: Re:PHP - mikroslužby - autentizace
Přispěvatel: Filip Jirsák 03. 08. 2021, 08:54:10
Nepoužívejte JWT s local storage. Použijte cookie s Secure, HttpOnly, SameSite=Strict. Cookie musíte chránit před CSRF/XSRF, což je triviální. Přístup k local storage získáte přes XSS, před kterým je dobrá ochrana složitá, nadarmo není v OWASP Top Ten.

Ještě se vrátím k tomuhle. Zajímalo by mne, jak si to představujete prakticky. Bavíme se o mikroslužbách, takže mám hejno služeb poskytujících nějaké API, typicky RESTové. Vedle toho mám hejno aplikací konzumujících ty služby, mezi nimi obvykle nějkaé SPA běžící v prohlížeči.

Konzument může klidně zavolat jedinou API službu a tím veškerá komunikace s tím API končí. Takže nemůžu použít klasické předpotopní ochrany proti CSRF rozbíjející web, které spočívají v tom, že se nevolá API ale zobrzauje se formulář a z něj se odesílají data – takže uživatel musí nejprve zobrazit nějaký formulář, který získá klíč pro jedno volání API. Takže API musí být stavové a uživatel má smůlu při používání prohlížeče – nmůže používat tlačítko zpět, nemůže si formulář duplikovat na další záložce.

OK, budete se tedy snažit zabránit CSRF pomocí SameSite cookie (která závisí na podpoře prohlížeče a bohužel ještě zcela nezmizely prohlížeče, které ji nepodporují). Jenže jde to reálně udělat? Ukažme si to na nějakém příkladu použití mikroslužeb. Představme si vydavatelství, které vydává několik internetových magazínů, a má pro ně společné účty. (Příklad je to čistě hypotetický, s uvedeným vydavatelstvím ani jeho softwarem nemám nic poslečného, jsem jen čtenář.) Takže to vydavatelství má mikroslužbu obhospodařující uživatelské účty dejme tomu na adrese user.api.iinfo.cz. Bude tam nějaký endpoint volaný metodou GET na adrese user.api.iinfo.cz/basicInfo, který vrátí základní informace o uživateli, které s ezobrzaují na každé stránce – jeho uživatelské jméno, odkaz na profilovou fotku, typ podporovatele. Tohle API pak budou volat jednotlivé magazíny třeba z adres root.cz, lupa.cz apod.

To asi se SameSite cookie fungovat nebude, že?