Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: maw abi 16. 03. 2020, 23:51:06

Název: Bezpečná session v PHP
Přispěvatel: maw abi 16. 03. 2020, 23:51:06
Ahoj.
Chystám se napsat webík v php do kterého se budou přihlašovat uživatelé. Chci se zeptat jak udělat bezpečně logování a obecně správu uživatelské session.
Upřímně jsem v tom nový, takže možná někde plácnu nějakou pitomost nicméně.
a) je bezpečné používat php sessions? Nebo už se používá něco jiného?
b) nechci moc používat "jakési" nadstavby a frameworky, bojím se jich - že přestanou být podporovány, zaniknou a já to pak budu muset celé předělávat. Takže ideálně používat jen čisté php.
c) jak je to s https? Kdesi jsem četl (ale už nemůžu najít) že je lepší místo sessions používat rovnou https a pak vše včetně hesla posílat šifrovaně a session neřešit.

Takže jsem v pasti :-)

Dík za nakopnutí. Pokud by jste mne odkázali na nějaký relativně aktuální jednoduchý postup či příklad jak na to, byl bych moc rád. (A nebo na něco starého s tím, že je to stále aktuální a bezpečný postup :-) )

PS: Jde mi fakt jen o nastínění základů - jak udělat sesion či jak si pak zřídit přes let's encrypt certifikát už si pořeším sám. Jde o to, poradit mi v pár základních bodech jak správně udělat bezpečný web s přihlašováním uživatelů.
Název: Re:bezpečná session v php
Přispěvatel: Filip Jirsák 17. 03. 2020, 08:09:28
Pokud o věci nic nevíte, naopak nějakou nadstavbu použijte, pokud možno přesně podle návodu. Je pravděpodobné, že alespoň některé věci kolem bezpečnosti má vyřešené správně. Když to budete dělat sám, nebudete mít ošetřené nic.

PHP session je jen řešení na straně serveru, které na základě nějakého identifikátoru poslaného z prohlížeče pozná, o kterou session se jedná a její data vám zpřístupní. To, co se mění, je způsob, jak bezpečně dostat ten identifikátor z prohlížeče na server, ne samotná serverová implementace. Ale pokud bude veškerá komunikace šifrovaná v rámci HTTPS, použijte standardní cestu předávání session identifikátoru pomocí cookie.

HTTPS slouží „jen“ k šifrování spojení, identifikaci session pomocí něj nezajistíte.

Nicméně bez alespoň základních znalostí o bezpečnosti ten web stejně neuděláte bezpečný. Nejde o to vědět pár bodů, jak některé věci udělat bezpečně. Kdyby to mělo být bezpečné, musíte o každé části aplikace vědět, jaké jsou tam potenciální hrozby. K tomu je potřeba znát co nejvíce možných hrozeb a umět vyhodnotit, které se vás týkají.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 09:16:12
PHP sessions se dají používat zcela bezpečně, jen musíte vědět, která data se do ní hodí a jak s nimi pracovat. To není na rozepsání do diskuse. Spousta internetových rad je nedobrých, nedomyšlených.

Alternativou k PHP sessions je JWT - Json Web Tokens (https://en.wikipedia.org/wiki/JSON_Web_Token). Výhodou je, že si data nese prohlížeč a nejsou uložena na serveru. Díky tomu můžete postavit víc serveru a mezi nimi přepínat / balancovat provoz. U klasické PHP session musíte řešit, aby do ní viděly všechny servery, u JWT nikoliv.

Ať už PHP session nebo JWT, v obou případech je nejčastější začátečnickou chybou ukládání příliš mnoho dat do session a málo do úložiště aplikace (databáze). Do session by mělo přijít co nejméně dat, jen ta, která se vztahují k dané relaci. Ostatní se mají ukládat aplikačně. Příkladem je např. košík na eshopu - ten nemá v session co dělat, protože potřebujete pravidelně ověřovat dostupnost zboží, změny cen a potřebujete, aby byl stejný košík vidět po přihlášení z různých počítačů. Do session naopak patří informace o tom, kdo je přihlášený (id / hash uživatele) nebo např. informace o naposledy navštívených produktech (kvůli navigaci zpět).

Doporučil bych vzít framework, který toto řeší. Z mojí zkušenosti, vyhnul bych se Nette (nedodělané, nestálý vývoj, špadná dokumentace), z těch větších mi přijde dobré Symfony. Učitě bych to neprogramoval sám. Sice o Vašich chybách nebude nikdo cizí vědět, ale uděláte spoustu i začátečnických chby. I vlastní framework budete muset neustále vyvíjet a upravovat - a zkušenost praví, že je jednodušší počítat s pravidelnými updaty cizího frameworku, než neustále měnit něco svého. S obojím je hodně práce, dnes už nic nefunguje tak, že jednou uděláte a pak na to roky nemusíte sáhnout.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 17. 03. 2020, 09:40:04
Alternativou k PHP sessions je JWT - Json Web Tokens (https://en.wikipedia.org/wiki/JSON_Web_Token). Výhodou je, že si data nese prohlížeč a nejsou uložena na serveru. Díky tomu můžete postavit víc serveru a mezi nimi přepínat / balancovat provoz. U klasické PHP session musíte řešit, aby do ní viděly všechny servery, u JWT nikoliv.
To je omyl. JWT i cookies mohou nést data i pouhý identifikátor session, v tom se nijak neliší.

HTTP je nestavový protokol, tj. z hlediska serveru je každý požadavek od klienta nový, jako by klienta nikdy před tím neviděl. Což se dá řešit dvěma způsoby – buď klient s každým požadavkem pošle data, která server potřebuje (a která požadavek často nějak svážou s předchozími požadavky – třeba identifikací uživatele), nebo klient posílá jenom nějakou identifikaci a data jsou uložená ne serveru (tomu se právě říká session).

Klasická PHP session je udělaná tak, že data jsou uložená na serveru a klient v cookie posílá jenom jednoznačný identifikátor session. Klidně ale může pomocí cookie předávat i jiné údaje, třeba identifikátor uživatele. A pokud potřebných údajů nebude mnoho, mohou se všechny předávat pomocí cookie a žádná session na serveru nemusí být.

JWT je jenom jiný (modernější) způsob předávání dat mezi prohlížečem a serverem. JWT se může předávat i pomocí cookies (i když to není obvyklé, spíš se používají HTTP hlavičky nebo URL). Předností JWT oproti dříve používaným způsobům je to, že data v JWT mohou být podepsaná (a mohou být i šifrovaná). Nebo-li klient nemůže manipulovat s tím, co mu poslal server. Například pokud byste vytvářel identifikátory session ze sekvence, a posílal to ID nepodepsané, může útočník klidně vzít svoje ID, odečíst jedničku a poslat takto upravené ID – a v tu ránu bude mít session úplně někoho jiného a bude vůči serveru vystupovat jeho jménem. Proto jsou ve skutečnosti identifikátory session generované náhodně, aby nebylo možné uhodnout cizí identifikátor session. Dá se to ale řešit i přes JWT –  pak může být identifikátor klidně generován ze sekvence, protože útočník sice může odvodit identifikátor jiné session, ale nepodaří se mu JWT správně podepsat. Na serveru pak selže validace podpisu JWT a server ví, že JWT nemůže věřit (a vrátí klientovi nějakou chybovou zprávu).
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 09:44:23
Alternativou k PHP sessions je JWT - Json Web Tokens (https://en.wikipedia.org/wiki/JSON_Web_Token). Výhodou je, že si data nese prohlížeč a nejsou uložena na serveru. Díky tomu můžete postavit víc serveru a mezi nimi přepínat / balancovat provoz. U klasické PHP session musíte řešit, aby do ní viděly všechny servery, u JWT nikoliv.
To je omyl. JWT i cookies mohou nést data i pouhý identifikátor session, v tom se nijak neliší.

Ano, přesně tak, to se nevylučuje. Systém, který v session / JWT přenáší jen identifikátor (např. uživatele), je podle mě nejlepší. Vzniká tím nejméně problémů v aplikaci. Zejména když se mění struktura dat, která ukládáme v session. Já jsem zmiňoval třeba nákupní košík - tam se může v čase struktura rozšiřovat (např. o pole dostupnosti, akční ceně, ...). Pak je potřeba v aplikaci zavést verzování struktury, nebo se spoléhat checky v aplikaci (aby chybějící pole v session doplnila). To už je rovnou jednodušší to ukládat ve struktuře do databáze.

Sessions (i JWT) jsou v praxi nadužívané i na data, na která se to nehodí.
Název: Re:Bezpečná session v PHP
Přispěvatel: maw abi 17. 03. 2020, 13:29:19
Super. Díky za nápovědu.
Ještě se zeptám. Ošetřuje se nějak situaci kdy má klient vypnuté cookies? Jak se pak chová server? Na základě čeho ověří že se jedná o daného uživatele.

Když to shrnu do bodů
a) na serveru je stránka s logováním
b) uživatel načte stránku + zadá jméno a heslo
c) odešle formulář (pomocí post?)
d) na serveru z post získám jméno + heslo (nevím jestli je tohle bezpečné nebo už tady je něco špatně?). Heslo se nějak musí dostat z formuláře klienta na můj server. Nevím jak je toto bezpečné.
e) na serveru ověřím uživatele a pokud je ok, pošlu mu sessionid (náhodně generované kvůli únosu a nebo sekvenčně pokud použiju jwt)
f) klient má id uložené v cookie? a při každém dotazu jej z cookie načte a pošle mi jej?


