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 ... 295
1
Hardware / Re:GPS lokátory do auta
« kdy: 12. 05. 2021, 11:04:45 »
Normálně je lokátor buď vypnutý nebo odesílá data s celkem velkou periodou pro úsporu dat a baterky. Až když detekuje neoprávněný pohyb (levné nemají) nebo se aktivuje na dálku, začne odesílat data často. Můžete skončit s GPS adresou starou 10 minut až hodinu. Budete tedy vědět, že je auto někde v Praze v podzemní garáži ;-) Pokud máte i triangulaci BTS, můžete mít lepší upřesnění polohy na třeba dva bloky. To už se dá pěšky obejít.
Mícháte dohromady zjišťování polohy a odesílání dat. Pokud bude mít lokátor v garáži mobilní signál, aby odeslal data, je jedno, zda jsou to data shromážděná z GPS nebo z mobilní sítě. Navíc i triangulace z mobilních sítí bude v podzemních garážích mít horší přesnost.

2
Hardware / Re:GPS lokátory do auta
« kdy: 11. 05. 2021, 19:07:52 »
Zase vyhoda mobilnich siti je, ze maji casto signal tam, kde GPS signal neni. Krabicka obsahujici GPS + mobilni data a schopna ziskat polohu z obou by byla nejlepsi. Musi se ale resit i spotreba elektriny a zalozni baterie. ukradene auto odstavene v podzemnich garazich s odpojenou baterii je pro GPS konecna.
Odpojená baterie bude konečná i pro pro cokoli jiného, co se bude založené na odesílání dat. Ale pořád budete mít GPS pozici před tím, než auto do garáže vjelo. Najít auto v podzemních garážích už pak nebude takový problém.

3
Hardware / Re:GPS lokátory do auta
« kdy: 11. 05. 2021, 13:04:34 »
De facto ani GPS nepotřebuješ. Pokud máš přístup k internetu můžeš použít API. Zkoušel jsem to na https://github.com/vlna/esp-cheap-geotracker a bylo to v zastavěné oblasti dost přesné (desítky metrů). Aktuálně to nefunguje bo Google poměnil API. Podobné API nabízí i Mozilla a snad i další. Stačilo by přidat AP nebo využít řidičův telefon jako AP (moje verze hledá volné AP, ale to se ukázalo jako poměrně nespolehlivé).
GPS je pro určování polohy mnohem lepší, než se pokoušet triangulovat pozici na základě zaznamenaných WiFi sítí, případně mobilních sítí. Navíc tazatel chce sledovat polohu auta, ne řidičova telefonu. Za prvé by se to asi nelíbilo řidiči, za druhé principGPS lokátoru auta je právě v tom, že sledujete polohu auta a nejste závislý na tom, zda má řidič zrovna správný telefon a zda nepodvádí.

4
Odkladiště / Re:Jak funguje spehovani pro cilenou reklamu?
« kdy: 10. 05. 2021, 11:54:38 »
Určitě spolu G. a F. v prodeji reklamy nějak nespolupracují? Mohlo by to být výhodné pro oba. Nemusí používat reklamní systém toho druhého, stačí si vyměňovat nebo přeprodávat data.
Jsou to v tomhle oboru asi dva největší konkurenti. Spoluprací by porušily antimonopolní zákony i zákony na ochranu osobních údajů. Opravdu si nemyslím, že by v tom spolupracovaly.

5
Odkladiště / Re:Jak funguje spehovani pro cilenou reklamu?
« kdy: 09. 05. 2021, 13:29:21 »
Tak to nevim, prokazatelne mi facebook ukazal neco, co jsem googloval, a co nema nic spolecneho s daty na Facebooku.
Kdybyste to opravdu sledoval, zjistil byste, že jste navštívil stránky s danou problematikou, které mají v sobě lajkovací tlačítko, nebo jste proklikl nějaké příspěvky s tematikou na Facebooku apod.

Kdyz tam dam do iframe Seznam.cz, tak nevidim jediny HTTP request na Seznam.cz, a vrati mi to tam 404 Not found z w3school.com. Jak byste to vysvetlil?
Seznam pomocí hlaviček zakazuje vkládání do rámců. Když zkusíte jiný web, který to nezakazuje, do stránky se vám normálně vloží a v prohlížeči ten požadavek uvidíte. Nebo se podívejte tady na diskusním fóru, je tady vkládaná reklama  Googlu.

