Podatności Apache Wicket

Apache Wicket generuje kod JavaScript odwołujący się do renderowanych elementów, umieszczając w literałach tekstowych w pojedynczych cudzysłowach wartości markup id oraz nazwy pól formularza bez odpowiedniego escapowania. Wartość zawierająca apostrof lub backslash może przerwać literał, a następnie wstrzyknąć kod wykonywany w kontekście aplikacji przy załadowaniu strony. Problem dotyczy wicket-core oraz wicket-extensions w wersjach 8.0.0–8.19.0, 9.0.0–9.24.0 i 10.0.0–10.11.0.

Apache Wicket w wersjach 10.10.0, 10.11.0 i 9.24.0 nie ustawia nagłówków Content-Security-Policy na stronach, których procedura obsługi żądania renderowania jest opakowana w więcej niż jeden IRequestHandlerDelegate. Framework odpakowuje tylko jeden poziom delegata przy podejmowaniu decyzji o renderowaniu strony, więc przy głębszym łańcuchu (np. delegujący mapper żądań aplikacji w połączeniu z CryptoMapper) strona jest serwowana bez nagłówka CSP, mimo że CSP jest włączone i nie jest zgłaszany żaden błąd ani ostrzeżenie. Ochrona oparta na nonce dla skryptów i stylów inline oraz inne skonfigurowane dyrektywy CSP są tracone dla tych stron, narażając je na wstrzyknięcie treści, któremu polityka miała zapobiegać. Aplikacje na standardowym Wicket, które same nie opakowują procedur obsługi żądań, nie są dotknięte. Wersje przed 10.10.0 i 9.24.0 obsługiwały zagnieżdżone delegaty poprawnie.

Podatność typu cross-site scripting (XSS) w Apache Wicket wynika z niewłaściwej neutralizacji danych wejściowych podczas generowania stron. Komponent ExternalLink, powiązany z elementem innym niż a, link lub area, wstawia URL z modelu do literału JavaScript w atrybucie onclick bez odpowiedniego escapowania, co pozwala na wykonanie złośliwego skryptu w kontekście aplikacji.

W Apache Wicket występuje błąd kolejności sprawdzeń: ścieżka pliku jest walidowana przez PackageResourceGuard zanim framework dołączy do niej atrybuty style, variation i locale. W rezultacie otwierany plik może być innym plikiem niż zatwierdzony przez guard, co pozwala na odczytanie szablonów HTML komponentów, których nazwy klas zawierają podkreślenie (np. Report_v2).

W Apache Wicket mechanizm PackageResourceGuard błędnie zezwala na serwowanie szablonów znaczników komponentów jako zasobów pakietowych, gdy wicket-core jest ładowany przez class loader, który nie widzi klas aplikacji. W takiej konfiguracji sprawdzenie obecności pliku klasy obok szablonu kończy się niepowodzeniem, a żądanie URL zasobu pakietowego zwraca szablon komponentu ze statusem 200. Ujawnieniu podlegają treści szablonów tworzone przez deweloperów, takie jak struktura komponentów, komentarze, skrypty inline i nazwy endpointów.

Podatność w Apache Wicket dotyczy zasobu AbstractFileUploadResource (serwerowa strona uploadu bez formularza z FileUploadToResourceField). Limity rozmiaru żądania, pojedynczego pliku i liczby części są pobierane z parametrów żądania (maxSize, fileMaxSize, fileCountMax) zamiast z konfiguracji aplikacji, więc klient może je dowolnie zawyżyć lub pominąć. Zasób nie ma adnotacji autoryzacyjnej, więc domyślnie żądanie nie wymaga uwierzytelnienia.

Podatność w Apache Wicket dotyczy komponentu FileUploadToResourceField, którego callback Ajax odczytuje parametr filesInfo bez powiązania go z rzeczywistym uploadem. Metoda UploadInfo#get() alokuje tablicę bajtów na podstawie rozmiaru podanego przez klienta, co pozwala na wyczerpanie sterty JVM pojedynczym żądaniem, a wartości ujemne powodują wyjątek NegativeArraySizeException.

Podatność w Apache Wicket dotyczy metody JavaScriptUtils#escapeQuotes(), która nie escapuje znaku backslash przed cudzysłowami. Wartość zawierająca backslash bezpośrednio przed cudzysłowem powoduje, że cudzysłów nie jest escapowany i zamyka literał JavaScript, umożliwiając wstrzyknięcie kodu JavaScript. Problem występuje, gdy aplikacja używa tej metody do osadzenia danych kontrolowanych przez atakującego w literale JavaScript, m.in. przez komponent AjaxEditableLabel.

