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 ... 158 159 [160] 161 162 ... 375
2386
Sítě / Re:NAT 1:1
« kdy: 27. 07. 2019, 12:44:22 »
Když máte veřejnou IPv4 adresu, má ji přidělenu přímo vnější rozhraní vašeho routeru. Takže po drátě (nebo vzduchem) k tomu routeru doputuje paket, který má jako adresu cíle uvedenou přímo tu veřejnou adresu. Pokud máte NAT 1:1, vnější rozhraní vašeho routeru má nějakou IP adresu z privátních rozsahů a někde u poskytovatele je NAT, který příchozí pakety s tou „vaší“ veřejnou IP adresou změní – adresu cíle nastaví na tu privátní adresu vašeho routeru (a u odchozích paketů zase opačně).

Rozdíl je tedy v tom, že u NATu musí nějaké zařízení měnit procházející pakety, a musí vědět, jak je má změnit. U standardních hlaviček IP paketů to není problém, ale pokud by se ta IP adresa vyskytovala i někde uvnitř komunikace a NAT té komunikaci nerozuměl, IP adresu nenahradí – a nejspíš něco nebude fungovat. Rozdíl je také v tom, že když se nepoužije NAT, router (a aplikace na něm) znají tu veřejnou IP adresu, zatímco když se použije NAT, znají jenom tu privátní a nevědí, že z internetu je ten router dostupný pod jinou IP adresou.

Jak je to ve vašem případě zjistíte tak, že se podíváte,jakou IP adresu má nastavené vnější (WAN) rozhraní vašeho routeru.

Čtyři IP adresy by byly potřeba, pokud byste chtěl tu IP adresu routovat jako celou síť (adresa sítě – nepoužívá se, adresa brány, vaše adresa a broadcast adresa). Technicky pro to přidělení veřejné IPv4 adresy stačí ta jedna adresa (může být routovaná přes jinou síť), konkrétně ale závisí na tom, jak je možné váš router nakonfigurovat.

2387
/dev/null / Re:javascript
« kdy: 25. 07. 2019, 18:14:48 »
Přestaňte se pokoušet hackovat a věnujte se raději tomu, abyste se uměl aspoň rozumně zeptat.

JavaScript je totiž skriptovací jazyk, který může být použit ve spoustě různých prostředí. Například existuje Node.js, ve kterém si můžete lokálně spouštět JavaScriptové skripty, dokonce si takhle můžete spustit třeba i webový server. Takže stáhnout a spustit soubor pomocí Node.js není žádný problém – příklad je v předchozím komentáři.

Vy to ale pravděpodobně chcete udělat ve webovém prohlížeči, a to bez vědomí a interakce uživatele. Jenže to by samozřejmě byla obrovská bezpečnostní díra, kdokoli by takhle klidně mohl na váš počítač dostat a spustit libovolnou aplikaci, libovolný vir. Na to jste asi ve svém snažení zapomněl, že, že pokud byste se dokázal vy vloupat do cizího počítače, dokázal by se i kdokoli jiný dostat do toho vašeho…

Pokud máte urputnou potřebu někomu škodit, doporučuju navštívit psychologa. tady vám s tím nikdo nepomůže.

2388
Sytémovou utilitku nice znám ta však neřeší všechny problémy. Jak mnozí z diskutérů uvedly není, moudré vytěžovat server na 100%. Hledám řešení, které mi umožní, zapínat vytěžovací úlohy v případě, pokud průměrné vytížení serveru za poslední hodinu nepřesáhlo například 30%. Podobně by bylo hezké brát v úvahu, operační paměť, nebo zápisy na disk. Tohle pomocí nice, pokud vím,  nezvládnu.
Proč to chcete dělat? Vypadá to, že se snažíte ručně optimalizovat něco, co bude jádro optimalizovat mnohem lépe.

2389
/dev/null / Re:administrace systemu
« kdy: 20. 07. 2019, 15:26:09 »
Píšete „vím, že to jde přes“, ale i to víte špatně. Pokud se na nějaké zařízení chcete dostat, domluvte se s jeho majitelem. Pokud byste se někam dostával neoprávněně, jde o neoprávněný přístup k počítačovému systému, na který trestí zákoník pamatuje v § 230 a oceňuje ho až dvěma roky vězení, v případě přitěžujících okolností i více.