6
Odkladiště / Re:Jak funguje spehovani pro cilenou reklamu?
« kdy: 09. 05. 2021, 11:47:14 »
1. Ja otevru Facebook, a ten bude mit vlozeny na strance nejaky prvek od Googlu, ktery zobrazuje reklamu.
Nebude. Facebook si prodává reklamu sám, nepoužívá reklamní systém Google.

2. Browser prece by default blokuje tzv. CORS requesty, takze na Facebook.com se mi nemuze v Browseru v Javascriptu udelat GET Google.com (obrazne receno), aby se nacetla cilena reklama.
JavaScriptový kód reklamy je vložený přímo v HTML kódu stránky. A vkádá iframe z reklamného systému. Takže do URL toho iframe si může poslat informace, které potřebuje reklamnímu systému předat.

SHRNUTI: Jak Google.com vi, ze ten dotycny na Facebook.com jsem JA? Prosil bych konkretni flow.
iframe je vložený z domény reklamního systému. Takže vidí cookies nebo localStorage z té domény reklamního systému. Prostě reklama Googlu se vám zobrazuje stále ze stejné domény, z pohledu prohlížeče jste prostě stále na stejném webu – akorát ten web je shodou okolností obalen nějakou jinou stránkou, která je pokaždé jiná.

7
Odkladiště / Re:Jak funguje spehovani pro cilenou reklamu?
« kdy: 09. 05. 2021, 10:28:21 »
Když něco hledáte na Google, Google si to spáruje s vaším profilem a používá to při doručování reklamy ve svých produktech. Google AdWords je ale vloženo na spoustě dalších webů, takže pak se vám odpovídající reklama v AdWords může zobrazit na nějakém blogu, v novinách apod.

Facebook se o hledání na Google může dozvědět jedině přes referrer – když půjdete z výsledků vyhledávání odkazem na Facebook. Případně teoreticky když půjdete z výsledků vyhledávání na stránku, kde je vložen nějaký prvek Facebooku (např. tlačítko „Líbí“) – nevím, jak teď vypadá kód, který se pro vkládání tlačítka používá, zda se může k referreru dostat.

Jenom na základě toho, že jste něco hledal na Googlu, se Facebook nic nedozví. Musí tam být to propojení, že ve výsledcích hledání kliknete na odkaz, cílová stránka se dozví z jaké stránky jste přišel, tedy že to byl Google s nějakým vyhledávaným výrazem. Dál záleží na tom, co ta cílová stránka s touhle informací udělá. Ale Facebook se ty informace dozví spíš z toho, co děláte na Facebooku.

Co zadáváte do prohlížeče nikdo nešpehuje (pokud nemáte na počítači nějaký vir). Stránky si sice mohou logovat otisk vašeho prohlížeče, ale to jim je k ničemu, protože neví, jaké jiné stránky jste navštívil nebo co jste kde hledal. Nejvíc toho vědí ti, kdo mají své kódy vložené na spoustě jiných stránek – např. provozovatelé reklamních systémů nebo různá lajkovací tlačítka. Protože ti vás mohou sledovat napříč weby (je na stránce vždy jejich kód), zároveň vědí, na jakém webu jste (protože se dozví, odkud se volá ten jejich vložený kód).

8
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 08. 05. 2021, 08:53:42 »
Připojovací podmínky jsou smluvní závazky zákazníka (které podmiňují povinnost poskytovatele splnit smlouvu), "definice služby" je závazek poskytovatele. Evidentně jde tedy o ortogonální ustanovení uzavřené smlouvy a není to ani náhodou totéž.
Jo, takže když se ISP zaváže vytvořit přípojku v Praze a zákazník vytvoří podmínky pro připojení v Ostravě, perfektně to klapne, protože „připojovací podmínky“ a „definice služby“ jsou na sobě zcela nezávislé.

