Vlákno názorů k článku Postřehy z bezpečnosti: kritická chyba React2Shell mění pravidla hry od radekm - React2Shell je krásný příklad, že ani velké množství...
-
radekmStříbrný podporovatelReact2Shell je krásný příklad, že ani velké množství uživatelů nezaručuje kvalitu. A jak by svět mohl být hezčí, kdyby lidé více promýšleli, zda použít nějakou komplexní knihovnu, které většinou sami ani nerozumí, jako závislost, nebo si to radši vyřešit jinak.
Bohužel dnešní software je často pomalejší a méně spolehlivý, než před 30 lety, protože je složen z desítek vrstev, kterým vývojáři nerozumí. K tomu ještě některé programy potřebují komunikovat se servery na druhé straně zeměkoule.
-
L.Stříbrný podporovatel
V drtivé většině případů to NIH řešení znamená, že tam bude chyb víc, než kdyby se použila (rozšířená) knihovna.
-
radekmStříbrný podporovatel
To je podloženo daty?
Osobně, když něco implementuji sám, tak implementuji přesně to, co potřebuji. Nic víc. Takže moje řešení je často mnohem jednodušší než nějaká obecná knihovna a prostor pro chyby je mnohem menší.
-
L.Stříbrný podporovatel
To je podloženo celoživotní vývojářskou zkušeností s vlastními a cizími programy.
Případy, kdy člověk potřebuje jen nějaký malý subset funkčnosti jsou asi jediníé, kde se vám může podařit vytvořit lepší řešení, než má knihovna.
Řešení kde vynecháte třeba autorizaci ke službě je sice menší, ale to neznamená, že je bezpečnější ;-)
-
radekmStříbrný podporovatel
> To je podloženo celoživotní vývojářskou zkušeností s vlastními a cizími programy.
Já právě všude okolo vidím pravý opak. Skoro vše je plné bezpečnostních chyb a pomalé.
A sdílený knihovní kód je hlavní přičinou. Problém je, že hodně knihoven se snaží zpracovávat i neplatné vstupy - což je logické - neboť, aby knihovnu mohl každý použít, musí fungovat všude, takže i se vstupy, co neodpovídají specifikaci. A jsou to knihovny pro HTTP, JSON, ZIP a hromadu dalších věcí.
Zpracování neplatných vstupů knihovnu komplikuje, zpomaluje a zvětšuje prostor pro bezpečnostní problémy.
Takže osobně si práci zjednoduším tím, že neplatné vstupy nepřijmu, pokud nemusím.
Konkrétní věci: Některé HTTP servery používají jen \n k oddělování hlaviček, JSON není přesně specifikován a různé knihovny se chovají různě (třeba vzhledem k duplicitním klíčům) a málokterá je robustní (zvládne neomezenou hloubku zanoření, neomezenou přesnost čísel) a některé JSON knihovny parsují i neplatné vstupy. Mac ještě před pár lety neuměl ani vyprodukovat validní ZIP soubor, když jste komprimovali soubor > 4 GB (nepomohlo, že za tím stojí firma, co má balík peněz).
Závěr: Je velice jednoduché udělat něco kvalitnějšího než umí nějaká široce používaná knihovna. S tím, že je pár knihoven, co jsou velice kvalitní a rád je používám. Ale jsou to výjimky. Podívejte se třeba na React - je to složité a pomalé a moc tomu nepomohlo, že to používají tisíce vývojářů.
-
React není ani složitý ani pomalý. Obojí je značně relativní. React mám v lásce čím dál tím méně, navíc je koncepčně zastaralý, ale tohle paušální tvrzení je také úplný nesmysl. Ano, třeba Svelte je mnohem rychlejší a ještě jednodušší. Ale třeba Angular je mnohem složitější. Obrovský rozdíl je mezi dobře a špatně napsanou reactovou aplikací. A tak dále. To se takhle vůbec nedá říct.
Ve výsledku pak zjistíte, že rychlý je zcela dostatečně pro drtivou většinu případů užití. A to je přesně to, o čem jsem psal na začátku výše.
-
radekmStříbrný podporovatel
> Ve výsledku pak zjistíte, že rychlý je zcela dostatečně pro drtivou většinu případů užití.
Nj, lidé už si zvykli, že na primitivní stránku nebo aplikaci v mobilu musí čekat sekundy nebo dokonce několik desítek sekund :-/
Ale rozumím tomu. To firmy, co dělají internetové aplikace moc neřeší a energii, co ty stránky prožerou neplatí, protože to běží u zákazníků. Takže z tohodle pohledu to je dostatečné.
-
Filip JirsákStříbrný podporovatelVe skutečnosti se třeba v e-commerce rychlost načítání řeší dost fest, řeší se tam desítky milisekund. Rychlost načtení první stránky je jeden z hlavních důvodů pro RSC.
-
Jenomže za to fakt nemůže React ani jiný framework ale zcela typicky pomalá API. Jestli myslíte tohle, to s použitou knihovnou/frameworkem přímo nesouvisí skoro nijak. Teda samozejmě pokud ta aplikace není úplně zprasená -- a ne, že by takovou člověk občas nepotkal. Nebo pokud samozřejmě nezpracovává větší množství dat čili tam ten framework je nasazený nevhodně.
A rozhodně si nezvykli, konverzní poměr to v e-shopech snižuje solidně.
-
radekmStříbrný podporovatel
> Jenomže za to fakt nemůže React ani jiný framework
To ani neříkám. Jen říkám, že díky tomu, že stránky jsou pomalé, tak většině lidí React dostačuje, už jsou totiž zvyklí.
-
radekmStříbrný podporovatel
Aspon vim, ze ty moje knihovny nekontroluje primo utocnik, jako se to posledni dobou deje s NPM balicky.
-
"V drtivé většině případů to NIH řešení znamená"
predevsim to, ze tam nebude bambiliarda funci, ktere nikdo nepotrebuje. A tudiz tam ani nebude bambiliarda deravych funkci.
Jinak receno, vektor k utoku bude zcela jednoznacne vyrazne mensi. Jako bonus se pak eliminuji veskere automaticke utoky na zname diry ktere jsou vedeny prakticky vyhradne na proflaknute veci.
-
DannyStříbrný podporovatelBezpecnost neni o tom, kolik funkci kde je. V prvni rade musi byt bezpecnost integralni soucasti uz navrhu a ne system "se to pak dodela". A jen tak mimochodem, dost pochybuju o tom, ze nekdo na serverovem API programuje "bambiliardu" endpointu, ktere nidko nepouziva - to bude spis vas nicim nepodlozeny babol.
A zrovna v debate kolem react2shell je tenhle argument o poctu funkci mimo zcela - i kdybyste tam mel jednu jedinou funkci, tak... mate problem, zeano ;-)