Podatność typu cross-site scripting (XSS) w komponentach SmartLinkLabel i SmartLinkMultiLineLabel biblioteki Apache Wicket. Komponenty te zamieniają znalezione w tekście adresy URL w hiperłącza, akceptując dowolny schemat URL — w tym schematy wykonujące skrypt, takie jak javascript:. Eskapowanie wartości modelu nie chroni, ponieważ payload trafia do atrybutu href, a nie do tekstu elementu.

Podatność typu cross-site scripting (XSS) w Apache Wicket dotyczy zachowania AjaxNewWindowNotifyingBehavior, które zapisuje w stanie strony wartość window.name przesłaną przez klienta. Wartość ta jest później wstawiana bez escapowania do literału JavaScript w preconditions wywołania Ajax, co pozwala na wykonanie dowolnego skryptu w kontekście aplikacji przy każdym renderowaniu strony. Podatność występuje tylko w aplikacjach, które jawnie dodały to zachowanie do komponentu.

Apache Wicket zapisuje teksty z resource bundle (etykiety, nazwy klas CSS) do generowanego JavaScriptu i znaczników HTML bez odpowiedniego escapowania dla kontekstu. Tekst zawierający apostrof lub cudzysłów może przerwać literał lub atrybut, a następnie zostać zinterpretowany jako skrypt lub znacznik w origin aplikacji. Problem dotyczy m.in. MultiFileUploadField, Form, UploadProgressBar, FilterForm i TrapFocusBehavior w wersjach 8.0.0–8.19.0, 9.0.0–9.24.0 i 10.0.0–10.11.0.

W Apache Wicket występuje nieprawidłowa kolejność sprawdzeń bezpieczeństwa w ResourceIsolationRequestCycleListener — strona docelowa żądania jest tworzona przed sprawdzeniem polityk izolacji zasobów. W wyniku tego wyjątek RestartResponseAtInterceptPageException jest rzucany z wnętrza listenera, zanim polityki zostaną uruchomione, a żądanie z innego origin nie zostaje odrzucone. Dodatkowo zapisany URL docelowy (wraz z query stringiem) jest używany po zalogowaniu, co pozwala innemu origin wpłynąć na wartości pól formularza przekazywane do Form#onSubmit().

Podatność typu session fixation w Apache Wicket dotyczy klasy AuthenticatedWebSession i metody signIn(String, String). Identyfikator sesji jest odnawiany tylko przy pierwszym logowaniu, a nie przy ponownej autoryzacji już zalogowanej sesji, mimo że metoda zwraca true w obu przypadkach. Wykorzystanie wymaga umieszczenia przez atakującego wybranego identyfikatora sesji w przeglądarce ofiary, np. przez kontrolę hosta w tej samej domenie rejestrowanej lub konfigurację kontenera przenoszącego identyfikator sesji w URL.

Apache Wicket nie egzekwuje autoryzacji zasobów (isResourceAuthorized() ani adnotacji @AuthorizeResource) w komponentach ResourceLink, Image, ImageButton oraz AjaxDownloadBehavior, gdy zasób jest przekazany jako instancja IResource. W takim przypadku zasób jest serwowany bez sprawdzenia uprawnień, podczas gdy ta sama kontrola działa przy użyciu ResourceReference. Problem dotyczy też ExportToolbar, który buduje linki eksportu z instancji IResource.

W Apache Wicket brak autoryzacji pozwala na wywołanie listenera komponentu, dla którego strategia autoryzacji odmówiła akcji RENDER. Wystarczy spreparowany lub nawet standardowy URL listenera bez identyfikatora strony, przez co nie wykonuje się faza renderowania ani Component#configure(), a flaga widoczności pozostaje domyślna. Dotyczy to również komponentów ukrytych lub wyłączonych w Component#onConfigure().

Podatność w Apache Wicket polega na niewystarczającym wygasaniu sesji w obsłudze natywnych WebSocketów. Połączenie WebSocket przechowuje kopię sesji HTTP z momentu jego otwarcia, więc unieważnienie sesji przez kontener (timeout, wylogowanie, invalidate z filtra) nie kończy połączenia — kolejne ramki nadal korzystają z wygasłej tożsamości i jej atrybutów.