Pokud bych se vykašlal na cookie můžu mít to id uložené jen někde v paměti ? Nepotřebuju aby session zůstávala třeba 10 hod aktivní. Nedělám eshop, takže pokud uživatel zavře tab a otevře jiný nový, klidně jej donutím znova se přihlásit. Nebude to zas až tak častá aktivita (předpokládám).

Taky jsem četl, že pro bezpečnější web je dobré u kritických operací sessionid zahodit, vygenerovat nové a nechat uživatele znova ověřit (pro jistotu, aby bylo jisté že se nejedná o podvrh). Takže pokud bych narazil na jějakou kritickou část (například změna hesla), můžu to klidně udlěat i takto.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 13:39:20
To co popisujete je klasické poor man's řešení, oblíbené v kuchařkách na internetu a pramenící tak někdy z devadesátých let.

Dnešní ezpečnost:
1. heslo zpracovat už na straně browseru; osolit a vygenerovat hash; případně lze ještě ze serveru poskytnout pubkey, browser data ještě zašifruje a rozšifruje je až server (na toto slouží lépe JTW); rozhodně neposílat postem heslo
2. po ověření zaznamenat do DB id uživatele a čas přihlášení (kvůli timeoutu)
3. do session uložit zašifrovanou informaci o přihlášení (id z předchozí tabulky; výhodné je používat UUID namísto SERIALU)
4. s každým požadavkem na server aktualizovat v tabulce čas posledního přístupu
5. hlídat timeout (po X hodinách od posledního přístupu už nepovolit přístup "přihlášenému" uživateli)
6. do session neukládat žádnou jinou významnou informaci, maximálně balast typu "poslední navštívená stránka", "produkty které jsem shlédl", ... ale i to raději ukládat do DB a sanitizovat
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 17. 03. 2020, 14:11:11
Super. Díky za nápovědu.
Ještě se zeptám. Ošetřuje se nějak situaci kdy má klient vypnuté cookies? Jak se pak chová server? Na základě čeho ověří že se jedná o daného uživatele.

Když to shrnu do bodů
a) na serveru je stránka s logováním
b) uživatel načte stránku + zadá jméno a heslo
c) odešle formulář (pomocí post?)
d) na serveru z post získám jméno + heslo (nevím jestli je tohle bezpečné nebo už tady je něco špatně?). Heslo se nějak musí dostat z formuláře klienta na můj server. Nevím jak je toto bezpečné.
e) na serveru ověřím uživatele a pokud je ok, pošlu mu sessionid (náhodně generované kvůli únosu a nebo sekvenčně pokud použiju jwt)
f) klient má id uložené v cookie? a při každém dotazu jej z cookie načte a pošle mi jej?


Pokud bych se vykašlal na cookie můžu mít to id uložené jen někde v paměti ? Nepotřebuju aby session zůstávala třeba 10 hod aktivní. Nedělám eshop, takže pokud uživatel zavře tab a otevře jiný nový, klidně jej donutím znova se přihlásit. Nebude to zas až tak častá aktivita (předpokládám).

Taky jsem četl, že pro bezpečnější web je dobré u kritických operací sessionid zahodit, vygenerovat nové a nechat uživatele znova ověřit (pro jistotu, aby bylo jisté že se nejedná o podvrh). Takže pokud bych narazil na jějakou kritickou část (například změna hesla), můžu to klidně udlěat i takto.

Pokud chcete použít PHP, je tohle obvyklý postup. To, že se v d) posílá z klienta jméno a heslo je dnes absolutně nejrozšířenější postup. Posílá se to šifrovaně přes HTTPS, takže z tohohle pohledu to nevadí. Problém je, že heslo zná server, ale to dnes skoro nikdo neřeší. A posílá se to metodou POST, kdybyste to poslal GETem, zůstane to v logu a bude to vidět v referreru.

Klient posílá session ID jako cookies – vy se o to nemusíte starat, cookie nastavíte a klient ji pak automaticky posílá s každým požadavkem.

Session ID můžete mít v prohlížeči uložený v paměti, ale stejně musíte zařídit, aby se s každým požadavkem odeslal na server. Cookies je to nejsnazší řešení, tam se nemusíte o nic starat, jenom ji poprvé nastavíte na serveru a dál se o nic nestaráte. Resp. i o to nastavení si zařídí použitý framework nebo PHP.

