PHP - mikroslužby - autentizace

[vesterna12]

Č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ě?

[Reklama]

[Filip Jirsák]

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).

[Death Walker]

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.

[Death Walker]

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.

[Filip Jirsák]

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.

[Reklama]

[Death Walker]

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.

[Death Walker]

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...

[Filip Jirsák]

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.

[Death Walker]

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...

[Filip Jirsák]

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…

[Death Walker]

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. 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...

[🇺🇦 cjohn]

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).

[Filip Jirsák]

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.

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.)

[Death Walker]

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.

[Filip Jirsák]

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.