Apache Wicket nie sprawdza autoryzacji przed wywołaniem callbacków onMessage() w WebSocketBehavior. Komunikat wysłany przez klienta jest dostarczany do każdego WebSocketBehavior na stronie, nawet jeśli komponent, do którego jest przypisany, jest ukryty, wyłączony lub zabroniony przez IAuthorizationStrategy — w przeciwieństwie do zachowań Ajax, gdzie taka weryfikacja jest wykonywana.

W Apache Wicket w wersjach od 10.3.0 do 10.11.0 występuje brak autoryzacji przy przetwarzaniu formularzy. Formularz przyjmuje nazwę komponentu zatwierdzającego z parametrów żądania i przekazuje ją bezpośrednio do onFormSubmitted(), pomijając sprawdzenie widoczności i dostępności komponentu. W efekcie żądanie może wywołać akcje przycisku lub linku, który aplikacja ukryła lub zablokowała.

W Apache Wicket brakuje autoryzacji w obsłudze natywnych WebSocketów. Handler WebSocketMessageBroadcastHandler wywołuje WebSocketResource#onPayload() bez sprawdzenia IAuthorizationStrategy#isResourceAuthorized(), a adnotacja @AuthorizeResource nie działa. Wystarczy sesja Wicket i nazwa zasobu (ujawniana w stronie otwierającej połączenie), by wywołać wszystkie callbacki zasobu, w tym onConnect() i onMessage().

Apache Wicket w wersjach przed 1.5.12, 6.x przed 6.17.0 oraz 7.x przed 7.0.0-M3 może umożliwić zdalnym atakującym uzyskanie wrażliwych informacji poprzez identyfikatory używane do przechowywania znaczników stron dla tymczasowych sesji użytkowników.

Apache Wicket w wersjach 6.x przed 6.25.0, 7.x przed 7.5.0 oraz 8.0.0-M1 zawiera lukę w zabezpieczeniach, która nieprawidłowo obsługuje zapobieganie atakom CSRF, nie wykrywając niektórych żądań z innych źródeł. Problem dotyczy również braku sprawdzania niektórych celów po stronie serwera Wicket.

Apache Wicket w wersjach przed 1.5.13, 6.x przed 6.19.0 oraz 7.x przed 7.0.0-M5 ułatwia atakującym pokonanie mechanizmu ochrony kryptograficznej i przewidywanie zaszyfrowanych adresów URL, wykorzystując CryptoMapper jako domyślnego dostawcę szyfrowania.

Klasa DiskFileItem w Apache Wicket w wersjach 6.x przed 6.25.0 oraz 1.5.x przed 1.5.17 umożliwia zdalnym atakującym wywołanie odmowy usługi (nieskończona pętla) oraz zapis, przenoszenie i usuwanie plików z uprawnieniami DiskFileItem. Dodatkowo, jeśli działa na maszynie wirtualnej Java przed wersją 1.3.1, może wykonywać dowolny kod za pomocą spreparowanego zserializowanego obiektu Java.

W Apache Wicket wykryto podatność na cross-site scripting (XSS) w komponencie AbstractSingleSelectChoice (bazowym dla DropDownChoice). Domyślna opcja (null) jest zapisywana w markup bez escapowania, podczas gdy inne opcje są escapowane. Podatność dotyczy aplikacji, które nadpisują metody getNullValidDisplayValue() lub getNullKeyDisplayValue() i zwracają dane kontrolowane przez atakującego. Wersje od 8.0.0 do 8.18.0, od 9.0.0 do 9.23.0, od 10.0.0 do 10.10.0 są dotknięte.

W Apache Wicket wykryto podatność na cross-site scripting (XSS) w komponencie AbstractOptions (renderującym listy opcji w Palette). Atrybuty i wartości zwracane przez getAdditionalAttributes są zapisywane bez escapowania. Podatność dotyczy aplikacji, które nadpisują metody getAdditionalAttributesForChoices, getAdditionalAttributesForSelection lub getAdditionalAttributes i zwracają dane kontrolowane przez atakującego. Wersje od 8.0.0 do 8.18.0, od 9.0.0 do 9.23.0, od 10.0.0 do 10.10.0 są dotknięte.

W Apache Wicket w komponencie MetaDataHeaderItem nieprawidłowo neutralizowane są dane wejściowe podczas generowania stron. Atrybuty wartości w tagach <meta> i <link> nie są poprawnie escapowane, co pozwala na wstrzyknięcie dodatkowych atrybutów. Problem dotyczy wersji od 8.0.0 do 8.18.0, od 9.0.0 do 9.23.0 oraz od 10.0.0 do 10.10.0.

