reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 2 3 [4] 5 6 ... 245
46
Vývoj / Re:Java KeyStore
« kdy: 17. 03. 2020, 18:01:19 »
Klíč na certifikát nezkonvertujete. Certifikát je veřejný klíč plus další údaje to celé podepsané. JKS ale může obsahovat i klíče (bez certifikátu).

Truststore slouží k uložení důvěryhodných certifikátů (ne klíčů).
Omlouvám se, tohle jsem napsal špatně. Trustore obsahuje to, čemu se má důvěřovat – tedy buď certifikát nebo veřejný klíč. Neobsahuje privátní klíč.

Ta vaše aplikace je SFTP klient? Pak by v trustore měl být veřejný klíč serveru. Ale je mi to trochu divné. Klasické OpenSSH ale místo uložení celého klíče používá jen jeho otisk (to je to, co je uložené v souboru .ssh/known_hosts). Co přesně je to za aplikaci?

47
Vývoj / Re:Java KeyStore
« kdy: 17. 03. 2020, 17:46:37 »
Truststore slouží k uložení důvěryhodných certifikátů (ne klíčů). Takže privátní klíče z .ppk to nebudou. Ovšem v jakém formátu to truststore má být, to z toho jasné není – může to být JKS (může obsahovat i jen důvěryhodné certifikáty, bez klíčů), ale klidně to může být i DER certifikát v binárním kódování nebo v BASE64. Novější Java aplikace už si obvykle umí poradit i s těmito formáty.

48
Vývoj / Re:Bezpečná session v PHP
« kdy: 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.

49
Vývoj / Re:Bezpečná session v PHP
« kdy: 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. 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.

50
Vývoj / Re:Java KeyStore
« kdy: 17. 03. 2020, 17:20:30 »
Je to úložiště certifikátů a privátních klíčů. Neukládají se do toho žádné soubory, jenom certifikáty, veřejné klíče a privátní klíče. Heslo chránící Java Keystore je určené jenom pro ověření integrity dat, k obsahu se ale dostanete i bez něj. Privátní klíče v úložišti jsou ale chráněné svým vlastním heslem. Často se to používá tak, že heslo pro keystore i heslo pro privátní klíče je to stejné, software se vás pak ani neptá na heslo znova.

.ppk je pokud vím formát, který používá Putty. Pokud z něj vyextrahujete klíče, můžete je uložit i do Java KeyStore. Ale proč byste to dělal? Putty s formátem JKS pracovat neumí.

51
Vývoj / Re:Bezpečná session v PHP
« kdy: 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.

52
Vývoj / Re:Bezpečná session v PHP
« kdy: 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é).

53
Vývoj / Re:Bezpečná session v PHP
« kdy: 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í.

54
Vývoj / Re:Bezpečná session v PHP
« kdy: 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).

55
Vývoj / Re:bezpečná session v php
« kdy: 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í.

56
Vývoj / Re:Python - pejsek a kocicka varili dort
« kdy: 15. 03. 2020, 10:28:54 »
Tohle vam zarve chybu, vy totiz nemuzete v Pyjthonu pouzit jako atribut rezervovane klicove slovo!!! Takze vam z nejakeho API prijde JSON obsahujici klicove slovo, a vy proste mate SMULU a stejne si na to @dataclass vyrobit NEMUZETE!
Zatímco v Javě také nemůžete jako název atributu (fieldu, metody) použít rezervované nebo klíčové slovo.

Pro tenhle JSON

Kód: [Vybrat]
{
  'for': 'you'
}

si také nemůžete vyrobit třídu

Kód: [Vybrat]
public class TargetPerson {
  private String for;

  public String getFor() {
    return for;
  }

  public void setFor(String for) {
    this.for = for;
  }
}

Také tam budete muset mít nějaké mapování, buď mezi JSONem a názvem property, nebo mezi názvem property a názvem fieldu (tedy přejmenovat getter a setter).

