Podatności LinkAce

LinkAce przed wersją 2.5.7 nie waliduje formatu URL w endpointcie Bulk Link API, co pozwala uwierzytelnionemu użytkownikowi zapisać URI `javascript:`. Zapisany URI jest później renderowany jako `href` w szablonach Blade, a kliknięcie go wykonuje dowolny kod JavaScript w przeglądarce ofiary, umożliwiając kradzież ciasteczek i tokenów sesji. Wersja 2.5.7 naprawia ten problem.

Podatność w LinkAce przed wersją 2.5.6 pozwala atakującemu na wstrzyknięcie złośliwych zmiennych konfiguracyjnych poczty podczas konfiguracji bazy danych, co prowadzi do zdalnego wykonania kodu przy wysyłaniu wiadomości e-mail.

LinkAce przed wersją 2.5.6 zawiera podatność na trwały atak XSS, która pozwala użytkownikowi z niskimi uprawnieniami na wykonanie dowolnego kodu JavaScript w sesji przeglądarki administratora. Atakujący może ustawić swoją nazwę wyświetlaną OAuth na złośliwy skrypt, a następnie utworzyć token API, co spowoduje umieszczenie trwałego ładunku XSS w dzienniku audytu. Gdy administrator przejdzie do /system/audit, ładunek wykonuje się w kontekście przeglądarki administratora.

LinkAce przed wersją 2.5.6 zawiera podatność Insecure Direct Object Reference (IDOR) w warstwie polityki autoryzacji. Umożliwia ona każdemu uwierzytelnionemu użytkownikowi modyfikację zasobów (linków, list, tagów, notatek) należących do innych użytkowników, zarówno przez interfejs webowy, jak i API REST. Problem wynika z błędnego sprawdzania dostępu w metodach update(), które zezwalają na edycję zasobów o widoczności publicznej lub wewnętrznej, ignorując własność.

LinkAce w wersjach przed 2.5.4 nie sprawdza prywatnych adresów IP w funkcjach LinkRepository::update i CheckLinksCommand::checkLink. Uwierzytelniony użytkownik może odczytać odpowiedzi z usług wewnętrznych (AWS IMDSv1, metadane chmury, wewnętrzne API), tworząc link z publicznym URL, a następnie zmieniając go na prywatny adres IP; zadanie cron links:check wykonuje żądanie po stronie serwera bez filtrowania IP. Może to ujawnić dane uwierzytelniające chmury, dane usług wewnętrznych i topologię sieci. Podatność naprawiono w wersji 2.5.4.

W LinkAce przed wersją 2.5.3 prywatna notatka dołączona do linku innego niż prywatny może zostać ujawniona innemu uwierzytelnionemu użytkownikowi przez interfejs webowy. API poprawnie egzekwuje widoczność notatek, ale strona szczegółów linku renderuje notatki bez równoważnego filtrowania.

LinkAce w wersjach 2.3.1 i starszych zawiera podatność Stored Cross-Site Scripting (XSS) w funkcji udostępniania w mediach społecznościowych. Uwierzytelniony użytkownik może wstrzyknąć dowolny JavaScript poprzez pole tytułu linku z złośliwym HTML. Kod wykonuje się w przeglądarce użytkownika przeglądającego szczegóły linku.

W LinkAce w wersjach 2.3.1 i niższych uwierzytelnione punkty końcowe RSS w klasie FeedController nie implementują prawidłowych kontroli autoryzacji. Umożliwia to każdemu uwierzytelnionemu użytkownikowi dostęp do wszystkich linków, list i tagów wszystkich użytkowników, niezależnie od ustawień własności lub widoczności. Problem naprawiono w wersji 2.4.0.

LinkAce to samo-hostowana archiwizacja linków. W wersjach 2.3.1 i starszych każdy uwierzytelniony użytkownik może wyeksportować całą bazę linków wszystkich użytkowników, w tym linki prywatne, które powinny być dostępne tylko dla właścicieli. Funkcje eksportu HTML i CSV w klasie ExportController pobierają wszystkie linki bez filtrowania własności lub widoczności, omijając mechanizmy kontroli dostępu. Problem naprawiono w wersji 2.4.0.

LinkAce to samodzielnie hostowane archiwum linków. W wersjach 2.3.0 i starszych funkcja htmlKeywordsFromUrl w klasie FetchController przyjmuje adresy URL podane przez użytkownika i wykonuje do nich żądania HTTP bez sprawdzania, czy cel nie jest zasobem wewnętrznym lub prywatnym. Luka SSRF pozwala uwierzytelnionym atakującym na skanowanie portów i odkrywanie usług w sieciach wewnętrznych; wpływ jest ograniczony, ponieważ funkcja wyodrębnia tylko zawartość tagów meta keywords. Problem naprawiono w wersji 2.4.0.