Kolikrát mám napsat, že dle zákonů ČR je ISP povinen plnit smlouvu, nikoli nějaké očekávání.
Na tomhle jsme se shodli někde na straně 2 této diskuse. Ovšem ukázalo se, že ta smlouva používá pojem, který nemá žádnou závaznou definici. Takže diskuse pokračovala dál a snažili jsme se odvodit nějakou definici pojmu „služba veřejné IP adresy“. Evidentně bez vás. Tak až si tu diskusi dostudujete a budete schopen diskutovat o tom, jak odvodit definici pojmu „služba veřejné IP adresy“, můžeme pokračovat.

Nebude možné ověřit, zdali ISP je schopen poskytnout službu VIPA tak, jak jsi ji definoval Ty. Protože pokud např. ISP poskytuje NAT 1:1 označený veřejná IP, tak podle Tvé definice:Přijde zákazník 1 objedná veřejnou IP. ISP opravdu zpřístupní služby definované tímto zákazníkem, tedy závazek splní.
Přijde zákazník 2 objedná veřejnou IP. Protože bude chtít IPSEC, tak ISP naprosto stejnou službou smluvní závazek nesplní.
Tedy je z toho vidět, že tak, jak jsi definoval veřejno IP, jde ve skutečnosti nikoli o jednu službu, ale o několik různých služeb. Tedy není bez zákazníka dobře definovaná, a tedy nejde bez zákazníka ověřit, zdali ISP poskytuje službu VIPA.Co jde ověřit je, zdali poskytuje službu NAT 1:1. Nebo zdali poskytuje (skutečnou tedy routovanou) veřejnou IP. Protože to jsou dobře definované služby "nezávislé na zákazníkovi".
Račte už konečně pochopit, že poskytování určité služby neznamená, že uspkojíte všechny zákazníky, kteří takovou službu požadují. Poskytování služby znamená, že uspokojíte nezanedbatlenou část zákazníků požadujících takovou službu. Autoservis nepochybně poskytuje službu opravy aut, opraví vám na autě nejrůznější závady – ale když se s nimi budete domlouvat, že byste přivezl své BMW, řeknou vám, že dělají pouze koncernová auta. Hospoda nepochybně nabízí služu stravování, můžete si tam dát svíčkovou, guláš, utopence – ale když tam přijde vegan, z nabídky si nevybere. Student Agency nepochybně poskytuzje službu autobusové dopravy, ale z Mostu do Bíliny vás pravidelnou linkou neodveze. Už to chápete?

A jakékoli očekávání zákazníka nemá naprosto žádný vliv na to, kdy, kam a jak ten autobus pojede.
Akorát že není řeč o tom, že by zákazník určoval, jak bude služba vypadat, ale určuje, zda byla služba splněna. Když dopravce nadefinuje svou linku Praha–Brno tak, že skončí v Humpolci na náměstí, bude to sice hezké, ale nedodrží smlouvu o dopravě z Prahy do Brna. Protože zákazník očekává, že linka Praha–Brno ho doveze do Brna.

9
Je teda to Moneta bankovnictví na webu bezpečné, nebo ne ? Protože jestli ne, asi by se to mělo eskalovat
Nenarazili jsme tu na nic, co by dávalo důvod domnívat se, že to bankovnictví není bezpečné.

Pane Jirsáku, zcela věcně: co máte pořád proti “security through obscurity” ? Jistě, úhelný kámen bezpečnosti to být nemůže, neboť by to indukovalo falešný pocit bezpečí , ale jako doplněk je to naprosto v pořádku, prostě je to v obecném slova smyslu tajemství.
Ne, security through obscurity není v obecném smyslu tajemství. Za security through obscurity je označována situace, kdy se někdo snaží skrývat něco, co principiálně skrýt nejde. Je možné to trochu zakrýt, zamlžit, ale nejde to doopravdy skrýt. To je rozdíl oproti skutečnému tajemství, které můžete schovat a schováváte úplně.