2390
Vytváříte tam objekt Document a pravděpodobně nikde nenastavujete fieldu documentsForUsers nějakou hodnotu – v deklaraci to nemáte a nejspíš to není ani v konstruktoru. document.getDocumentsForUsers() pak vrací null a pokus o volání metody na null skončí NullPointerException.

Jinak s ORM vám asi nepomůžu, já mám k ORM vrozený odpor (podle mne je to nástroj, který dělá víc škody než užitku) a zatím se mu úspěšně vyhýbám… (Ne že bych nedělal i na projektech, kde se používá ORM, ale nemusím u nich ORM řešit.)

2391
Vývoj / Re:Prototypové OOP
« kdy: 16. 07. 2019, 11:00:53 »
Nejrozšířenější jazyk používající prototypovou dědičnost je JavaScript. O prototypové dědičnosti v JavaScriptu si můžete přečíst např. v článku Třídy, dědičnost a OOP v Javascriptu – II.

2392
Software / Re:Interaktivní návrh obrazovek
« kdy: 16. 07. 2019, 09:35:10 »
Lidé z oboru, kteří tohle dělají, jsou UX designéři. Používají např. Sketch, Figma nebo Adobe XD pro návrh wireframů nebo obrazovek. Dají se použít i pro jednoduché prototypy, případně se pro prototypy používá např. InVision, Framer, Axure nebo Principle.

2393
Token pro autorizaci požadavků na resource server se obvykle posílá v hlavičce Authorization – použije se typ autentizace  „Bearer“ a pak je uvedený token. Tj. HTTP hlavička pak vypadá takhle:

Kód: [Vybrat]
Authorization: Bearer <token>

Resource server s podporou JWT by měl umět vyzvednout si JWT token z této hlavičky.

2394
Spring musí být nakonfigurován, aby povolil ten přístup bez client secret – dá se k tomu něco najít např. zde: Spring Security OAuth 2.0 - client secret always required for authorization code grant.

Podle mne je local storage nebo session storage bezpečné úložiště pro ty tokeny – dostanou se k němu jenom skripty z příslušné domény. Pokud jde o SPA aplikaci, můžete ten token uložit i přímo v aplikaci, ale pak dojde k odhlášení uživatele když obnoví stránku (F5).

2395
Používáte podporu pro resource server, která je součástí Spring Boot, takže JWT nebudete ověřovat ručně. O ověření se postará Spring Boot a z vašeho pohledu to bude fungovat stejně, jako jakýkoli jiný způsob přihlášení. Tzn. deklarujete, které části aplikace může používat anonymní uživatel, které přihlášený, případně jakou roli musí mít uživatel, aby mohl použít danou službu. Je dobré to ověřit tak, že vyzkoušíte přístup s platným tokenem, s expirovaným tokenem, s tokenem s nevalidním podpisem a bez tokenu. K aplikaci byste se měl dostat jenom s platným tokenem, v ostatních případech musí server vrátit nějakou chybu.

Implicit flow se už dnes nepoužívá. Byl navržený pro aplikace v prohlížeči, ale i tam už se dnes doporučuje používat authorization flow, akorát se v takovém případě nepoužívá client secret (protože u aplikace běžící kompletně v prohlížeči není kam ho schovat).

2396
Pokud běží REST API na jiném hostname, než webová aplikace (typicky to tak je), musí ten REST server posílat Access-Control-* hlavičky, aby prohlížeč komunikaci akceptoval. Je to ochrana před tím, aby webová stránka nemohla volat REST služby serveru, který s tím nepočítá – mohla by tak na ten server útočit.

Akorát ve Springu to nemusíte řešit ručně, má už pro to podporu: Enabling Cross Origin Requests for a RESTful Web Service.

2397
Každá stránka by si měla kontrolovat, zda je token k dispozici – a pokud není, přesměrovat uživatele na přihlašovací stránku.

JWT je jen JSON zakódovaný v BASE64 (resp. jsou to tři objekty, každý se zakóduje do BASE64 a vše se pak spojí tečkou do jednoho řetězce). Takže získat z toho ty údaje (pokud byste neprováděl validaci) jde i ručně. Lepší je ale použít hotovou knihovnu, např. na jwt.io je docela dobrý přehled knihoven pro různé jazyky.

