PHP - mikroslužby - autentizace

[Filip Jirsák]

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

[Reklama]

[vesterna12]

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

[FactChecker]

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.

[Filip Jirsák]

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.

[Filip Jirsák]

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.

[Reklama]

[FactChecker]

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:

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.

[Filip Jirsák]

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í:

• Psát aplikaci tak, aby nebyla náchylná na XSS.
• Zabezpečit aplikaci pomocí CSP tak, aby v prohlížečích, které CSP podporují, nebylo XSS možné.
• Aplikace je proti XSS odolná, takže mohu směle použít sessionStorage a nemusím se bát CSRF.

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

[tomas88]

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/

[Death Walker]

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. 

[Death Walker]

Tolik zbytečných vět.

Jj, gish gallop je jeho oblubeny argumentacny klam, nie len tu

[Death Walker]

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

[Filip Jirsák]

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

[Death Walker]

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.

[Filip Jirsák]

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

[Death Walker]

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