Pokud o tom někdo uvažuje jako o doplňku, je to právě ten falešný pocit bezpečí. Když budete mít bezpečnostní dveře, kování odolné proti odvrtání a tři bezpečnostní zámky, nebudete na ty dveře „jako doplněk“ instalovat zámeček z nějaké dětské hry, který se rozpadne jenom když se na něj ošklivě podíváte. Každému je jasné, že kdo si poradí s tím vším zabezpečením okolo, bez mrknutí oka si poradí i s tím dětským zámečkem. Security through obscurity funguje právě jen jako vzbuzení falešného pocitu bezpečí – když jsem tomu věnoval čas a energii, tak to přece musí mít nějaký přínos, ne? Jenže ten přínos je jen teoretický, je neměřitelný, a hlavně nevypovídá vynaložené energii. Kdyby se ta energie věnovala skutečnému zabezpečení, zlepšila by se bezpečnost třeba jen málo, ale pořád by to bylo víc, než ten neměřitelný teoretický přínos security through obscurity.

Nebo se na to můžete podívat opačně. Pokud by internetové bankovnictví bylo tak špatně zabezpečené, že by na něj dokázal zaútočit i někdo, komu znatelně pomůže, že vidí i neminifikovaný kód frontendu, má to bankovnictví řádově větší problém než ten čitelný kód frontendu. Když běžci nezanedbatelně pomůže to, že ho na startu posunete krok před startovní čáru, je vám jasné, že ten běžec nepoběží ultramaraton.

10
Snažíte se z toho vykecat, ale to, co jste napsal, už nesmažete. Celé tohle začalo tím, že jste polemizoval s mým tvrzením, že prohlížeč nestahuje původní zdrojové soubory ale jen minifikované soubory. Teď se z toho snažíte vykroutit, že jste vlastně nemyslel soubory, ale jenom jejich části.

Pak jste tvrdil, že minifikovaný kód podstatně stíží útočníkovi hledání chyb – a nakonec z vás jako příklad vypadlo volání funnkce eval. Jo, to se bude v minifikovaném souboru fakt těžko hledat – otevřít soubor v editoru a dát vyhledat eval, to je fuška.

Příště, až zase budete chtít diskutovat o něčem, čemu moc nerozumíte, raději se na to vykašlete. Je to lepší, než pak své přešlapy zkoušet maskovat tím, že z ostatních děláte blby.

je napsané neprofesionálně
Zkuste si zjistit, jaký je rozdíl mezi psaním programu a jeho buildováním. Navíc jsem uváděl důvody, proč může dávat smysl mít i na produkci nějakou dobu dostupné sourcemapy a původní zdrojový kód. To, že něčemu nerozumíte, neznamená, že je to špatně.

11
Víš, normální člověk, když si není jistý, na co druhý reagoval, tak se zeptá.
Normální člověk reaguje tak, aby bylo jasné, na co reaguje. Jenže to vy jste nechtěl, protože by bylo vidět, jak je vaše reakce nesmyslná.

pokud je prokázáno, že ta stránka se zbytečně připojuje někam, tak prostě tam je prokazatelně zbytečný skript dělající to připojení
„Skript“ obvykle znamená celý soubor. Pokud je v souboru 4 MB kódu a z toho možná kilobajt kódu, který dělá zbytečnou věc, neznamená to, že celý skript je zbytečný.

Samozřejmě, že u nemalé části phisingu (např. zaměřené na elektronické bankovnictví) to je s čím porovnatelné, protože URL se snaží napodobovat orginální URL, které uživatel zná.
Nezná. Málokdy zná adresu tak dobře, aby si byl jistý a rozpoznal podvod na první pohled. Jinak by phishing nefungoval.

Navíc je to vlastně jedno, protože zadávat hesla na "mailem zaslaném odkazu" je stejné porušení pravidel bezpečnosti uživatelem, jako nezkontrolování čísla účtu v SMS.
Není. Adresu otevřenou z e-mailu můžu dodatečně zkontrolovat. Když potvrdím transakci, kontrolovat něco dodatečně často nedává smysl.

Takže i kdyby to co tvdíš byla pravda (jako že není), tak to nijak nevyvrací to, co jsem tvrdil: že pod otázky bezpečnosti patří i co největší prevence "uživatelských chyb" vedoucích k úspěšnému útoku.

