Příspěvky

481

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

« kdy: 18. 03. 2020, 19:43:50 »

Pánové, jste stále u tématu bezpečné session? 

482

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

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

483

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

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

Zajímavé, já to rovnou z https://www.uoou.cz/assets/File.ashx?id_org=200144&id_dokumenty=37240 ocituji:

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

484

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

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

485

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

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

486

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

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

487

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

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

• pochopit princip session a její použití v PHP
• pochopit význam vynuceného https a zasílání dat metodou POST
• pochopit význam soleného hashování při ukládání hesla do databáze
• pochopit a zamezit sql injection

Teprve při zvládnutí tohoto má podle mě cenu zvednou laťku a nasazovat javascript.

488

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

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

489

Hardware / Re:Sluchátka s mikrofonem přes Bluetooth

« kdy: 15. 03. 2020, 15:28:07 »

Toto by mě také zajímalo.

490

Vývoj / Re:Doporučte programovací jazyk pro Windows

« kdy: 13. 03. 2020, 14:35:41 »

Kod neni asset, ale liability.
Tzn cim mene ho je tim lepe pro vyvojare. To ze mi IDE neco vygeneruje... je pro me spatne, protoze mi to pridava dalsi zodpovednost navic za neco co sem nenapsal. Jaky je prinos?
Pokud to zvladne stroj(IDE) vygenerovat kdyz to pisu, tak proc to radsi neudela az kdyz kompiluju?

Pro priklady a srovnani ukecanosti se muzete podivat na http://rosettacode.org/wiki/Rosetta_Code.
Stejny problem reseny v ruznych jazycich.

Kratší neznamená automaticky lepší - příliš kryptický kód představuje taky problém. Navíc je to individuální, čím komplexnější mindset programátor obsáhl, tím lépe vidí co se děje na pozadí a tím pádem rozumí kratšímu kódu. Naopak začátečník potřebuje explicitnější popis, co se děje. Dobrý příklad je Scala, která umí odvodit kde co a cestu programátora k pochopení shrnul Odersky ve svých Scala levels  https://www.scala-lang.org/old/node/8610

Takže debata postrádá smysl, cenu má jen vysvětlit best-practices a common-practices jednotlivých jazyků a ať si programátor vybere dle osobních preferencí

491

Vývoj / Re:Doporučte programovací jazyk pro Windows

« kdy: 11. 03. 2020, 14:11:29 »

Protokoly ve Smalltalku neřeší vcelku nic, je to jen kategorizace selektorů (metod), nic nevynucují (což je trošku škoda).

Dynamic dispatch má i Java, Python, prakticky každý OOP jazyk, to není žádná specialita Smalltalku.

Žil jsem v přesvědčení že protokoly můžou ve Smalltalku implementaci vyžadovat. Protože by mi přišlo ideální mít možnost volné vazby a volitelně vynucené implementace.

Slovo protokol jsem viděl ve Smalltalku používat ve dvou významech, jestli se pamatuju správně:

 - Neformálně např. při popisování (mluvení, čmárání na papír) nějaké objektové hierarchie, tj. "Objekt který se zde předá musí podporovat protokol Foo, tj. implementovat metody #foo a #fooAt:, které se nějak chovají", tedy něco významově podobného kontraktu.
 - Kategorie metod nějakého objektu (Accessors, testing, painting, ...), ta už je u každé metody uvedená, něco trochu podobného jako #region v C#, slouží jen pro zpřehlednění.

Kažopádně se nikde nic nevynucuje..

Koukám na to a skutečně máte pravdu. Divil bych se ale, kdyby nikdo do Smalltalku nezkusil  vyžadování a kontrolu kontraktů přidat.

492

Vývoj / Re:Doporučte programovací jazyk pro Windows

« kdy: 11. 03. 2020, 14:08:30 »

Podívej Stando, to jsou bláboly. Smál jsi se pěknému přehlednému a srozumitelnému  Python programu ve věci, která ani není nativní vlastností toho jazyka. Můžeš předvést jak si s tím poradí Java, u které to je nativní vlastnost, tudíž by to měla zvládnout lépe nebo aspoň stejně. Ano, Java je hnusný těžkopádný jazyk, takže to nezvládne, to víme oba, teď jde jenom o to, jestli to přiznáš nebo ne. Čím víc to budeš rozpatlávat abys to zakamufloval, tím víc to bude smrdět. Takže hoď sem Java implementaci kraťoučkého Python programu, co jsi sem sám napastoval a nebo jsi porazil sám sebe svými vlastními hloupými ukázkami. :-)

Jak to?? Podle mě ten java kód už poslal. Ale férovější by bylo popsat, co ten Python kód přesně dělá a pak řešit, zda a jak se to dá realizovat v jiném jazyku.