Řekl bych, že tentokrát jste cíl minul o pořádný kus…

57
Sítě / Re:Mikrotik - blokuje odchozí 1194
« kdy: 14. 03. 2020, 13:04:49 »
TLS error neznamená, že se nedaří navázat spojení, ale je to chyba při šifrování komunikace – nedůvěryhodný certifikát, obě strany se nedomluví na podporovaných protokolech či algoritmech apod.

58
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 13. 03. 2020, 19:05:56 »
Kratsi ale taky neznamena "kryptictejsi". Kod by mel vzdycky byt dobre citelny a prodluzovani podle me nevede k lepsi citelnosti.
Ono to platí na obě strany. Je nějaká optimální délka kódu, kdy je nejčitelnější, (navíc je různá pro různé vývojáře a v různých kontextech). A když tenhle kód začnete zkracovat nebo prodlužovat, čitelnost bude klesat.

Takze pri praci v tymu maji i zkuseni vyvojari psat "rozbredly" kod? Aby to po nich novacci precetli? A jak se potom z novacku stanou seniori?
Ne rozbředlý, ale čitelný. To už se snad v oboru ví minimálně dvacet let, že je potřeba psát čitelný kód, aby to přečetli i nováčci i senioři, kteří zrovna nejsou ve formě, i senioři, kteří to po sobě čtou po půl roce. Z nováčků se stanou senioři právě tak, že budou číst čitelný kód, budou ho chápat a naučí se ho postupně psát také. Je to jeden z rozdílů mezi kódem nováčka a zkušeného vývojáře, že nováček píše kód, kterému je těžké porozumět, zatímco zkušený vývojář píše kód, který snadno pochopí každý. Pokud si myslíte, že se senior vyznačuje tím, že jeho kód nikdo nepřečte, pak jste si asi spletl století.

59
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 13. 03. 2020, 10:23:51 »
Proc mi vysvetlujes, co vim?
Pokud to víte, tak proč píšete, jako byste to nevěděl?

Samozrejme, ze ukecany kod je podstatne vetsi problem pro toho, kdo ho musi cist, protoze ma horsi pomer signal/sum.
Jenže on to není šum. To jste jenom absolutně nepochopil, jak funguje přenos informací. Podívejte se na přirozené jazyky. Ty v sobě také mají spoustu redundance, kterou vy mylně nazýváte šumem. Jenže to není jejich chyba, je to výhoda. Podívejte se na historii přenosových kódování – také byla nejprve snaha to vylepšit a přenášet co nejúsporněji jedničky, ale nuly, a pak se ukázalo, že to nefunguje a přidáním samoopravných kódů se komunikace sice nafoukne, ale ve výsledku je efektivnější.

Stejně jako u přirozeného jazyka i u těch programovacích platí, že jejich efektivita při čtení není dána tím, aby byl program zakódován do co nejmenšího počtu bitů (to bychom psali ve strojovém kódu), ale aby byl co nejsrozumitelnější. Opakování i dlouhé popisné názvy přispívají srozumitelnosti.

60
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 13. 03. 2020, 08:28:10 »
Jako spravnemu clenu sekty Ti ani neprijde zbytecne porad dokola psat MyjTyp promenna = new MujTyp(). K dokonalosti uz chybi to jeste zduraznit v komentari (ano, fakt je to MujTyp) a udelat pro to podporu v IDE, aby to tam doplnovalo samo.
Aha, o věci nic nevíte, takže vám nezbývá, než „argumentovat“ ad hominem.

Pokud někomu přijde zbytečné v Javě při deklaraci lokální proměnné uvádět typ, když je stejný, jako typ odvozený z inicializace, může použít klíčové slovo var.

Navíc předpokládám, že jste nechtěl napsat „psát“, ale „číst“ – protože tu deklaraci typu programátor opravdu nepíše, ani když chce typ deklarovat, napíše to za něj IDE.

Stran: 1 2 3 [4] 5 6 ... 245

reklama