Akorát že to byla reakce úplně na něco jiného.
To neokradl nebyla reakce na mé okradl? Nebo chceš tvrdit, že víš lépe, na co jsem reagoval svým že Tě okradl, než já? Teda, v originálnosti vejmluv mne furt překvapuješ....
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.
Blba ze sebe dělá sám ten, kdo tvrdí, že se stahují zbytečné skripty, sourcemaps apod.
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.
Btw. ta stránka stahuje i plno dalších blbostí, včetně např. nějakého pdf-workeru, kterej je určitě na login-page potřeba, žejo.... Jako mít na jednoduchý login page skoro 9MB javascriptu????? Fakt profi práce....
Ano, protože jsem za bezpečnost považoval aktivní kroky, které brání nějakým útokům.
Jako že jsi si myslel že mít "neděravou aplikaci" do bezpečnosti nepatří???
Když porušíš pravidla vývoje na backendu, máš děravý backend. Když porušíš pravidla vývoje na frontendu, máš děravý frontend. Je to úplně to samé.
Nevím, za co jsi bezpečnost považoval. 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.
Pokud někdo číslo účtu v SMS nekontroluje, je náchylný ke spoustě různých útoků.
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....
Samozřejmě, kdo nečte SMS, tak je náchylnej k různejm útokům. Třeba napadení frontendu. Jenže ono nemusí jít o nečtení, může jít např. o napadení telefonu. Nebo. Nebo. 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.
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áš.
i vyvarování se triviálně nebezpečným konstrukcím typu eval(), pak
Víš, ono těch bezpečnostních problémů na frontendu je podstatně více, než jen ten triviální eval. Ale vzhledem k tomu, jak dlouho mi trvalo, než jsi aspoň částečně byl schopnej připustit, že vůbec nějakej bezpečnostní problém na frontendu může být, tak fakt nemám ani čas, ani náladu ti vysvětlovat podstatu dlaších, složitějších a v reálu k útokům použitelnejch nabourání bezpečnosti frontendu.
Smiř se s tím, že napsat frontend bezpečně není "automatické", že je k tomu třeba něco vědět a dodržovat určitá pravidla.A s dodržováním pravidel mají hoši z Monety evidentně problém, v diskusi už bylo poukázáno na X porušení pravidel dobrého webu (debugovací skripty na produkci, obecně velikost skriptů, s tím související nahrávání nepotřebného balastu potřebného až někde v hloubi webu, absence SCP....)
Btw., v tom útoku nemusí jít jen o podvržení plateb, kde Tě, když vše děláš správně, zachrání další vrstva zabezpečení. Může jít např. o krádeže výpisů z účtů, kde už další vrstva zabezpečení prostě není. Tam Ti stačí nabourat frontend a máš to, pro co sis přišel.