Neposlal, snažil se jen vysvětlovat, jak by to napsal, kdyby to napsal. Ten Python kód sem dal on, tak snad ví, co dělá. Dal to sem navíc s tvrzením, že java to umí přehledněji, tak se může předvést :-).

A co je podle Vás tedy tohle? https://forum.root.cz/index.php?topic=22582.msg326312#msg326312

493

Vývoj / Re:Doporučte programovací jazyk pro Windows

« kdy: 10. 03. 2020, 20:30:29 »

Proto má třeba Smalltalk dynamic dispatch a současně protokoly. Což řeší oba požadavky.

Protokoly ve Smalltalku neřeší vcelku nic, je to jen kategorizace selektorů (metod), nic nevynucují (což je trošku škoda).

Dynamic dispatch má i Java, Python, prakticky každý OOP jazyk, to není žádná specialita Smalltalku.

Žil jsem v přesvědčení že protokoly můžou ve Smalltalku implementaci vyžadovat. Protože by mi přišlo ideální mít možnost volné vazby a volitelně vynucené implementace.

494

Vývoj / Re:Doporučte programovací jazyk pro Windows

« kdy: 10. 03. 2020, 19:09:23 »

Podívej Stando, to jsou bláboly. Smál jsi se pěknému přehlednému a srozumitelnému  Python programu ve věci, která ani není nativní vlastností toho jazyka. Můžeš předvést jak si s tím poradí Java, u které to je nativní vlastnost, tudíž by to měla zvládnout lépe nebo aspoň stejně. Ano, Java je hnusný těžkopádný jazyk, takže to nezvládne, to víme oba, teď jde jenom o to, jestli to přiznáš nebo ne. Čím víc to budeš rozpatlávat abys to zakamufloval, tím víc to bude smrdět. Takže hoď sem Java implementaci kraťoučkého Python programu, co jsi sem sám napastoval a nebo jsi porazil sám sebe svými vlastními hloupými ukázkami. :-)

Jak to?? Podle mě ten java kód už poslal. Ale férovější by bylo popsat, co ten Python kód přesně dělá a pak řešit, zda a jak se to dá realizovat v jiném jazyku.

495

Vývoj / Re:Doporučte programovací jazyk pro Windows

« kdy: 10. 03. 2020, 19:07:47 »

No a co? Způsob jak se technologicky řeší to a ono v daném jazyce je podružné. Z toho, že Java nepotřebuje dekorátory či knihovny (protože si to tahá přímo "v základu" = v přibalené knihovně) na určité věci, narozdíl od Pythonu je jen ukázka dvou různých řešení téhož a nevypovídá to nic o tom, že automaticky řešení v Javě je lepší, jak to tady nastavujete v téhle diskuzi manipulativně vy.

No ona si to java netahá v přibalené knihovně, je to vlastnost jazyka jako takového.

Samozřejmě o charakteru jazyka hodně vypovídá, co je zahrnuto do jazyka, co do standardní knihovny a co je ponecháno na externích nástrojích. Nutně to ale neznamená, že je něco lepší než druhé.

Ano, plny souhlas.
Ze je neco zadratovane v jazyce nebo stdlib este neznamena, ze je to dobre.
Treba legacy Java logging, nebo stary zadratovany JAX-WS ve spoupraci s pribalenym wsimport, co podporuje nahodne vybrane featury WS-SOAP standardu - je na streleni se do hlavy. A tak kazdy mavenem bunluje SJLF a Apache CXF.

Kdzy se vratime k puvodnimu examplu, tady je vide rozdil filosofie Python vs. Java asi nejlip.

Kód: [Vybrat]

@singledispatch
def render(s, **kwargs):
  print('Rendering an unknown type')

@render.register(S_Block)
def _(s, **kwargs):
  print('Rendering an S_Block')

@render.register(S_Empty)
def _(s, **kwargs):
  print('Rendering an S_Empty')

Potom indicky spoluprqcovnik vezme nas kod jako knihovnu, prida si novy typ S_Vindaloo, a tak nejak zapomene maimplementovat vsechny potrebne metody ktere ja v ramci ducktypingu ocekavam, proste uplne chybi a tento se zavola vzdy v utery a dubnu

Holy python bez typehintingu: program rok bezi a pak cely zbuchne v utery v dubnu

Python s @singledispatch" program rok bezi a pak v utery v dubnu vypise hlasku 'Rendering an unknown type' pricemz neprovede ocekavane. Indicky kolega musi hrabat do meho kodu, aby zacal podporovat S_Vindaloo.

Java (C#, C++): vubec to nejde zkompilovat, coz indickeho kolegu donuti, aby S_Vindaloo splnovalo potrebne interface, pak vsecko funguje.

Slozitejsi program, kde kooperuje vic lidi + dynamicke typovani => pain.

Proto má třeba Smalltalk dynamic dispatch a současně protokoly. Což řeší oba požadavky.