S opakovaným ověřením uživatele bych byl hodně opatrný. To má smysl u banky, když potvrzujete převedení peněz, ale jinak bude opakované zadání hesla uživatele hodně otravovat. Používá se to nanejvýš u té změny hesla (a i u té je to podle mne sporné).

Ukládání posledního přístupu do DB bych v tuto chvíli neřešil, čas posledního přístupu můžete mít v session. Resp. o platnost session se vám bude starat už framework nebo snad přímo PHP. Z vaší strany je potřeba akorát session invalidovat/zrušit v okamžiku, kdy se uživatel odhlásí.
Název: Re:Bezpečná session v PHP
Přispěvatel: petr.parolek 17. 03. 2020, 14:13:09

Doporučil bych vzít framework, který toto řeší. Z mojí zkušenosti, vyhnul bych se Nette (nedodělané, nestálý vývoj, špadná dokumentace), z těch větších mi přijde dobré Symfony. Učitě bych to neprogramoval sám. Sice o Vašich chybách nebude nikdo cizí vědět, ale uděláte spoustu i začátečnických chby. I vlastní framework budete muset neustále vyvíjet a upravovat - a zkušenost praví, že je jednodušší počítat s pravidelnými updaty cizího frameworku, než neustále měnit něco svého. S obojím je hodně práce, dnes už nic nefunguje tak, že jednou uděláte a pak na to roky nemusíte sáhnout.

O Nette koukám nevíš nic, má dobrou dokumentaci, dokonce i v češtině. Nette doporučuju, hllavní výhoda je velká česká komunita. Pokud se ti nrlíbí něco na dokumentaci nebo v kodu, pošli pull request nebo věcnou issue na GitHub. Hanět umí každý a přiložit ruku k dílu už míň lidí, smutné. Já to dělám obráceně - když se mi něco nelíbí, nenadává, ale snažím se přispět.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 14:19:25
O Nette koukám nevíš nic, má dobrou dokumentaci, dokonce i v češtině. Nette doporučuju, hllavní výhoda je velká česká komunita. Pokud se ti nrlíbí něco na dokumentaci nebo v kodu, pošli pull request nebo věcnou issue na GitHub. Hanět umí každý a přiložit ruku k dílu už míň lidí, smutné. Já to dělám obráceně - když se mi něco nelíbí, nenadává, ale snažím se přispět.

U nás máme 80 % projektů na Nette a utíkáme od něj, protože trpí spoustou neduhů. Ne tolik technických, jako spíš v neuspořádanosti vývoje, ve vezrování a kompatibilitě komponent atd., které nikdo nespravuje. V produkci to přináší spoustu nákladů navíc. Nedokumentovaných funkcí je, že by člověk až brečel. Radím z velké praxe. Potřebuji vyvíjet to, co mám za úkol a ne dlouze dohledávat a na konci dohledávání zjistit, že to v celé Nette komunitě nikdo neřeší. Dokumentaci si porovnejte Symfony a Nette, knowledge base taky. David a Goliáš.
Název: Re:Bezpečná session v PHP
Přispěvatel: maw abi 17. 03. 2020, 14:31:51
Díky za odpovědi.

Ještě dva dotazy.

- Je v nějakém frameworku pro PHP JWT použitelně zpracované?
(než jsem položil dotaz, sleduju že jsem nechtěně vyrobil bitvu... tzn buď nette nebo sympfony)

- Pokud bych se rozhodl nepoužívat framework, tak v php existuje funkce
password_hash(string $password , int $algo ...)
Ta zdá se umožní volit jak šifrovací algoritmus, tak přidat sůl. Je to ok? Nebo děláte hash jinak?
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 17. 03. 2020, 14:34:04
To co popisujete je klasické poor man's řešení, oblíbené v kuchařkách na internetu a pramenící tak někdy z devadesátých let.

Dnešní ezpečnost:
1. heslo zpracovat už na straně browseru; osolit a vygenerovat hash; případně lze ještě ze serveru poskytnout pubkey, browser data ještě zašifruje a rozšifruje je až server (na toto slouží lépe JTW); rozhodně neposílat postem heslo
2. po ověření zaznamenat do DB id uživatele a čas přihlášení (kvůli timeoutu)
3. do session uložit zašifrovanou informaci o přihlášení (id z předchozí tabulky; výhodné je používat UUID namísto SERIALU)
4. s každým požadavkem na server aktualizovat v tabulce čas posledního přístupu
5. hlídat timeout (po X hodinách od posledního přístupu už nepovolit přístup "přihlášenému" uživateli)
6. do session neukládat žádnou jinou významnou informaci, maximálně balast typu "poslední navštívená stránka", "produkty které jsem shlédl", ... ale i to raději ukládat do DB a sanitizovat

Co je špatně na $_SESSION „z devadesátkých let“ pokud používám vynucené https? IMHO je to pro řadu případů zcela dostačující řešení. Spíš bych si dal pozor na SQL injection při zadávání jména a hesla.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 14:39:21
Co je špatně na $_SESSION „z devadesátkých let“ pokud používám vynucené https? IMHO je to pro řadu případů zcela dostačující řešení. Spíš bych si dal pozor na SQL injection při zadávání jména a hesla.

Posílat heslo po HTTPS považuji za zbytečné, když může práci provést klient. Aplikace heslo nemusí nikdy znát a nikdy obdržet. Sníží se tím riziko MITM útoku na HTTPS. V devadesátých letech byla ještě spousta užití a prohlížečů, které JS implementovaly všelijak, takže se vše provádělo server side, mělo to racionální důvod. Dnes ten důvod už neexistuje a jede se jen ze setrvačnosti. Pan kolega se ptal na bezpečnost, tak k tomu směřovala odpověď.

Na SQL injections je opravdu potřeba si dát pozor, vždy a v každém případě!
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 17. 03. 2020, 15:03:20
- Je v nějakém frameworku pro PHP JWT použitelně zpracované?
Určitě ano, ale pro vaše potřeby to je kanón na vrabce. JWT se používá pro SPA aplikace, kde máte nějaké API (třeba REST nebo GraphQL), kterým komunikuje webová aplikace se serverem. A server můžou tvořit třeba mikroservisy. Pokud chcete udělat pár formulářů v PHP, nic takového nepotřebujete.

- Pokud bych se rozhodl nepoužívat framework, tak v php existuje funkce
password_hash(string $password , int $algo ...)
Ta zdá se umožní volit jak šifrovací algoritmus, tak přidat sůl. Je to ok? Nebo děláte hash jinak?
Ano, je to OK. Naopak se to nesnažte dělat sám – pravděpodobnost, že to uděláte správně, když o tom nic nevíte, je skoro nulová.

