Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: vesterna12 08. 08. 2021, 12:06:42
-
Pomoci sha1 a serialize vytvarim hash instance objektu User.
Instance objektu je ulozena v COOKIE pomoci base64_encode.
Pomoci
unserialize(base64_decode($_COOKIE['user']),["allowed_classes" => ["User"]]); ; ziskavam objekt zpet a kontroluji jeho integritu znovu pomoci sha1 serialize.
Cetl jsem par clanku a ocividne to neni bezpecne, protoze deserialize methoda je snadno napadnutelna.
Muzu nejak vic ochranit unserialize metodu?
-
Pravděpodobně serializaci nepotřebuješ a stoprocentně ne na data v cookies. Tak to prostě nedělej.
-
Potřebuji předat instanci objektu do COOKIE, ale nevím jak to udělat jinak.
-
COOKIE má omezenou velikost, buď uložit do persistentního storage v browseru anebo si do cookie uložit jen identifikátor objektu a uložit si to na serveru anebo použít session, kde to již vše víceméně vyřešené. Nejlépe si o tom něco přečíst, je tam totiž více různých úskalí.
-
Není mi jasné, jak tam pracujete s tím hashem. Pokud znáte hash serializovaných dat, můžete nejprve ověřit hash a pak až deserializovat – tím máte zaručeno, že nemohl nikdo serializovaná data podvrhnout.
Pro serializaci krátkých dat posílaných mezi prohlížečem a serverem se dnes obvykle používá JSON Web Token.
Každopádně ale to, o co se pokoušíte, je celé divné. Lepší by bylo, kdybyste popsal, jaký problém řešíte. Nejspíš už to řešily tisíce lidí před vámi a existuje na to nějaké ověřené řešení, možná dokonce standard.
-
Pokud znáte hash serializovaných dat
Tím bylo samozřejmě myšleno, že zároveň uživatel nemůže správný hash podvrhnout. Tj. buď je hash uložený jenom na serveru, nebo se sice bere hash od uživatele, ale je to hash vytvořený z dat a z tajemství, které uživatel nezná.
-
Nebylo by jednodušší použít session, kde je tohle vše již vyřešeno včetně hashe?
-
Chtěl jsem se vyhnout replikaci relací.
Uživatel měl předložit podepsanou instanci objektu, která obsahuje info o autorizaci a autentizaci.
Teď jsem si na tom pěkně vylámal zuby.
Buď budu muset nastavit replikaci nebo objekty ukládat do db a získávat je zpět pomocí id uloženého v cookie...
-
Uživatel měl předložit podepsanou instanci objektu, která obsahuje info o autorizaci a autentizaci.
To zní přesně jako JSON Web Token (https://jwt.io).
-
Na co presne tady nestaci PHP session (a pripadne jeji ukladani do memcache pokud je vice PHP serveru na backendu)? Stejne by tam melo byt jen user id a cely objekt inicializovat jako entitu (a je jedno jestli z DB nebo nejake cache layer)
-
Cetl jsem par clanku a ocividne to neni bezpecne, protoze deserialize methoda je snadno napadnutelna.
Muzu nejak vic ochranit unserialize metodu?
Podivejte se na ten serializovany format - a napiste si REGEX ktery to velice striktne matchne od ^ po $. Snad vite kde v objektech mate cisla a pismenka.. ponekud horsi to bude jestli tam chcete prenaset binarky nebo UTF.
-
Na co presne tady nestaci PHP session (a pripadne jeji ukladani do memcache pokud je vice PHP serveru na backendu)? Stejne by tam melo byt jen user id a cely objekt inicializovat jako entitu (a je jedno jestli z DB nebo nejake cache layer)
Proč tam zavádět memcache, pokud se jinak nepoužívá? Proč zavádět centrální bod, na kterém bude záviset vše a který bude úzkým hrdlem při škálování aplikace?
-
Podivejte se na ten serializovany format - a napiste si REGEX ktery to velice striktne matchne od ^ po $. Snad vite kde v objektech mate cisla a pismenka.. ponekud horsi to bude jestli tam chcete prenaset binarky nebo UTF.
Takového řešení bych se dost bál. Jednak že stejně nepodchytíte nějakou možnost, jak tam útočník propašuje něco škodlivého. Jednak že se formát serializace změní. Je vůbec v PHP při serializaci zaručeno, že bude pořadí prvků stále stejné? Já pro takovou záruku nevidím žádný důvod.
-
Proste pouzit redis backend pre session. Je jedno ci ide o maly projekt kde bude jedna redis node, alebo velky projekt kde bude cluster n redis node... Tie php containery sa tym stanu bezstavove. Len sa ta stavovost neprenesie do browseru uzivatela, ale tam kam patri. To o co sa znazite vy, na tom si vylamalo zuby uz mnoho vyvojarov. Nie vsetko co najdete na webe je navod ale skor varovanie...
-
Jednak že se formát serializace změní. Je vůbec v PHP při serializaci zaručeno, že bude pořadí prvků stále stejné? Já pro takovou záruku nevidím žádný důvod.
No, ona ta zaruka tam nie je. Php ma tych serializatorov niekolko. Da sa to pouzit iba pre session alebo pre cache, ci ine co nevadi ak po restarte servra zmizne. Videl som uz x projektov, ktore technologicky zamrzli koli tomu, ze nejakeho sialenca napadlo ukladat serializovane objekty do databazy.
-
Proste pouzit redis backend pre session.
Prostě zavést do systému další komponentu, o kterou se musíte starat a kterou musíte platit.
Len sa ta stavovost neprenesie do browseru uzivatela, ale tam kam patri.
HTTP protokol vznikl jako bezstavový. Stav do toho přináší až uživatel. Takže podle mne stav patří na klienta.
To o co sa znazite vy, na tom si vylamalo zuby uz mnoho vyvojarov.
Zároveň to mnoho vývojářů úspěšně provozuje.
-
Také se mi to zdá jako úplně ukázková věc na aplikaci redisu.
Nicméně, pokud bych už to chtěl řešit bez "externího úložiště" a použít PHP serializaci, tak bych k serializovanému objektu připojil ještě hash s nějakým secret code (defakto další podpis), kterej bych ověřil před unserializací. Ale i tak i to přijde jako "very bad practice".
Pokud už posílat nějaká data takto na klienta, tak ne serializovaný objekt, ale např. něco v JSON formátu a ten objekt z toho JSONu vytvořit "ručně". Tam je podstatně menší prostor na bezpečnostní díry, než při použití serializace. Ale to jsme vlastně u toho JSON web tokenu, kterej tu někdo navrhoval, aneb u klasické zásady:
Pokud se něco týká bezpečnosti, POUŽIJ OSVĚDČENÁ ŘEŠENÍ. Šance, že při samodomo řešení bezpečnosti něco uděláš blbě je v podstatě 100%. To neplatí jen pro úplné lopaty:lidí, kteří opravdu zvládají všechny aspekty bezpečnosti a zároveň jsou ještě k tomu schopni je dobře implementovat zas tak moc není.
Filip:
HTTP protokol vznikl jako bezstavový. Stav do toho přináší až uživatel. Takže podle mne stav patří na klienta.
Vznikl, ale také vznikl pro naprosto jiné účely, než pro které se dnes používá. Takže ať už se to bude řešit jakkoli, vždycky to je "rovnák na vohejbák". Oni už samotný cookies, který k tomu ať tak či tak použiješ, popíraj původní ideu HTTP.
-
Proste pouzit redis backend pre session.
Prostě zavést do systému další komponentu, o kterou se musíte starat a kterou musíte platit.
Bez tak, ako vzdy dojde na to ze radsej ako 10000x to generovat v php, tak je lepsie 1x php a 9999x si siahnut do cache. Php v dnesnej dobe sic uz nie je tak pomale, ale stale to nie je raketa.
Naviac ide kp komponentu naviac, ktorej vyvoj ide mimo vyvojara konkretnej aplikacie. Kdezto riesenie urobime to v php, je funkcionalita o ktoru sa zbytocne naviac musi starat vyvojar.
Len sa ta stavovost neprenesie do browseru uzivatela, ale tam kam patri.
HTTP protokol vznikl jako bezstavový. Stav do toho přináší až uživatel. Takže podle mne stav patří na klienta.
Podla mna ani nie, s pohladu uzivatela ide o poziadavku a odpoved. Na strane serveru je odlisit jednotlivych uzivatelov tak aby dostali odpoved v spravnom kontexte.
To o co sa znazite vy, na tom si vylamalo zuby uz mnoho vyvojarov.
Zároveň to mnoho vývojářů úspěšně provozuje.
Slovo uspech je vysoko relativne. "Uspech je, ze to funguje" asociuje so slovom zazrak.