24. Feb 2022
FrontendČo sa stalo s Faker.js a ako zabezpečiť svoje projekty
Zlaté pravidlo pri inštalovaní externých javascript modulov hovorí, že by sme mali preferovať obľúbené balíčky, ktoré sú často aktualizované.Knižnica Faker.js to všetko spĺňala a desaťtisíce vývojárov ju využívalo na generovanie náhodných dát, ako sú mená ľudí alebo názvy firiem, ako užitočnú pomôcku pri vývoji či testoch.
Jej developer Marak však 5. januára všetkých zaskočil, keď v poslednej aktualizácií vydal verziu s kompletne premazaným kódom. Do inej knižnice colors.js zasa umiestnil nekonečnú slučku.
Nie je úplne jasné, prečo to Marak urobil. Keď mu Github a NPM zablokovali prístup k projektom, Marak na Twitteri napísal, že každý robí z času na čas programátorské chyby.
Skôr ako o chybu však išlo o úmysel. Marak po zverejnení verzie prepisoval komentáre na Githube a zverejňoval odkazy na nesúvisiace príspevky.
Aj keby chcel, Marak našťastie nemal možnosť moduly úplne odstrániť, tak ich aspoň znefunkčnil aktualizáciou. Nie je to prvýkrát, čo sa autor rozhodol odstrániť svoje dielo, hoci na ňom záviselo fungovanie tisícov ďalších projektov.
💡 V najznámejšom incidente z roku 2016 developer Koçulu odstránil z registra okrem iných aj modul left-pad, ktorý využívalo množstvo knižníc - napríklad aj React.
Ľudia z NPM vtedy modul obnovili a do budúcnosti preventívne zakázali zmazanie čohokoľvek, čo už niekto v inom projekte používa.
Marakovi sa napriek tomu podarilo znefunkčniť projekty ako napríklad AWS Cloud Development Kit, ktorý využíval modul colors.js.
Po prvotnom chaose NPM obnovil posledné funkčné verzie knižníc a faker pre JavaScript pokračuje ďalej už pod iným vedením.
Ak sa budeš držať aspoň pár našich základných typov, môžeš trochu minimalizovať riziko, že ťa podobné situácie nepríjemne ovlyvnia.
Aktualizácie
Správa modulov a aktualizovanie závislostí je jedna z mála vecí v programovaní, ktorú by si mal robiť manuálne, aj keď je to otravnejšie. Treba na to myslieť hlavne pri registroch modulov ako NPM pre JavaScript, ktoré ponúkajú vo východzom nastavení istú mieru automatizácie.
Ak pridávaš do projektov moduly štandardne cez príkaz npm install, do súboru package.json sa uloží zápis verzie so strieškou. Vtedy môže byť nainštalovaná akákoľvek najvyššia kompatibilná verzia. V realite sa však môže stať, že aj menší update zanesením nového bugu rozbije tvoj kód a nebude spustiteľný.
Najistejší spôsob, ako sa vyhnúť nechcenému zvýšeniu verzie modulu, je použiť v súbore package.json iba číselný zápis verzie a zvyšovať ju manuálne. Vždy po pridaní nového modulu je nutné striešku zmazať alebo inštalovať konkrétnu verziu modulu.
🔒 Bezpečný zápis: "typescript": "4.3.4"
⚠️ Rizikový zápis: "typescript": "^4.3.4"
V tomto prípade je povolené nainštalovať verzie medzi 4.3.4 a 5.0.0.
Najčastejšie sa stretneš s verziou so strieškou alebo iba s číslom verzie, no npm podporuje aj ďalšie variácie.
Ideálne je aktualizovať moduly po jednom, ľahšie identifikuješ prípadný problém. Vopred známe a chcené problémy s kompatibilitou by mali byť poznačené v poznámkach k vydaniu novej verzie. Menej často môžu problémy spôsobiť aj vnútorné závislosti modulu, ktoré budú obsahovať chybu alebo budú v konflikte s iným balíčkom. Dôležité je preto používať aj package-lock.json, ktorý fixuje aj verzie vnútorných závislostí.
Musím kontrolovať všetky zmeny v commitoch?
Vyššie spomenuté problémy s modulmi faker a left-pad boli síce devastačné, ale ľahko a rýchlo odhaliteľné. Ak však ide o cielený útok hackerov, ktorí sa zmocnia prístupu k vydávaniu nových verzií modulu, určite na seba budú chcieť čo najmenej upozorniť. Viacero modulov (napr. Coa) takto útočníci vydali so škodlivým kódom.
Problémy sa dajú väčšinou odhaliť pri kontrole commitov (ak sa verzia automaticky zverejňuje cez CI pipelinu), no v praxi takto auditujú aktualizácie väčšinou iba veľké firmy. Navyše útočník môže v prípade priameho prístupu do npm registra zverejniť útočnú verziu rovno zo svojho počítača (tu ale pomôže jednoduchá ochrana cez dvojfaktorovú autorizáciu).
Stojí za to si pripomenúť aj "neškodný" žart vývojára pre UI knižnice pre React Ant Design. Hoci sa knižnica profiluje pre firmy a korporáty, jeden z autorov si dovolil bez varovania pridať aktualizáciu, ktorá na Vianoce pridala pre komponenty tlačidiel efekt sneženia. Autor sa po kritike prekvapených vývojárov ospravedlnil a nechcenú funkciu odstránil.
Ako si vybrať knižnicu
Pri výbere modulu je dobré porovnať si tvorbu od viacerých vývojárov.
Ideálny kandidát by mohol vyzerať takto:
- Používajú ho stovky, tisíce ďalších programátorov. Má vychytané muchy, ktoré sa prejavili v bežnej prevádzke na rôznych systémoch a mal by byť preto stabilnejší a bezpečnejší.
- Je pravidelne aktualizovaný. Hoci niektoré produkty sú funkčne kompletné, môžu mať v sebe napríklad závislosti s bezpečnostnými chybami, ktoré je nutné aktualizovať.
- Spravuje ho väčšia komunita alebo firma a nie jeden človek. Jednak je vývoj a oprava chýb rýchlejšia, ale hrozí menšie riziko, že budeš musieť hľadať alternatívu, ak sa developer prestane o projekt starať. Alebo ho prečistí ako Marak
- Má benevolentnú licenciu (napr. MIT), čo priťahuje viac užívateľov a firiem. Zároveň budeš môcť kód aj upravovať podľa vlastnej potreby.
Niekedy, samozrejme, stojí za to tieto pravidlá porušiť, ak je nová knižnica rýchlejšia, menšia či jednoduchšia na použitie alebo sa správa úplne presne tak, ako potrebuješ. Kód by mal byť ale aspoň ľahko udržiavateľný, ak by si v ňom musel neskôr niečo opraviť sám.