Co je špatně na $_SESSION „z devadesátkých let“ pokud používám vynucené https? IMHO je to pro řadu případů zcela dostačující řešení. Spíš bych si dal pozor na SQL injection při zadávání jména a hesla.
Špatně na tom samozřejmě není nic, pro tazatele je to nejlepší řešení.

Posílat heslo po HTTPS považuji za zbytečné, když může práci provést klient.
To je hezká teorie. Jenže ten, kdo se tím může řídit, protože na to má dostatečné znalosti, se nebude takhle ptát na Rootu. Pro maw abi by to ale byla cesta do pekel, pro něj je nejlepší použít to, co používají všichni – takže v PHP klasickou $_SESSION, přihlašování přes formulář a POST, hashování hesla přes password_hash(). Resp. použít nějaký framework, který bude zapouzdřovat práci s databází (především kvůli hrozbě SQL injection) – přičemž je možné, že ten framework už bude mít i nějakou svou podporu pro přihlašování uživatelů (která ale interně bude používat výše uvedené).
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 15:11:24
To je hezká teorie. Jenže ten, kdo se tím může řídit, protože na to má dostatečné znalosti, se nebude takhle ptát na Rootu. Pro maw abi by to ale byla cesta do pekel, pro něj je nejlepší použít to, co používají všichni – takže v PHP klasickou $_SESSION, přihlašování přes formulář a POST, hashování hesla přes password_hash()

Předpokládám, když se ptá, že chce získat přehled, jaké jsou možnosti. To, co popisujete, je možná nejpoužívanější, ale dnes už je jasné, že je to překonané a budoucnost si s tím nevystačí. Rozhodnutí je samozřejmě na tazateli, nemůžeme tu posoudit o jak citlivá data jde, jestli hrozí riziko finančních škod atd.
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 17. 03. 2020, 15:12:03
Co je špatně na $_SESSION „z devadesátkých let“ pokud používám vynucené https? IMHO je to pro řadu případů zcela dostačující řešení. Spíš bych si dal pozor na SQL injection při zadávání jména a hesla.

Posílat heslo po HTTPS považuji za zbytečné, když může práci provést klient. Aplikace heslo nemusí nikdy znát a nikdy obdržet. Sníží se tím riziko MITM útoku na HTTPS. V devadesátých letech byla ještě spousta užití a prohlížečů, které JS implementovaly všelijak, takže se vše provádělo server side, mělo to racionální důvod. Dnes ten důvod už neexistuje a jede se jen ze setrvačnosti. Pan kolega se ptal na bezpečnost, tak k tomu směřovala odpověď.

Na SQL injections je opravdu potřeba si dát pozor, vždy a v každém případě!

Samozřejmě v principu máte pravdu a je bezpečnější, aby server heslo neznal. Ale pro tazatele je důležité, aby pochopil základ, což je v daném usecase:


Teprve při zvládnutí tohoto má podle mě cenu zvednou laťku a nasazovat javascript.
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 17. 03. 2020, 15:15:26
Super. Díky za nápovědu.
Ještě se zeptám. Ošetřuje se nějak situaci kdy má klient vypnuté cookies? Jak se pak chová server? Na základě čeho ověří že se jedná o daného uživatele.

Když to shrnu do bodů
a) na serveru je stránka s logováním
b) uživatel načte stránku + zadá jméno a heslo
c) odešle formulář (pomocí post?)
d) na serveru z post získám jméno + heslo (nevím jestli je tohle bezpečné nebo už tady je něco špatně?). Heslo se nějak musí dostat z formuláře klienta na můj server. Nevím jak je toto bezpečné.
e) na serveru ověřím uživatele a pokud je ok, pošlu mu sessionid (náhodně generované kvůli únosu a nebo sekvenčně pokud použiju jwt)
f) klient má id uložené v cookie? a při každém dotazu jej z cookie načte a pošle mi jej?


Pokud bych se vykašlal na cookie můžu mít to id uložené jen někde v paměti ? Nepotřebuju aby session zůstávala třeba 10 hod aktivní. Nedělám eshop, takže pokud uživatel zavře tab a otevře jiný nový, klidně jej donutím znova se přihlásit. Nebude to zas až tak častá aktivita (předpokládám).

Taky jsem četl, že pro bezpečnější web je dobré u kritických operací sessionid zahodit, vygenerovat nové a nechat uživatele znova ověřit (pro jistotu, aby bylo jisté že se nejedná o podvrh). Takže pokud bych narazil na jějakou kritickou část (například změna hesla), můžu to klidně udlěat i takto.

Pokud nastavíte https://www.php.net/manual/en/session.configuration.php#ini.session.auto-start na true tak bude session v PHP fungovat úplně automaticky. Do session zapíšete kdykoli prostým vložením hodnoty do pole $_SESSION a údaje získáte naopak čtením ze $_SESSION. Session id si PHP uloží automaticky do cookies v prohlížeči, takže bude PHP schopné při každém requestu ztotožnit požadavek prohlížeče s příslušnou session na serveru. Životnost session bude PHP také hlídat automaticky. Pokud bude web nastaven tak, aby běžel vynuceně na https, je to i relativně bezpečné. Je lepší se spolehnout na toto hotové řešení přítomné v PHP než se snažit si session implementovat jinak - šance, že uděláte při vlastní implementaci chybu, je značná.

Do $_SESSION si uložíte cokoli potřebujete, typicky identifikátor přihlášeného uživatele. Takže při prvním přihlášení ověříte přítomnost jména a hesla v databázi (budete hledat v databázi hash hesla, aby tam nebyla hesla uložena v čitelné podobě) a při úspěchu si uložíte identifikátor uživatele do $_SESSION. Při dalších požadavcích kontrolujete přítomnost identifikátoru v $_SESSION a přítomnost uživatele v databázi. Pokud bude nalezen, je přihlášen, pokud nikoli, není přihlášen. Při odhlášení zrušíte nejlépe celou session https://www.php.net/manual/en/function.session-destroy.php

Při zadávání jména a hesla dejte pozor na SQL injection, nejlepší je použít hotovou knihovnu. Stačí použít prepared statements v PDO případně nadstavby PDO. PDO měla také nějaké zranitelnosti, aktuální stav ale neznám, takže mě případně někdo doplní (IMHO při použití současných verzí Mysql a PHP je to již vyřešeno).
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 15:55:17
Teprve při zvládnutí tohoto má podle mě cenu zvednou laťku a nasazovat javascript.

Nevím, to je podle mě jako učit ve škole psát na stroji a k počítači až za zásluhu. Moje zkušenost velí učit programátory pochopit potřebné technologie, ale to je asi věc názoru.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 15:56:47
Pokud nastavíte https://www.php.net/manual/en/session.configuration.php#ini.session.auto-start na true tak bude session v PHP fungovat úplně automaticky.