2398
Client-id je veřejný údaj, ten není potřeba šifrovat. Client secret se používá v případě, kdy se autentizuje serverová aplikace, do které můžete ten klíč client secret schovat. Pokud se autentizuje webová aplikace běžící v prohlížeči, client secret se nepoužívá – bezpečnost je založená na tom, že autentizační server po dokončení autentizace přesměruje prohlížeč na adresu, která je svázaná s daným klientem. Tj. i kdyby přihlášení zahájil útočník, skončí to tak, že se uživatel přihlásí do té správné (ne útočníkovi) aplikace.

Pro podpis JWT se pak mohou použít dvě různé metody – buď  se používá sdílený klíč, nebo klasický elektronický podpis s veřejným a privátním klíčem. Ten sdílený klíč se používá v případě, kdy si aplikace navzájem důvěřují a vše je na serveru, takže se sdílený klíč k nikomu cizímu nedostane. Aplikace, která JWT token jenom ověřuje, totiž musí mít ten samý klíč, který se používá pro vytvoření podpisu – škodlivá aplikace by tudíž mohla sama vytvořit falešný JWT, který by ale byl podepsán tím správným klíčem, a třetí aplikace by mu důvěřovala.

Druhá možnost je použití veřejného a privátního klíče. To používají třeba veřejné služby – když se přihlašujete prostřednictvím Google nebo Twitteru, dají vám jenom veřejný klíč. Nemohou použít přístup se sdíleným klíčem, protože pak by tím jejich klíčem mohl kdokoli podepsat JWT, který by pak vypadal jako skutečný JWT od Googlu nebo Twitteru. Implementačně je ten způsob s dvojicí klíčů trochu složitější, ale většinou používáte nějakou knihovnu, kde už je to podepisování zapouzdřené a vy to nemusíte řešit. Pokud tedy klienta nemáte pod kontrolou (buď je to webová aplikace v prohlížeči, a nebo aplikace třetích stran), používá se tahle druhá metoda s veřejným i privátním klíčem. My to například budeme používat i v jednom spolku, kde se bude autentizovat víc různých aplikací. Sice jsou všechny ty aplikace „naše“ a mohli bychom jim věřit, ale očekáváme, že i ty „naše“ aplikace budou různě důvěryhodné – takže rovnou použijeme tu variantu s veřejným a privátním klíčem, a ten privátní klíč bude znát jenom aplikace provádějící autentizaci.

Kontrola toho, zda JWT nebylo změněno, by se měla provádět vždy, když se JWT použije (budete z něj číst nějaká data). K tomu právě slouží ten podpis. V knihovnách to obvykle bývá nazváno jako validace a ověří se právě to, že podpis sedí s daty, tj.  po podepsání nedošlo ke změně dat. K validaci je právě potřeba znát buď ten sdílený klíč nebo veřejný klíč, podle toho, co se používá.


Mám na tohle diskusní téma zapnuté e-mailové notifikace, takže když sem vložíte příspěvek, dozvím se to, a pokusím se poradit, pokud budu vědět.

2399
Sítě / Re:Veřejná, neveřejná
« kdy: 23. 06. 2019, 21:42:04 »
To nic nemění na tom, že i když bude mít možnost navázat z venku spojení na libovolný port TCP i poslat UDP paket na libovolný port (a paket dorazí až na cílový počítač), pořád ještě to neznamená, že tam není firewall. Firewall může blokovat třeba pakety nepatřící do žádného spojení nebo třeba tyhle pakety. Stejně tak přítomnost firewallu nijak nesouvisí ani s tím, zda je ta IP adresa routovaná nebo zda je to řešené jako NAT 1:1.

2400
Sítě / Re:Veřejná, neveřejná
« kdy: 23. 06. 2019, 20:58:04 »
Tak mi komunikace na všechny porty prochází, ale jsem za firewallem? Jak to jde dohromady?
Firewall blokuje provoz podle nějakých pravidel. Ta pravidla nemusí brát ohled na porty nebo to může být podmínka „port + další podmínka“. Firewall může blokovat i provoz, který žádné porty nemá (nemáme jen protokoly TCP a UDP).

Stran: 1 ... 158 159 [160] 161 162 ... 375