Příspěvky

781

Vývoj / Re:Bezpečná session v PHP

« kdy: 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.

782

Vývoj / Re:Bezpečná session v PHP

« kdy: 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).

783

Vývoj / Re:Bezpečná session v PHP

« kdy: 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.

784

Vývoj / Re:Bezpečná session v PHP

« kdy: 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.

785

Distribuce / Re:ZFS a Linux

« kdy: 18. 03. 2020, 12:28:49 »

Je to slepá ulička. Sun zveřejnil implementaci ZFS pod licencí, která je nekompatibilní s linuxovým jádrem a ani Oracle (který mezitím Sun koupil a má potřebná práva) ani v nejmenším nenaznačil, že by se chystal svůj postoj změnit.

Upřesním:

• Ubuntu ZFS distribuuje v sobě, ZFS je kompatibilní s jádrem, pochybnosti jsou pouze v tom, jestli lze zdrojový kód ZFS začlenit přímo do zdrojového kódu jádra, nebo jestli se kód ZFS musí distribuovat odděleně. Není to na překážku ve využívání, jen je to méně pohodlné pro maintainery distribucí (a v některých případech i pro programátory).
• Licence podle mnohých kompatibilní je, protože CDDL dává větší práva užití, než GPL. Ortodoxní vykladači GPL však nechtějí začlenění do zdrojových kódů povolit, protože by pak část kernelu Linuxu měla přísnější GPL a část kódu ZFS by spadala pod volnější CDDL. Linux maintaineři by si přáli při začlenění licenci změnit na GPL, což samozřejmě možné není - ta část kódu by musela zůstat pod CDDL. Oracle necítí potřebu se k tomu vyjadřovat, protože to je vnitřní mentální boj v rámci GPL komunity; z jejich strany je licence volná prakticky maximálně.

786

Server / Re:Backup serveru

« kdy: 18. 03. 2020, 08:56:06 »

Já to dělám tak, že zálohuji celý server, ale pomocí --exclude vynechávám ty části, které zálohovat nechci. Tento způsob mi přijde šťastnější, protože když na disku přibude nový adresář, spadne automaticky do zálohy. Opačným postupem musíte pravidelně hlídat, že nezapomínáte zálohovat něco nového důležitého.

Přikládám své nastavení, ale je určené pro FreeBSD - tam není potřeba vůbec zálohovat base system, protože ten je přímo z distribuce (ne z balíčků) a vždy se dá obyčejným tarem rozbalit přímo od nich.

Kód: [Vybrat]

borg create \
    --verbose \
    --filter AME \
    --list \
    --stats \
    --show-rc \
    --compression zstd,5 \
    --exclude-caches \
    --exclude "/bin/*" \
    --exclude "/boot/*" \
    --exclude "/dev/*" \
    --exclude "/lib/*" \
    --exclude "/libexec/*" \
    --exclude "/rescue/*" \
    --exclude "/root/.cache/*" \
    --exclude "/sbin/*" \
    --exclude "/tmp/*" \
    --exclude "/usr/bin/*" \
    --exclude "/usr/home/*/.cache/*" \
    --exclude "/usr/home/*/.composer/*" \
    --exclude "/usr/home/*/.npm/*" \
    --exclude "/usr/home/*/www/*/temp/*" \
    --exclude "/usr/include/*" \
    --exclude "/usr/lib/*" \
    --exclude "/usr/libdata/*" \
    --exclude "/usr/libexec/*" \
    --exclude "/usr/local/var/php-session/*/*" \
    --exclude "/usr/obj/*" \
    --exclude "/usr/ports/*" \
    --exclude "/usr/sbin/*" \
    --exclude "/usr/share/*" \
    --exclude "/usr/src/*" \
    --exclude "/usr/tests/*" \
    --exclude "/var/cache/*" \
    --exclude "/var/crash/*" \
    --exclude "/var/db/etcupdate/*" \
    --exclude "/var/db/freebsd-update/*" \
    --exclude "/var/db/portsnap/*" \
    --exclude "/var/ports/*" \
    --exclude "/var/tmp/*" \
    \
    ::"{hostname} [REGULAR] {now}" \

787

Vývoj / Re:Bezpečná session v PHP

« kdy: 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Ú.

788

Vývoj / Re:Bezpečná session v PHP

« kdy: 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í.

789

Vývoj / Re:Bezpečná session v PHP

« kdy: 17. 03. 2020, 16:35:02 »

Souhlas s použitím cookies ovšem uživatel dává nastavením prohlížeče.

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

790

Vývoj / Re:Bezpečná session v PHP

« kdy: 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.

791

Vývoj / Re:Bezpečná session v PHP

« kdy: 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.

792

Vývoj / Re:Bezpečná session v PHP

« kdy: 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.

793

Vývoj / Re:Bezpečná session v PHP

« kdy: 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ě!

794

Vývoj / Re:Bezpečná session v PHP

« kdy: 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áš.

795

Vývoj / Re:Bezpečná session v PHP

« kdy: 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