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í...

> 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.

> 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é.

Ve 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/fra­meworkem 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ě.

> 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í.

ano, na to vase se nikdy neobjevi cve a tim to ma 0 zranitelnosti :) Narozdil od knihoven, kde ty zranitelnosti nekdo najde, udela cve a nekdo opravi :)

Ja teda radsi zive knihovny, SBOM a sledovani zranitelnosti v prubehu zivota aplikace.

Aspon vim, ze ty moje knihovny nekontroluje primo utocnik, jako se to posledni dobou deje s NPM balicky.