Sorry, Filipe, ale opět klasika - docházejí Ti arugmenty, tak začínáš agumentovat ad hominem. Mluv za sebe, jestli o dané věci nic moc nevíš Ty ještě neznamená, že s webovým vývojem nemají zkušenosti ostatní..... :-)
Tvrdit, že já to vidím správně, protože všichni ostatní jsou laici, to je jen varianta naprosto učebnicové arogance: "já vím všechno nejlíp".
Za se to překrucujete. Laici jsou ti, kteří když se dozví o bezpečnostní díře na backendu, vrhnou se na minifikaci frontendu a myslí si, že tím něco zachrání.
Minifikovaný kód je řádově obtížnější na čtení, než původní. Sorry, ale tady pronášíš kategorické soudy o věci, se kterou evidentně nemáš reálné praktické zkušenosti.
V prohlížeči máte takové kouzelné tlačítko, které minifikovaný kód hezky zformátuje. Takže z té původní nečitelné hrůzy zbyde nečitelné už jenom to, že jsou možná přejmenované identifikátory. Jenže prohlížeč má další kouzelná tlačítka, která umožňují vkládat breakpointy a krokovat kód. Takže ten kód nemusíte číst, můžete ho prostě krokovat. Pro pochopení fungování kódu to bohatě stačí. Vím to, protože to tak dělám.
Není. Nahrávat "neužitečné" skripty a provádět na klientu nějaký kód, který není k funkčnosti stránky potřeba je z hlediska UX naprosto stejný problém, jako nahrávat neminifikované soubory. Zbytečné zpomalení.
NO, a tady se zase ukazuje, že jste laik, který o tom nic neví. Klient žádné neužitečné skripty nenahrává a neprovádí žádný kód, který není k funkčnosti stránky potřeba. Už jsem to psal několikrát. Když neotevřete vývojářské nástroje, prohlížeč stáhne do posledního bitu to samé, jako kdyby na serveru zdrojové kódy nahrané nebyly.
Ovšem frontend bankovnictví klíčová infrastruktura je, neboť nemálo bezpečnostních problému (jako např. ochrana proti XSS) jsou záležitosti frontendu
Mýlíte se. Ochrana proti XSS je samozřejmě záležitostí backendu. Kdyby byla na frontendu, útočník si ji prostě vypne a máte po ochraně. Nejblíž frontendu má nastavení hlaviček CSP, což ovšem není záležitost apliakce běžící na frontendu, ale serveru, který tu aplikaci servíruje.
Pokud Ti někdo úspěšně napadne frontend, tak mu to např. podstatně usnadní provádění různých variant phisingových útoků atd. atd.....
Jako že si otevřu internetové bankovnictví, pak si ho v DevTools pozměním a pak těm změnám sám uvěřím a napadnu sám sebe? Abychom si ujasnili, co je frontend – frontend je to, co je nahrané v prohlížeči.
Ale vývoj frontendu jde zpravidla v úzké součinnosti s vývojem backendu, že jde opět o úplně jiný případ: zatímco piloti a webaři mohou mít úplně jinou "firemní kulturu", tak pokud jsou někde lajdáci frontendáři, tak zpravidla jsou i backendáři.
Vývoj backendu a frontendu může být úplně oddělený, mohou to dělat různé firmy. A hlavně jste pořád ještě nedokázal, že jde o nějaké lajdáctví.
Zaprve to co tvrdíš je blbina. Bezpečnost webových aplikací závisí I NA FRONTENDU. Viz předchozí odstavec.
Pochopte už konečně, že frontend má plně ve své moci uživatel. Takže na tom nemůže záviset bezpečnost, protože uživatel má možnost cokoli vypnout, změnit, upravit. Mám vám natočit video, kde budete mít bezpečnost založenou na frontendu, ve formuláři nastavím atribut
required – a pak si ho v DevTools vymažu a celou vaši slavnou frontendovou bezpečnost tak vygumuju?
Zadruhé je to z Tvé strany další argumentační faul: že když neumíš vyvrátit to, co tvrdím, tak můj argument překroutíš, abys měl co kritizovat.
Netvrdil jsem, že na tom bezpečnost stojí (byť vlastně i stojí, viz výš).
Aha, takže argumentaulu se na vás opravdu někdo dopustil – akorátjste to byl vy.
Tvrdil jsem, že to zesložiťuje případný útok.
To sice tvrdíte, ale to údajné zesložitění je pod rozlišovací schopnost přístrojů. Vy vyrobíte bezpečnostní chybu, které má hodnotu 1 000 000 000, a pak začnete bazírovat na tom, že jste ale snížil závažnost chyby o 0,0000000001.
Bezpečnost zámku také nestojí na tom, že útočník neví, kde vrtat, ale na tom, že je z "tvrdokovu" a tedy velmi obtížně odvrtatelný. Ale znalost, kde vrtat a kam se postavit, abych nebyl vidět na kameře, urychlí a usnadní provedení útoku.
Jistě. Jenže vy zloději neporadíte, kde má vrtat. Vy ho přivedete do otevřeného bytu, řeknete mu, že odjíždíte na čtrnáct dní na dovolenou, dáte mu do ruky klíče. A pak se chlubíte: Já jsem ale jeho možný útok zesložitil. Dal jsem do předsíně obraz od F. R. Čecha a pokud ho zloděj nemá rád, možná se lekne a uteče. No jo, fajn, útok jste zesložitil. Ale možná by víc pomohlo neotevřít tomu zloději byt a nedat mu klíče.
Nedodržování best-practicies v jedné věci je důvodem k tomu se domnívat, že se nedodržují i v jiných věcech.
Už jsem vám napsal, že žádné takové best-practices nejsou. Ani nevíte, co a jak webový prohlížeč stahuje ze serveru, takže vaše povědomí o best-practices webového vývoje asi bude stejně hodnotné.
příliš dlouhé načítání stránky kvůli zbytečně dlouhému kódu
Vaše smůla je, že každý, kdo se alespoň trošku orientuje ve webovém vývoji, ví, jaké píšete nesmysly. Ten kód je pořád stejně dlouhý, protože se při vývoji minifikuje úplně stejně, jako u produkční verze.
tak je to důvod k pochybnostem, jak jsou dodržována další pravidla ohledně bezpečnosti
Problém je pořád v tom, že se neorientujete v problematice, a na základě své neznalosti činíte dalekosáhlé závěry.
Při hackování potřebuješ odhalit ty, které jsou chybně implementované, a to jsou zpravidla právě ty, které se nepoužívají moc často. A právě takové requesty nemusíš nasimulovat, ale v zdrojovém kódu je můžeš vyhledat. Znalost zdrojového kódu Ti často hodně pomůže porozumět významu requestu a tedy můžeš snáz odhadnout, kde nechal autor toho api "díru".
Lidé, kteří se webovému vývoji věnují, opravdu nepotřebují ten zdrojový kód krásně čitelný a opoznámkovaný. I v minifikovaném kódu najdu požadavky a porozumím významu requestu.
Váš přístup je ukázkový příklad security through obscurity, což je bad practice. Boíte se, že máte chybu v backendu, a místo toho, abyste to řešil, doufáte, že na to nikdo nepřijde, když přejmenujete funkce na frontendu.
Zobrazit příspěvky
