Názory k článku Postřehy z bezpečnosti: kritická chyba React2Shell mění pravidla hry
-
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.
-
Filip JirsákStříbrný podporovatel
S tím, že frontendoví vývojáři programují backend, si ještě užijeme. Dokud to byly jednotlivé aplikace, chyby postihly jenom jednotlivé aplikace. Teď už jsou to ale i frameworky.
RSC je správná cesta. Ale naráží to na to, že nápad „pojďme programovat backend ve stejném jazyce, jako frontend, ušetříme tím“ moc nereflektuje realitu. Protože rozdíl mezi frontendem a backendem je především ve způsobu uvažování – rozdílné jazyky jsou ten nejmenší problém. Doufejme, že se kolem Reactu začne motat víc backendových vývojářů.
Holt se teď budou muset i frontendoví programátoři naučit, co znamená vyvíjet backend. Že se musí řešit bezpečnost, validace, autentizace, paralelní zpracování, výkon.
-
Co na tom nereflektuje realitu? Vždyť to se přece vzájemně nijak nevylučuje. Ostatně máte frontendové vývojáře, máte backendové vývojáře, máte fullstackové vývojáře. Což zhruba vychází z toho, co chce kdo dělat a co koho baví.
Ale souhlasím, že kdyby se čistě frontendoví vývojáři vynořili ze své alternativní reality, byl by svět o hodný kus jinde i na tom frontendu jako takovém.
-
Filip JirsákStříbrný podporovatel
Realitu nereflektuje to, že podstatné rozdíly mezi vývojem frontendu a backendu jsou úplně v něčem jiném, než v použitém jazyce. Použitý jazyk je drobnost ve srovnání s jinými rozdíly.
Jinak skutečných fullstack vývojářů zas tolik není. A zajímalo by mne, kdo z nich o sobě říká, že je fullstack vývojář. Většinou „fullstack vývojář“ znamená, že zvládne jedno, třeba backend, a druhé nějak splácá – ale skutečný frontend vývojář, když vidí ten kód, trpí. Nebo opačně. Případně „fullstack vývojář“ znamená, že neumí pořádně ani jedno.
-
A pro tu "většinu" máte nějaké podklady, studie a průzkumy nebo je to vaše dojmologie? Že se ptám, že... Ne, žádné takovéhle "většinou" opravdu neexistuje. I fullstackoví vývojáři jsou horší i lepší stejně jako všichni ostatní. To je celé. To, co píšete jsou jen vaše naprosto nesmyslné předsudky. Dle kterých soudíte svět. Ale podle sebe.
-
Filip JirsákStříbrný podporovatel
Vy pro vaše tvrzení máte nějaké podklady, studie nebo průzkumy?
Nejsou to předsudky, nikoho nehodnotím na základě toho, že o sobě řekne, že je fullstack vývojář. Stejně jako nikoho nehodnotím podle toho, že řekne, že je frontend vývojář nebo backend vývojář. Vždycky konkrétního člověka hodnotím podle toho, co předvede.
Je to zobecnění, kterého jsem si všiml, když jsem pár takových fullstack vývojářů někde potkal. Ale neuplatňuju to při posuzování nikoho konkrétního. Je klidně možné, že vy máte jinou zkušenost. A nebo třeba máte ty podklady, studie a průzkumy pro svá tvrzení.
-
React2Shell je rozsáhlý problém.
Ale tak nějak se nic hrozného neděje.
Tak budou piráti chvíli těžit BTC než si toho někdo všimne.
Důležité věci nestrčím na web ale budu se snažit je ochránit třeba Fortinetem.
A proto se mi zdá mnohem horší zranitelnosti Fortinetu.
Naštěstí ho nemám.
Ale v ČR to může být docela rozšířené.
Vnucujou ho všichni tři mobilní operátoři?
Dvě nabídky mám na stole.15. 12. 2025, 21:27 editováno autorem komentáře