To bych nedělal. Podle nařízení EU i podle české legislativy musí být cookie formou opt-in. Zatím se to přechodně porušuje (různé cookie bary často nastaví cookie dřív, než návštěvník odsouhlasí). Ale není to rozhodně dobrá rada pro nový projekt.
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 17. 03. 2020, 16:16:20
Teprve při zvládnutí tohoto má podle mě cenu zvednou laťku a nasazovat javascript.

Nevím, to je podle mě jako učit ve škole psát na stroji a k počítači až za zásluhu. Moje zkušenost velí učit programátory pochopit potřebné technologie, ale to je asi věc názoru.

Jasně, nic proti, didaktika je do značné míry subjektivní disciplína (a u každého funguje trochu jinak).
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 17. 03. 2020, 16:26:26
Předpokládám, když se ptá, že chce získat přehled, jaké jsou možnosti.
Tak příště radši nepředpokládejte a místo toho čtěte zadání. maw abi nechce znát možnosti, chce se dozvědět úplné základy.

To, co popisujete, je možná nejpoužívanější, ale dnes už je jasné, že je to překonané a budoucnost si s tím nevystačí.
Jenže to budou implementovat lidé, kteří alespoň trochu vědí, o čem je řeč. Ne někdo,kdo se právě začal učit PHP. Hashovat heslo už v prohlížeči je teoreticky samozřejmě správně, ale když to bude implementovat někdo, kdo tomu vůbec nerozumí, bude výsledek milionkrát nebezpečnější, než když heslo standardně odešle POSTem přes HTTPS a na serveru zahashuje přes password_hash(). Což tazatel samozřejmě vědět nemůže, ale vy byste to vědět měl, když chcete radit.

Rozhodnutí je samozřejmě na tazateli, nemůžeme tu posoudit o jak citlivá data jde, jestli hrozí riziko finančních škod atd.
Pokud jste z dotazu nepochopil, že maw abi v žádném případě nemá kvalifikaci na to, aby tohle dokázal posoudit, raději nikdy nikomu nic neraďte. Že to maw abi nedokáže posoudit je naprosto v pořádku, začíná se v problematice zorientovávat. Špatné je to, jaké nesmysly píšete vy.

Nevím, to je podle mě jako učit ve škole psát na stroji a k počítači až za zásluhu. Moje zkušenost velí učit programátory pochopit potřebné technologie, ale to je asi věc názoru.
Ne, to není věc názoru. To je věc toho, že absolutně nedokážete rozumně poradit. Vy jste nikomu nepomohl pochopit nějaké technologie – akorát jste někomu zamotal hlavu, a po několikátém upozornění z vás teprve vypadlo, že aby to mohl maw abi posoudit, musel by mít takové znalosti, že by radil on vám a ne vy jemu.