W Apache Wicket tag <wicket:label> jest renderowany bez escapowania, co pozwala na wstrzyknięcie znaczników HTML, jeśli etykieta pochodzi z modelu zawierającego dane kontrolowane przez atakującego. Problem dotyczy wersji od 8.0.0 do 8.18.0, od 9.0.0 do 9.23.0 oraz od 10.0.0 do 10.10.0.

Podatność XSS w Apache Wicket dotyczy komponentu Button renderowanego jako element <button>. Konstruktor czyści flagę escape-model-strings, przez co model nie jest kodowany przy zapisie do treści elementu, co pozwala na wstrzyknięcie znaczników HTML.

Podatność XSS w Apache Wicket dotyczy komponentów AjaxEditableChoiceLabel, AjaxEditableLabel i AjaxEditableMultiLineLabel. Wartości wyświetlane przez etykiety nie są poprawnie escapowane, co pozwala atakującemu na wstrzyknięcie HTML lub skryptów. Problem występuje w wersjach 8.0.0-8.18.0, 9.0.0-9.23.0 oraz 10.0.0-10.10.0.

Podatność w Apache Wicket dotyczy mechanizmu ochrony przed CSRF (ResourceIsolationRequestCycleListener). Domyślna polityka FetchMetadataResourceIsolationPolicy błędnie zezwala na proste nawigacje top-level oraz żądania same-site, co pozwala atakującemu na wywołanie akcji (np. listenerów komponentów) w kontekście uwierzytelnionej sesji ofiary. Problem występuje w wersjach 9.1.0–9.23.0 oraz 10.0.0–10.10.0.

Podatność w Apache Wicket pozwala na obejście limitów rozmiaru i liczby przesyłanych plików, gdy żądanie multipart jest już wcześniej przetworzone przez inny komponent (np. filtr). Wicket wtedy odczytuje pliki przez HttpServletRequest#getParts() bez stosowania limitów per-plik i limitu liczby plików, co umożliwia przesłanie większych lub liczniejszych plików niż dozwolone. Dodatkowo część bez nagłówka Content-Type jest w całości wczytywana do pamięci, co może prowadzić do nadmiernego zużycia zasobów.

Podatność w Apache Wicket pozwala nieuwierzytelnionemu atakującemu na odczyt plików z aplikacji webowej, w tym plików z katalogu WEB-INF, które normalnie nie są serwowane. Atak wykorzystuje nieprawidłową walidację atrybutów URL zasobów pakietu, które są wstawiane do ścieżki wyszukiwania bez sprawdzenia separatorów ścieżki.

Podatność w Apache Wicket polegająca na użyciu niewystarczająco losowych wartości oraz awarii mechanizmu ochrony. Dotyczy wersji od 9.0.0 do 9.23.0 oraz od 10.0.0 do 10.9.0. Zalecana jest aktualizacja do wersji 10.10.0.

Podatność na Cross-Site Scripting (XSS) w Apache Wicket spowodowana niewłaściwą neutralizacją danych wejściowych podczas generowania stron. Dotyczy wersji od 9.0.0 do 9.23.0 oraz od 10.0.0 do 10.9.0. Zalecana jest aktualizacja do wersji 10.10.0.

W Apache Wicket komponent FolderUploadsFileManager nie waliduje ani nie sanityzuje parametru uploadFieldId ani clientFileName przed budowaniem ścieżek plików. Umożliwia to nieuwierzytelnionemu atakującemu zapis dowolnych plików poza katalogiem docelowym lub odczyt plików z dowolnych lokalizacji na serwerze. Podatność dotyczy wersji 8.0.0–8.17.0, 9.0.0–9.22.0 i 10.0.0–10.8.0.

W Apache Wicket występuje podatność na ujawnienie wrażliwych informacji osobom nieuprawnionym. Dotyczy to wersji od 8.0.0 do 8.17.0, od 9.0.0 do 9.22.0 oraz od 10.0.0 do 10.8.0.

Apache Wicket zawiera podatność typu Cross-site Scripting (XSS) wynikającą z niewłaściwej neutralizacji danych wejściowych podczas generowania stron WWW. Problem dotyczy wersji od 8.0.0 do 8.17.0, 9.0.0 oraz od 10.0.0 do 10.8.0.