Storybook: Brak weryfikacji pochodzenia w Storybook preview umożliwia wstrzyknięcie kodu przez złośliwe witryny

Podsumowanie

Złośliwa witryna internetowa może być w stanie doprowadzić do nieautoryzowanych modyfikacji plików w projekcie programisty podczas działania podatnego serwera deweloperskiego Storybook. W określonych warunkach zmodyfikowany plik może zostać wykonany przez lokalne środowisko uruchomieniowe z uprawnieniami programisty. Twórcy oprogramowania nie odnotowali przypadków aktywnego wykorzystania podatności w środowisku rzeczywistym.

Kogo dotyczy problem?

Problem dotyczy użytkowników uruchamiających serwer deweloperski Storybook w podatnych wersjach.

Podatność nie dotyczy użytkowników, którzy:

• uruchamiają serwer deweloperski, którego nigdy nie otwierają w przeglądarce internetowej (np. automatyzacja headless, klienci MCP)
• uruchamiają lub odwiedzają zbudowaną (skompilowaną) wersję Storybook

Nowsze wersje przeglądarek Chrome i Firefox mogą wymagać potwierdzenia uprawnień przed nawiązaniem połączenia przez stronę internetową z usługą localhost. Zmniejsza to ryzyko, lecz go nie eliminuje. Nie należy przyznawać tych uprawnień niezaufanym witrynom.

Przegląd potencjalnie niekompatybilnych zmian (breaking changes)

Ze względu na wyjątkowy charakter zgłoszonych podatności zespół Storybook zdecydował o zmianie domyślnego zachowania Storybook (w tym wersji 8 oraz 9) w odniesieniu do funkcji sieciowych, które nie są niezbędne dla pracy większości użytkowników. Dla zespołów korzystających z tych funkcji dodano flagi funkcjonalne (feature flags), które umożliwiają wyłączenie określonych mechanizmów bezpieczeństwa w celu zachowania istniejących procesów.

Należy dokładnie zapoznać się z wprowadzonymi flagami oraz konsekwencjami ich użycia:

• Domyślne wyłączenie osadzania w ramkach iframe przez sieć: Storybook nie pozwala już na osadzanie managera ani podglądu (preview) wewnątrz elementów iframe na witrynach o innej nazwie hosta. Zbudowane wersje Storybook nie są objęte tą zmianą i mogą być swobodnie osadzane. W przypadku konieczności osadzania serwera deweloperskiego przez osobną aplikację webową należy uruchomić ją na localhost. Można także użyć flagi security.insecureRemoteIframeEmbed, aby ponownie zezwolić na osadzanie w ramkach z dowolnego źródła.
• Odrzucanie przez ramkę preview wiadomości od nieznanych hostów: Zarówno preview, jak i manager Storybook ograniczają obecnie pochodzenie (origin) ramek iframe i okien nadrzędnych, z którymi mogą wymieniać wiadomości za pośrednictwem API postMessage. Domyślnie Storybook w trybie deweloperskim akceptuje komunikację wyłącznie z własnym źródłem oraz innymi usługami localhost. Zbudowane wersje Storybook nadal akceptują komunikację z nieznanych źródeł. Jeśli dany dodatek lub integracja wykorzystuje postMessage do modyfikowania argumentów historii na żywo, zaleca się kontakt z zespołem Storybook w celu wypracowania bezpiecznych rozwiązań. Kompozycja Storybook również bazuje na postMessage, przez co skomponowany Storybook z innego źródła nie załaduje się, o ile nie został wcześniej zbudowany. Flaga security.insecureIframeMessaging wyłącza to zabezpieczenie, jednak rekomendowanym podejściem jest budowanie skomponowanych instancji.
• Zmiana sygnatury zdarzenia highlight: Wbudowany dodatek ułatwień dostępu (accessibility) Storybook używa zdarzenia highlight do wstrzykiwania w podglądzie klikalnych wyróżnień, które otwierają menu z linkiem do dokumentacji. API tego zdarzenia było zbyt permisywne i mogło zostać wykorzystane do wywoływania dowolnych zdarzeń, w tym przetwarzanych przez lokalny serwer deweloperski. API zostało zmodyfikowane w celu zapobiegania nadużyciom. Oprócz dodatku ułatwień dostępu, z interfejsu tego korzysta dodatek Visual Tests od Chromatic do linkowania dokumentacji z wyróżnionych ignorowanych elementów. Aby zachować działanie tych linków, należy zaktualizować dodatek Visual Tests do wersji 5.5.1 lub nowszej. Ponieważ według wiedzy autorów żadne inne dodatki nie używają tego API, nie wprowadzono flagi przywracającej stare zachowanie.

Oś czasu ujawnienia

30th września zespół Storybook otrzymał zgłoszenie w ramach odpowiedzialnego ujawniania podatności, opisujące możliwość osadzenia ramki preview serwera deweloperskiego przez złośliwą stronę oraz wysyłania zdarzeń do serwera na maszynie dewelopera.

Informacje te połączono z ustaleniami z trwającego audytu bezpieczeństwa, co pozwoliło opracować najgorszy możliwy scenariusz wykorzystania podatności (uwzględniający również luki odkryte niezależnie). Następnie wdrożono poprawki na wszystkich etapach wymaganych do realizacji takiego ataku. Nie odnotowano dowodów na wykorzystanie podatności w rzeczywistych projektach Storybook. Przedstawiony scenariusz ataku wymaga pomyślnego wykorzystania ciągu wielu luk, z których część nie była wcześniej zgłoszona zespołowi Storybook.

Najgorszy scenariusz ataku

Kontrolowana przez atakującego witryna internetowa może wchodzić w interakcję z podglądem uruchomionego serwera deweloperskiego Storybook. Przy udziale interakcji użytkownika może to doprowadzić do wprowadzenia przez serwer deweloperski nieautoryzowanych zmian w plikach historii. W przypadku późniejszego wykonania złośliwego pliku przez lokalne środowisko uruchomieniowe atak może skutkować wykonaniem dowolnego kodu z uprawnieniami dewelopera.