To bych nedělal. Podle nařízení EU i podle české legislativy musí být cookie formou opt-in. Zatím se to přechodně porušuje (různé cookie bary často nastaví cookie dřív, než návštěvník odsouhlasí). Ale není to rozhodně dobrá rada pro nový projekt.
Souhlas s použitím cookies ovšem uživatel dává nastavením prohlížeče (https://www.uoou.cz/assets/File.ashx?id_org=200144&id_dokumenty=37240).
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 17. 03. 2020, 16:29:11
Pokud nastavíte https://www.php.net/manual/en/session.configuration.php#ini.session.auto-start na true tak bude session v PHP fungovat úplně automaticky.

To bych nedělal. Podle nařízení EU i podle české legislativy musí být cookie formou opt-in. Zatím se to přechodně porušuje (různé cookie bary často nastaví cookie dřív, než návštěvník odsouhlasí). Ale není to rozhodně dobrá rada pro nový projekt.

Při registraci a přihlášení musí uživatel tak jako tak nějaké své údaje předat a tedy musí být již GDPR ošetřené. Bez poskytnutí dat není možné službu vůbec poskytovat, je to nutná podmínka.

Ale ano, teoreticky bude lepší session nastartovat až dle potřeby, i třeba z hlediska výkonu apod. Takže pokud není session nastarovaná, tak ji nastartovat až při přihlášení, viz https://www.php.net/manual/en/function.session-status.php a https://www.php.net/manual/en/function.session-start.php
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 17. 03. 2020, 16:32:46
To bych nedělal. Podle nařízení EU i podle české legislativy musí být cookie formou opt-in. Zatím se to přechodně porušuje (různé cookie bary často nastaví cookie dřív, než návštěvník odsouhlasí). Ale není to rozhodně dobrá rada pro nový projekt.
Souhlas s použitím cookies ovšem uživatel dává nastavením prohlížeče (https://www.uoou.cz/assets/File.ashx?id_org=200144&id_dokumenty=37240).

Zajímavé, já to rovnou z https://www.uoou.cz/assets/File.ashx?id_org=200144&id_dokumenty=37240 ocituji:
Citace
Uživatel určuje v nastavení svého PC, resp. v nastavení prohlížeče, zda má prohlížeč umožnit webovské stránce ukládat cookies do koncového zařízení. Toto nastavení lze považovat za souhlas se zpracováním osobních údajů.Prohlížeč je nástrojem zprostředkování souhlasu. Souhlas však nemůže zhojit jiné nedostatky, resp. nezákonnosti zpracování osobních údajů.

Ale je tam napsáno „návrh“, tak nevím jak je to se závazností...
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 16:35:02
Souhlas s použitím cookies ovšem uživatel dává nastavením prohlížeče (https://www.uoou.cz/assets/File.ashx?id_org=200144&id_dokumenty=37240).

Poslal jste odkaz na návrh a jeho obsah je diskutovaný a diskutabilní a s nulovou právní hodnotou. V praxi mají prohlížeče cookies povoleny implicitně, nelze tedy hovořit o opt-in principu ani v přeneseném úkonu. Stále je to opt-out. Předpis má chránit uživatele a opt-in mechanismus je stanoven explicitně. Tedy, pokud máte jistotu, že to v prohlížeči zapnul ručně (opt-in), pak můžete přenést tento souhlas i na konkrétní situaci.

Pokud by tento návrh prošel legislativou, pak by nebylo co namítat, leč nyní nic takového nemáme. Zajímalo by mě, jak víc by měli v tom textu zdůraznit, že se nejedná o účinný dokument, než tím, že je tam jako kráva napsáno: "NÁVRH".
Název: Re:Bezpečná session v PHP
Přispěvatel: Tomas-T 17. 03. 2020, 16:55:51
Pokud se používá klasické session_id přes cookies u klienta, narazil jsem v minulosti na pokus převzít cizí aktivní session (ukrást a poslat její session_id).
Ošetřoval jsem to tak, že po úspěšném přihlášení a vytvoření session_id jsem zkombinoval session_id s IP adresou uživatele a uložil hash do databáze k uživateli - při každém přístupu pak hash z uvedených údajů znovu spočítal a kontroloval proti hodnotě v databázi - změna IP adresy uživatele pak znamená nový požadavek na přihlášení - vedlejší efekt je pak nefunkčnost přes Tor nebo jiné anonymizéry náhodně měnící IP adresu klienta.
Do kontrolního hashe lze také zahrnout (nebo použít místo IP adresy) otisk browseru použitého pro přihlášení (= inicializaci session).
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 17. 03. 2020, 17:21:38
Pokud se používá klasické session_id přes cookies u klienta, narazil jsem v minulosti na pokus převzít cizí aktivní session (ukrást a poslat její session_id).

Při použití https vám session session nikdo (snadno) neukradne.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 17:27:30
Při použití https vám session session nikdo (snadno) neukradne.

Co třeba podnikové proxy servery s vlastními certifikáty, které přebíjejí ty původní?
Co třeba antiviry, které dělají to samé?
Co třeba malware, který může taky to samé udělat?

Těch cest je mnoho, můžeme diskutovat o tom, jak moc pravděpodobné jsou.
Každopádně tento směr úvah už je o tom, že PHP sessions jsou vetché a že na chatrných základech se nedá už opravdová bezpečnost lehce vyřešit.

Podle mě jde přijmout PHP sessions tak, jak jsou i s jejich nevýhodami a nepočítat s tím, že to půjde jednoduše refactorovat do něčeho novějšího. Nebo to rovnou postavit lépe, když ty technologie existují.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 17. 03. 2020, 17:32:15
Poslal jste odkaz na návrh a jeho obsah je diskutovaný a diskutabilní a s nulovou právní hodnotou.
Jasně, návrh doporučení ÚOOÚ má nulovou právní váhu, zatímco vyjádření všeuměla amatéra Miroslava Šilhavého ne nezpochybnitelné. Nechci vám brát iluze, ale o porušení podmínek bude případně rozhodovat ÚOOÚ, ne vy.

V praxi mají prohlížeče cookies povoleny implicitně, nelze tedy hovořit o opt-in principu ani v přeneseném úkonu. Stále je to opt-out. Předpis má chránit uživatele a opt-in mechanismus je stanoven explicitně. Tedy, pokud máte jistotu, že to v prohlížeči zapnul ručně (opt-in), pak můžete přenést tento souhlas i na konkrétní situaci.
No jo, oni se vás na to asi na ÚOOÚ zapomněli zeptat.

Pokud by tento návrh prošel legislativou, pak by nebylo co namítat, leč nyní nic takového nemáme. Zajímalo by mě, jak víc by měli v tom textu zdůraznit, že se nejedná o účinný dokument, než tím, že je tam jako kráva napsáno: "NÁVRH".
Příště si zkuste radši najít informace o tom dokumentu a neřídit se jedním slovem. Ten návrh je odkazován zde: Názory a rozhodnutí Úřadu: Cookies a GDPR (https://www.uoou.cz/vismo/dokumenty2.asp?id_org=200144&id=29966&n=cookies-a-gdpr&p1=1099). Nic novějšího nebo závaznějšího od té doby ÚOOÚ nevydal. Ano, je to jen návrh doporučení, ale vzhledem k tomu, že je autorem toho doporučení ÚOOÚ, dá se předpokládat, že to vyjadřuje názor ÚOOÚ a bude se tímto názorem řídit. Rozhodně je milionkrát pravděpodobnější, že se ÚOOÚ bude řídit tímhle, než že se bude řídit vašimi představami.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 17. 03. 2020, 17:36:06
Pokud se používá klasické session_id přes cookies u klienta, narazil jsem v minulosti na pokus převzít cizí aktivní session (ukrást a poslat její session_id).
Ošetřoval jsem to tak, že po úspěšném přihlášení a vytvoření session_id jsem zkombinoval session_id s IP adresou uživatele a uložil hash do databáze k uživateli - při každém přístupu pak hash z uvedených údajů znovu spočítal a kontroloval proti hodnotě v databázi - změna IP adresy uživatele pak znamená nový požadavek na přihlášení - vedlejší efekt je pak nefunkčnost přes Tor nebo jiné anonymizéry náhodně měnící IP adresu klienta.
Do kontrolního hashe lze také zahrnout (nebo použít místo IP adresy) otisk browseru použitého pro přihlášení (= inicializaci session).
Proto je potřeba dbát na to, aby identifikátor session nikam neunikl. Úniku při přenosu brání šifrování (HTTPS, cookie musí mít nastaven příznak Secure), je potřeba přenášet jej výhradně v cookie (ne v URL, kde by mohl uniknout do referreru nebo být přečten skriptem), pro cookie je potřeba nastavit HttpOnly (aby ji nešlo přečíst skriptem).

Vázání session na IP adresu se silně nedoporučuje, IP adresa klienta se může měnit. A naopak útočník může být za NATem ve stejné síti, jako uživatel.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 17. 03. 2020, 18:03:00
Jasně, návrh doporučení ÚOOÚ má nulovou právní váhu, zatímco vyjádření všeuměla amatéra Miroslava Šilhavého ne nezpochybnitelné. Nechci vám brát iluze, ale o porušení podmínek bude případně rozhodovat ÚOOÚ, ne vy.

To se bavíte ale o postihu stran správního práva. Druhou částí je i civilní žaloba, ve které názor ÚOOÚ nemá naprosto žádnou váhu.

Názory a rozhodnutí Úřadu: Cookies a GDPR[/url]. Nic novějšího nebo závaznějšího od té doby ÚOOÚ nevydal. Ano, je to jen návrh doporučení, ale vzhledem k tomu, že je autorem toho doporučení ÚOOÚ, dá se předpokládat, že to vyjadřuje názor ÚOOÚ a bude se tímto názorem řídit. Rozhodně je milionkrát pravděpodobnější, že se ÚOOÚ bude řídit tímhle, než že se bude řídit vašimi představami.

Právěže je to jen ve fázi návrhu. ÚOOÚ ví, že takto zatím nemůže postupovat. Kdyby takto mohl postupovat, pak by stačilo aby vyhláškou stanovil svůj postup. Každý úřad může vyhláškou stanovit mírnější úřední postup (např. tak to někdy dělá finanční správa). V tomto případě to udělat nemohou, protože by takový postup byl sice mírnější k provozovatelům webů, ale na druhé straně by tím zasahoval do zákonem daných práv uživatelů. Proto je to ve fázi návrhu a právě tato fáze vyjadřuje ten kontrast stavu jaký je a musí respektovat a stavu, jaký by navrhovali.

V Evropě je trend chránit soukromí. Nastavit cookie v 99 % případů není nezbytné a už vůbec ne u nového systému. Je to jen pohodlné a lacinější na vývoj. Tomu chce přesně EU zabránit. Myslím, že EU se neposadí na zadek z ÚOOÚ.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 17. 03. 2020, 18:33:50
Druhou částí je i civilní žaloba, ve které názor ÚOOÚ nemá naprosto žádnou váhu.
Už zase melete z cesty. Civilní žaloba na co?

Právěže je to jen ve fázi návrhu. ÚOOÚ ví, že takto zatím nemůže postupovat. Kdyby takto mohl postupovat, pak by stačilo aby vyhláškou stanovil svůj postup. Každý úřad může vyhláškou stanovit mírnější úřední postup (např. tak to někdy dělá finanční správa). V tomto případě to udělat nemohou, protože by takový postup byl sice mírnější k provozovatelům webů, ale na druhé straně by tím zasahoval do zákonem daných práv uživatelů. Proto je to ve fázi návrhu a právě tato fáze vyjadřuje ten kontrast stavu jaký je a musí respektovat a stavu, jaký by navrhovali.
Ale houby. Přečtěte si tu webovou stránku, ze které je to odkazované. Je to plánované doporučení ÚOOÚ pro provozovatele webů, takže to nikdy nemělo být nic legislativního. A návrh je to proto, že to ÚOOÚ chtěl konzultovat s provozovateli webů.

V Evropě je trend chránit soukromí. Nastavit cookie v 99 % případů není nezbytné a už vůbec ne u nového systému. Je to jen pohodlné a lacinější na vývoj. Tomu chce přesně EU zabránit. Myslím, že EU se neposadí na zadek z ÚOOÚ.
Jenže cookies se soukromým nijak nesouvisí. S ochranou soukromí může souviset obsah, který se do cookie ukládá. A jestli nějaké informace uložíte do cookie nebo jiným způsobem, to je z hlediska ochrany osobních údajů mimo. K čemu by bylo dobré ukládat to komplikovanějším způsobem, když to na ochranu osobních údajů nebude mít žádný vliv? EU rozhodně nikoho nechce nutit něco vyvíjet zbytečně složitě, ani nechce web zaplevelit zbytečnými cookie lištami (to je akce Google). EU chce chránit soukromí – a to nijak nesouvisí s technologií cookies, ani s žádnou jinou technologií. Souvisí to jenom s tím, jaké osobní údaje se zpracovávají.
Název: Re:Bezpečná session v PHP
Přispěvatel: user398 18. 03. 2020, 11:18:37
S tymi cookies to nieje tak ze zakladne first-party cookies (sem patri aj session cookie) potrebne na beh webu su v GDPR povolene a netreba pytat suhlas. Suhlas je potrebny na statisticke, reklamne, 3rd party cookies a podobne.
Název: Re:Bezpečná session v PHP
Přispěvatel: user398 18. 03. 2020, 11:22:40
Aj na UOOU to pisu:

Pro cookies nezbytně nutné pro zajištění provozu webových stránek a internetových služeb není nutno získat souhlas uživatele (interpretační vodítka k určení takových cookiesposkytuje WP194).
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 18. 03. 2020, 12:58:41
Pro cookies nezbytně nutné pro zajištění provozu webových stránek a internetových služeb není nutno získat souhlas uživatele (interpretační vodítka k určení takových cookiesposkytuje WP194).

A nastavení session je nutné k zajištění provozu nepřihlášeného uživatele? Podle mě ani omylem. Musela by to být nějaká nevyhnutelná funkce, kterou nejde zajistit jinak.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 18. 03. 2020, 13:17:15
A nastavení session je nutné k zajištění provozu nepřihlášeného uživatele? Podle mě ani omylem. Musela by to být nějaká nevyhnutelná funkce, kterou nejde zajistit jinak.
No jo, podle vás. Mám pro vás několik tipů. Např. v e-shopech existuje taková věc, která se nazývá nákupní košík. Jistě, když se chcete e-shopem jen tak procházet a kochat se, co je v nabídce, nákupní košík není potřeba. Nicméně provozovatel e-shopu potřebuje, aby v něm někdo nakupoval, takže nákupní košík potřebuje. Nebo třeba servery, kde jsou články a pod nimi komentáře. Je dobré vidět, které komentáře už jsem četl a které ještě ne. Nutit kvůli tomu uživatele, aby se přihlásil, není úplně vhodné. Naopak proti smyslu GDPR je vnucovat lidem zbytečné přihlášení, když se to dá řešit i bez něj. Dál třeba vyhledávače spojení. Pro uložení často hledaných spojení nepotřebuju být přihlášen, právě naopak, nechci si kvůli tomu zakládat nějaký účet.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 18. 03. 2020, 13:23:42
No jo, podle vás. Mám pro vás několik tipů. Např. v e-shopech existuje taková věc, která se nazývá nákupní košík. Jistě, když se chcete e-shopem jen tak procházet a kochat se, co je v nabídce, nákupní košík není potřeba. Nicméně provozovatel e-shopu potřebuje, aby v něm někdo nakupoval, takže nákupní košík potřebuje. Nebo třeba servery, kde jsou články a pod nimi komentáře. Je dobré vidět, které komentáře už jsem četl a které ještě ne. Nutit kvůli tomu uživatele, aby se přihlásil, není úplně vhodné. Naopak proti smyslu GDPR je vnucovat lidem zbytečné přihlášení, když se to dá řešit i bez něj. Dál třeba vyhledávače spojení. Pro uložení často hledaných spojení nepotřebuju být přihlášen, právě naopak, nechci si kvůli tomu zakládat nějaký účet.

Ano, na to jsou nutná cookies. Ale jak to vysvětluje naši diskusi o (ne)vhodnosti session autostart? Pořád nějak nevidím důvod, proč by měl existovat autostart session a nastavení cookie, dokud neodkliknu souhlas a dokud nechci využívat žádnou takovou funkci? Chápu plně, že je jednodušší tam prdnout autostart, než přemýšlet, kdy ji můžu nastavit - ale to už je mimo rámec toho, co řešíme.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 18. 03. 2020, 13:46:47
Pořád nějak nevidím důvod, proč by měl existovat autostart session
Protože je to nejjednodušší a nelze v tom udělat chybu.

nastavení cookie, dokud neodkliknu souhlas
Souhlas s cookie se nastavuje v prohlížeči. Pokud jsou vypnuté, prohlížeč cookie neuloží a na serveru tudíž nemusíte řešit jejich neukládání. Na serveru musíte akorát vyřešit, zda uživateli s vypnutými cookies poskytnete nějakou náhradní metodu. Začátečníkovi bych to rozhodně nedoporučoval, je to podstatně náročnější na zabezpečení.

Souhlas uživatele odkliknutím na webové stránce vyžadují akorát obchodní podmínky Googlu, třeba když máte na stránkách AdWords nebo používáte Google Analytics. Ale ani Google nepředpokládá, že byste se těmi podmínkami řídil, protože nikde v API nevystavuje funkci, kterou byste jim sdělil, že uživatel souhlas dal. A všude předpokládají, že jejich kód vložíte do stránky rovnou, ne až po získání souhlasu.

Chápu plně, že je jednodušší tam prdnout autostart, než přemýšlet, kdy ji můžu nastavit - ale to už je mimo rámec toho, co řešíme.
Jenže to, co vy řešíte, je zase daleko mimo rámec dotazu.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 18. 03. 2020, 13:54:43
Protože je to nejjednodušší a nelze v tom udělat chybu.

A to je právě ono. Ta směrnice jasně říká o opt-in mechanismu, tedy o explicitním vyjádření souhlasu. Nainstalovaný prohlížeč, který má implicitně zapnutá cookies nemůže zakládat na předpoklad souhlasu. Proto taky je taky ten návrh zazděný. Podle Vašeho výkladu by totiž to ustanovení směrnice úplně ztratilo smysl, protože každý by mohl zcela volně cookies používat bez souhlasu. (To rovnou mohli do směrnice napsat: kdo nechce cookies, nechť si je vypne v prohlížeči).
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 18. 03. 2020, 14:56:22
A to je právě ono. Ta směrnice jasně říká o opt-in mechanismu, tedy o explicitním vyjádření souhlasu.
To už jsem vám vysvětlil včera.

To rovnou mohli do směrnice napsat: kdo nechce cookies, nechť si je vypne v prohlížeči
Což by bylo vůbec nejlepší, protože je to jediné, co dává smysl. Uživatel si to jednou nakonfiguruje, jak chce, a provozovatel webu to nemůže nijak obejít. Ta současná podoba směrnice je evidentně nejasná, když to kde kdo používá jako strašáka.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 18. 03. 2020, 15:01:20
Což by bylo vůbec nejlepší, protože je to jediné, co dává smysl. Uživatel si to jednou nakonfiguruje, jak chce, a provozovatel webu to nemůže nijak obejít. Ta současná podoba směrnice je evidentně nejasná, když to kde kdo používá jako strašáka.

Ta směrnice je naopak zcela jasná. Z opt-out mechanismu, který byl povolený u nás přechodnou dobu, je jasně požadovaný opt-in mechanismus. Je z toho zcela patrné, jaká je vůle zákonodárce a je to i logické vzhledem k zájmům uživatelů.

Návrh ÚOOÚ je zcestný, protože jde zcela proti smyslu explicitního ustanovení směrnice i proti jejímu vývoji v čase (anarchie => opt-out => opt-in => [návrh znovu anarchie]). Proto taky ten návrh už dlouho leží u ledu. Nedá se očekávat, že návrh ÚOOÚ směrem k provozovatelům zvrátí zákon.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 18. 03. 2020, 15:31:43
Ta směrnice je naopak zcela jasná. Z opt-out mechanismu, který byl povolený u nás přechodnou dobu, je jasně požadovaný opt-in mechanismus. Je z toho zcela patrné, jaká je vůle zákonodárce a je to i logické vzhledem k zájmům uživatelů.

Návrh ÚOOÚ je zcestný, protože jde zcela proti smyslu explicitního ustanovení směrnice i proti jejímu vývoji v čase (anarchie => opt-out => opt-in => [návrh znovu anarchie]). Proto taky ten návrh už dlouho leží u ledu. Nedá se očekávat, že návrh ÚOOÚ směrem k provozovatelům zvrátí zákon.
To si nepřipadáte hloupě? Nařízení si nepřečtete, názor ÚOOÚ si nepřečtete, ale dál trváte na tom, že jedině vaše dojmy jsou správné.

Vzhledem k tomu, že všude potkávám nejrůznější nesmyslné cookie lišty, které nevyhovují ani GDPR, ani obchodním podmínkám Googlu, ani ničemu jinému, evidentně to nařízení tak jasné není.

Zájem uživatelů určitě není na každém druhém webu skrývat při každé návštěvě nějakou nesmyslnou lištu, jejíž zobrazení či nezobrazení nemá žádný vliv na funkčnost webu. Pokud nějaký uživatel má potřebu nějak řešit cookies, ať to řeší ve svém prohlížeči, To je jediné místo, kde se to vyřešit dá.
Název: Re:Bezpečná session v PHP
Přispěvatel: Miroslav Šilhavý 18. 03. 2020, 15:45:15
Nařízení si nepřečtete, názor ÚOOÚ si nepřečtete, ale dál trváte na tom, že jedině vaše dojmy jsou správné.

Četl jsem vše zmiňované, včetně uznávané právní literatury k tématu.

Vzhledem k tomu, že všude potkávám nejrůznější nesmyslné cookie lišty, které nevyhovují ani GDPR, ani obchodním podmínkám Googlu, ani ničemu jinému, evidentně to nařízení tak jasné není.

Zájem uživatelů určitě není na každém druhém webu skrývat při každé návštěvě nějakou nesmyslnou lištu, jejíž zobrazení či nezobrazení nemá žádný vliv na funkčnost webu. Pokud nějaký uživatel má potřebu nějak řešit cookies, ať to řeší ve svém prohlížeči, To je jediné místo, kde se to vyřešit dá.

Ano, s tím souhlasím, že se většina firem snaží nařízení obejít, občůrat opt-out lištami, které neplní účel. Není však důležité, že se masy rozhodly na nařízení prdět, ale to, jestli to lze splnit či nikoliv. Já jsem přesvědčený, že lze, jen to bude vyžadovat změny. Tedy dokud není funkce cookie nezbytná, nesmí ji web nastavit. Pokud je nezbytná, smí. A smí ve chvíli, kdy o to člověk požádá opt-in způsobem (např. souhlasem při zakládání účtu a následně loginem).

Celá naše diskuse se točí kolem toho, že se Vám zdá směrnice nepohodlná a že vyžaduje změnu systémů i přemýšlení při plánování. Až bude chtít zákonodárce, aby si to uživatel ovládal v prohlížeči, vypustí to z normy. Do té doby to tam je.
Název: Re:Bezpečná session v PHP
Přispěvatel: Filip Jirsák 18. 03. 2020, 16:24:05
Celá naše diskuse se točí kolem toho, že se Vám zdá směrnice nepohodlná a že vyžaduje změnu systémů i přemýšlení při plánování.
Ne, celá naše diskuse se točí kolem toho, že vy jste si něco vymyslel, a tvrdíte, že je to v nějaké směrnici. Jenže v nařízení (sic!) GDPR nic takového není.

Až bude chtít zákonodárce, aby si to uživatel ovládal v prohlížeči, vypustí to z normy. Do té doby to tam je.
Jenže zákonodárce nerozhoduje o tom, jak má být něco technicky realizováno. Zákonodárce určuje cíl – a je mu jedno, jestli to bude implementováno v prohlížeči nebo na serveru. Splňuje konfigurace v prohlížeči požadavky GDPR? Splňuje. Tak proč by to samé mělo být implementováno ještě někde jinde?
Název: Re:Bezpečná session v PHP
Přispěvatel: Ondrej Nemecek 18. 03. 2020, 19:43:50
Pánové, jste stále u tématu bezpečné session?  ;)