Víš, v Tvém omezeném světě, kde existují pouze útoky typu "(catch, modify and) replay", tak nijak. Ale jak jsem Ti v předchozích postech doložil, tak pod pojmem bezpečnost webové aplikace spadá podstatně více problematik a podstatně více druhů útoků, než jen ten "replay".
No jo, mistr světa, všechno ví, všechno zná, nikdo jiný to znát nemůže. Proč pak polemizujete s tím, že prohlížeč v případě IB Monety nestahuje žádné zbytečné soubory a tvrdíte, že stahuje zbytečné skripty? Proč tu obhajujete security through obscurity? To podle vás patří do best practice?

A některým z těchto jiných útoků brání dobře napsaný frontend.
Já bych spíš řekl, že špatně napsaný frontend některé útoky umožňuje. To, že nepoužívám eval() (což je to jediné, co z vás zatím vypadlo), není žádný dobře napsaný frontend. To je naprostý základ, a pokud někdo nedodrží ani to, je to velice špatně napsaný kód. (Samozřejmě s výjimkou případů, kdy někdo opravdu dobře ví, co dělá – ale to není nic do této diskuse.)

Nechceš toho už nechat? Jen dokolečka prokazuješ, že problematice webové bezpečnosti prostě nerozumíš.
Pokud je pro vás základem webové bezpečnosti security through obscurity, pak vaší webové bezpečnosti opravdu nerozumím.

V podstatě dokolečka tady různými slovy opakuješ, že považuješ aplikaci zabezpečenou proti jednomu z mnoha druhů útoků za bezpečnou, což je prostě kravina.
Nesmysl.

Zamysli se, proč je to druhý faktor. Že by někde existoval první faktor?
Bingo. Zkuste nad tím ještě chvíli uvažovat, třeba na to přijdete, co je ten první faktor.

Tady jen potvrzuješ, že uživatelův "počítač" - a mezi což patří i bezpečnost frontendové aplikace - mezi zabezpečení IB prostě patří.
Samozřejmě. Akorát že minifikace kódu není způsob zabezpečení.

12
Nebo chceš tvrdit, že víš lépe, na co jsem reagoval svým že Tě okradl, než já?
Máte to skvěle zmáknuté. Nejdřív napíšete něco, z čeho vůbec není patrné, na co reagujete. A pak mi vynadáte, že přece nemůžu vědět, na co jste reagoval.

Reagoval jsem na odstavec, jde jsi tvrdil, že zabezpečení backendu řeší to, že si někdo napíše PIN na kartu. Což prostě neřeší, protože v okamžiku, kdy zareaguje ochrana na backendu (limity), tak už jsi okradenej.
Ochrana na backendu je potvrzovací kód, který musíte zadat, aby transakce proběhla.

Ano, děláš ze sebe blba, když tvrdíš, že stránka nic zbytečného nestahuje a nedokážeš uznat omyl.Ta stránka prokazatelně stahuje a spouští skript který umožňuje reload stránky při vývoji. A tendle skript tam prostě nemá co dělat, zpomaluje už tak nechutně nakynutý stránky.
Prokazatelně znamená, že ve výčtu stahovaných skriptů vyší označíte ten skript, který je zbytečný. Jenže nic takového se vám prokázat nepodaří, protože žádný z těch skriptů není zbytečný. Zbytečná je možná část kódu.

Když jsem napsal, že stránka neprovádí žádnýá kód, který není potřeba, byl to opravdu omyl – zapomněl jsem na to, že je tam patrně ta podpora pro live reload. Na mou omluvu – reagoval jsem na tvrzení, že stránka stahuje sourcemapy, původní zdrojové kódy a zbytečné skripty. Že bude v bundlu pár zbytečných řádek, jsem neřešil. Ostatně ono tam toho zbytečného kódu nejspíš bude víc, bundler nepracuje tak, že by ořezal na kost přesně jenom ten kód, který je pro danou stránku bezpodmínečně nutný. Ale mohl jsem v tom být absolutně přesný a napsat, že nestahuje žádné zbytečné soubory.

Jsem zvědav, jestli svůj omyl dokážete uznat také vy.

Jako že jsi si myslel že mít "neděravou aplikaci" do bezpečnosti nepatří???
Považoval jsem to za samezřejmost, která je splněná před tím, než začnete řešit bezpečnost.

