Ekspozycja manifestów dev

Ekspozycja manifestów dev to parametr monitoringu stron internetowych, który sprawdza, czy w katalogu głównym witryny serwer oddaje pliki composer.json albo package.json, czyli manifesty zależności projektu PHP i JavaScript. Pomiar kończy się jednym z trzech wyników: manifest dostępny, manifest niedostępny albo nie udało się uzyskać odpowiedzi. Plik composer.json opisuje pakiet i jego zależności według schematu Composera ^[1], a package.json pełni tę rolę w ekosystemie npm ^[3].

Jak działa

W composer.json pole name składa się z nazwy dostawcy i nazwy projektu rozdzielonych ukośnikiem, np. monolog/monolog ^[1]. Pole require to mapa pakietów wymaganych przez projekt, a require-dev wymienia pakiety potrzebne do rozwoju i testów ^[1]. W package.json zależności to obiekt, który przypisuje nazwie pakietu zakres wersji, np. ^version albo 1.2.x ^[3]. Pola name i version są wymagane przy publikacji pakietu, a w projekcie, który nie będzie publikowany, są opcjonalne ^[3].

Manifest podaje zakresy, plik blokady podaje dokładne wersje. Composer rozwiązuje zależności z composer.json i zapisuje wszystkie pakiety z dokładnymi wersjami do composer.lock ^[2]; dokumentacja zaleca dodanie tego pliku do repozytorium ^[2]. package-lock.json opisuje dokładne drzewo zainstalowanych pakietów, a przy każdym z nich podaje wersję i miejsce, z którego go pobrano ^[4].

RYS. 1.1Od manifestu do listy podatności

Standardy i specyfikacje

• Schemat composer.json definiuje pola manifestu Composera; name jest wymagane dla publikowanych bibliotek ^[1].
• Dokumentacja package.json opisuje zależności, zależności deweloperskie i pole private: przy ustawieniu "private": true npm odmówi publikacji pakietu ^[3].
• npm audit wysyła do rejestru opis zależności projektu i prosi o raport znanych podatności. Domyślnie wymaga pliku package-lock.json, a każde ostrzeżenie zawiera m.in. nazwę, powagę i pole vulnerable_versions ^[5].
• CWE-200 („Exposure of Sensitive Information to an Unauthorized Actor”) wymienia wśród informacji wrażliwych stan i środowisko systemu, np. system operacyjny i zainstalowane pakiety ^[6]. MITRE oznacza ten wpis jako niezalecany do przypisywania konkretnym podatnościom, bo opisuje skutek, a nie przyczynę ^[6].

Zagrożenia i skutki

Dopasowanie do znanych podatności. Nazwa pakietu i jego wersja to dane, które npm audit wysyła do rejestru, żeby dostać ostrzeżenia z zakresem podatnych wersji ^[5]. Kto odczyta manifest albo plik blokady z cudzego serwera, wykona to samo porównanie bez dostępu do kodu. Zakres z manifestu wskazuje wersję mniej dokładnie niż wpis w pliku blokady ^{[3] [4]}, więc dostępny composer.lock albo package-lock.json zdradza więcej niż sam manifest.

Mapa wtyczek i motywów. W projektach, które zarządzają WordPressem przez Composera, manifest wymienia rdzeń, wtyczki i motywy jako zależności. Szablon Bedrock instaluje w ten sposób np. pakiety roots/wordpress i wp-plugin/woocommerce ^[7]. Jednocześnie Bedrock wskazuje jako publiczny katalog główny podkatalog web, więc manifesty zostają poza drzewem serwera ^[7].

Skutek pośredni. Manifest nie daje dostępu do strony. Skraca rekonesans: zamiast zgadywać komponenty, napastnik dostaje ich listę.

RYS. 1.2Jak manifest trafia do sieci

Przykłady

Sytuacja	Plik pod adresem	Co ujawnia
Bedrock z katalogiem publicznym web [7]	brak	nic, manifesty poza drzewem serwera
Projekt Composera wdrożony w całości do katalogu WWW	composer.json	nazwy pakietów i zakresy wersji [1]
Jak wyżej, z plikiem blokady [2]	composer.lock	dokładne wersje wszystkich pakietów
Motyw budowany przez npm, package.json bez pola name [3]	package.json	zakresy wersji narzędzi i bibliotek
package-lock.json w katalogu WWW [4]	package-lock.json	wersja i źródło każdego pakietu w drzewie