Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: vesterna12 08. 08. 2021, 12:06:42

Název: PHP - deserializace objektu - ošetření vstupu
Přispěvatel: 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
Kód: [Vybrat]
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?
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: tecka 08. 08. 2021, 12:16:41
Pravděpodobně serializaci nepotřebuješ a stoprocentně ne na data v cookies. Tak to prostě nedělej.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: vesterna12 08. 08. 2021, 12:24:11
Potřebuji předat instanci objektu do COOKIE, ale nevím jak to udělat jinak.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Ondrej Nemecek 08. 08. 2021, 12:39:08
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í.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Filip Jirsák 08. 08. 2021, 12:47:48
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.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Filip Jirsák 08. 08. 2021, 13:09:31
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á.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Kit 08. 08. 2021, 13:18:25
Nebylo by jednodušší použít session, kde je tohle vše již vyřešeno včetně hashe?
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: vesterna12 08. 08. 2021, 13:24:57
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...
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Filip Jirsák 08. 08. 2021, 15:17:25
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).
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: to_je_jedno 09. 08. 2021, 09:58:13
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)
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: RDa 09. 08. 2021, 10:45:02
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.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Filip Jirsák 09. 08. 2021, 11:33:54
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?
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Filip Jirsák 09. 08. 2021, 11:36:27
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.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Death Walker 09. 08. 2021, 11:44:13
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...
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Death Walker 09. 08. 2021, 11:54:59
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.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Filip Jirsák 09. 08. 2021, 11:59:34
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.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Logik 09. 08. 2021, 12:13:54
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:
Citace
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.
Název: Re:PHP - deserializace objektu - ošetření vstupu
Přispěvatel: Death Walker 09. 08. 2021, 12:57:44
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.