Ale prostě jsi evidentně netušil, co vše do bezpečnosti webové aplikace patří a ignoroval jsi problémy, které by měl v otázce bezpečnosti znát a řešit i slušný junior. Ale měl jsi tu drzost v diskusi ostatní označovat za laiky a arogantně poučovat.
Samozřejmě že vím, co do bezpečnosti webové aplikace patří. Akorát se snažíte zamaskovat, že vy jste netušil, že prohlížeč nestahuje sourcemapy a už vůbec ne v nich odkázané soubory, když si uživatel normálně zobrazí stránku (bez vývojářských nástrojů).

Takže vlastně celej phishing a opatření proti němu se vlastně vůbec netýká zabezpečení prohlížeče, protože stačí dobře číst a není to problém.... Aha....
Nevím, jak přečtením zjistíte, že adresa je špatně. Abyste to zjistil, musíte ji s něčím porovnat – obvykle ale není s čím. Číslo účtu v SMS je s čím porovnat – s tím číslem účtu, které jste právě zadal.

Jenže ono nemusí jít o nečtení, může jít např. o napadení telefonu.
Právě proto se používá druhý faktor. Protože aby byl útočník úspěšný, musel by napadnout uživatelův počítač a zároveň telefon.

Právě proto je zabezpečenej i frontend, a není to tak, že by mohl poslat požadavek kdokoli a bezpečnost záležela jen na potvrzení SMS.
Aha, takže ten zabezpečenej frontend mi brání v tom, abych si odchytil, jaký JSON s požadavkem prohlížeč posílá, a pak stejně strukturovaný požadavek poslal třeba přes curl. A pěkně prosím, jak přesně mi v tom ten frontend brání?

Bezpečnost frontendu je jeden z faktorů bezpečnosti IB, úplně stejně, jako bezpečnost telefonu, kam Ti choděj SMS. Aby útočník IB zneužil, musí je překonat všechny. A právě proto, že ať už uživatel svým hloupým chováním, nebo hacker zneužitím chyby nebo kombinací může být nabourána bezpečnost jedné z vrstev bezpečnosti, je bezpečnost vícefaktorová.

Bezpečnost zahrnuje i řešení toho, že se uživatelé nechovají vždy 100% ideálně a tím oslabujou bezpečnost použitejch řešení (nečtou SMS, maj zavirovanej prohlížeč apod.). Bezpečnost spoléhající se na to, že se všichni chovájí "správně" není bezpečnost, ale iluze bezpečnosti. To je další ze školáckých pouček, kterou by měl znát každej, kdo se jen trochu ochomejtá kolem bezpečnosti - a kterou tu implicitně popíráš.
Aha, takže phishing vlastně vůbec neexistzuje. Protože to by znamenalo, že útočník musí údělat web, který bude vypadat stejně, jako originální IB. A tomu přece brání bezpečný frontend.

13
Citace
Neokradl.
Psal jsi "někdo s ní může vybrat až do výše limitu z bankomatu.". Tedy ten někdo Tě prostě okradl. Tak prosím takto primitivně nelži, je to trapné.
Akorát že to byla reakce úplně na něco jiného.

Ty jsi Tvrdil, že security je čistě otázka backendu.
Ano, protože jsem za bezpečnost považoval aktivní kroky, které brání nějakým útokům. Pokud do bezpečnosti frontendu počítáte i to, že na frontendu nebudete mít odkaz na stažení zavirovaného EXE souboru, pak musíte opravdu bezpečnost řešit i na frontendu.

Ne Filipe, zábavné je, že neznáš úplné základy web-security, a přitom tu vystupuješ jako člověk, co snědl moudrost světa a snažíš se ostatní poučovat a dělat z nich blby.
Já z nikoho blby nedělám. Blba ze sebe dělá sám ten, kdo tvrdí, že se stahují zbytečné skripty, sourcemaps apod.

To, že je tam další rovina zabezpečení např. v telefonu pomocí SMS je pravda, ovšem protože nemálo lidí čístlo účtu v došlé SMS nekontroluje, je toto zabezpečení nedostatečné. Proto ano, úspěšné nabourání JS na frontendu (které umožní pozměnit číslo účtu příjemce) je podstatné narušení bezpečnosti IB. A pokud to furt popíráš, tak další debata nemá smysl, protože pak seš evidentně schopen popřít i nos mezi očima, abys nemusel uznat omyl.
Pokud někdo číslo účtu v SMS nekontroluje, je náchylný ke spoustě různých útoků. Ale OK, uznávám, pokud do zabezpečení aplikace zahrnujete i vyvarování se triviálně nebezpečným konstrukcím typu eval(), pak je skutečně potřeba zabezpečit i frontend.

14
Okradl Tě? Okradl.
Neokradl.

Pokud používáte na frontendu eval(), pak frontend opravdu zabezpečit potřebujete. Nejlépe tak, že si najdete jinou práci.

Vaše představa, že nechtěnému převodu na cizí účet brání JavaScriptový kód v prohlížeči, je opravdu zábavná.

15
Samozřejmě, minimálně tím, že source mapy jsou docela pamětově náročné (zbytečně zvyšují přenášené bajty;
Myslím, že na server se ten jeden soubor navíc vejde. Přenášené bajty by to zvyšovalo, kdyby se přenášely.

Tady je seznam GET požadavků na hostname ib.moneta.cz na úvodní stránce IB Monety po vyprázdnění cache v prohlížeči. Prohlížeč je Chrome 90.0. Máte to tam i s velikostí souborů a dobou vyřízení požadavku.

Kód: [Vybrat]
https://ib.moneta.cz/ GET 200 4.1kb 37ms
https://ib.moneta.cz/static/css/main.dd038447.chunk.css GET 200 29.9kb 90ms
https://ib.moneta.cz/static/css/2.83a38660.chunk.css GET 200 170.9kb 109ms
https://ib.moneta.cz/config.json GET 200 599b 144ms
https://ib.moneta.cz/static/js/main.ab9551fd.chunk.js GET 200 3.9mb 954ms
https://ib.moneta.cz/static/js/2.699be89f.chunk.js GET 200 3.6mb 948ms
https://ib.moneta.cz/config.json GET 200 599b 28ms
https://ib.moneta.cz/static/js/pdf.worker.entry.eb113c7a.worker.js GET 200 667.3kb 124ms
https://ib.moneta.cz/static/media/login_default_background.fe96d08d.svg GET 200 1.6kb 116ms
https://ib.moneta.cz/static/media/login-old-redirect.d66fe5b3.svg GET 200 267.6kb 158ms
https://ib.moneta.cz/static/media/login_default_background.fe96d08d.svg GET 200 1.6kb 145ms
https://ib.moneta.cz/static/js/8rwzPySP46.js GET 200 205.2kb 223ms
https://ib.moneta.cz/vendors/launch/97dcc26c2440/4b6116328f07/launch-063e383bd603.min.js GET 200 155.4kb 277ms
https://ib.moneta.cz/manifest.json GET 200 306b 79ms
https://ib.moneta.cz/vendors/launch/97dcc26c2440/4b6116328f07/db4982d31bbc/hostedLibFiles/EPbde2f7ca14e540399dcc1f8208860b7b/AppMeasurement.min.js GET 200 32.7kb 84ms
https://ib.moneta.cz/vendors/launch/97dcc26c2440/4b6116328f07/db4982d31bbc/hostedLibFiles/EPbde2f7ca14e540399dcc1f8208860b7b/AppMeasurement_Module_ActivityMap.min.js GET 200 3.2kb 101ms

Snad se teď konečně dozvím, který z těch souborů je sourcemap.

Z mého pohledu to je jako bych na platební kartu napsal PIN.
Když na platební kartu napíšete PIN a ztratíte ji, někdo s ní může vybrat až do výše limitu z bankomatu. A může vybírat tak dlouho, dokud kartu nezablokujete. Když někdo ušetří pár vteřin nebo minut tím, že má kód rovnou v čitelné podobě, stejně narazí na zabezpečení na backendu. Když někdo založení bezpečnost na frontendu, je to jako napsat PIN na platební kartu a doufat, že když ji někdo najde, PINu si nevšimne.

Stran: [1] 2 3 ... 295