Co znajdziesz w tym artykule?
Wprowadzenie do problemu
Bezpieczeństwo aplikacji wykorzystujących modele językowe coraz częściej zależy nie tylko od ochrony danych użytkowników, ale również od prawidłowego zarządzania kluczami API, tokenami i pośrednimi mechanizmami autoryzacji. Najnowsza analiza aplikacji AI dla iPhone’a pokazuje, że wiele produktów mobilnych nadal wdraża integrację z usługami LLM w sposób, który umożliwia nadużycia finansowe i techniczne.
Problem dotyczy przede wszystkim umieszczania poświadczeń po stronie klienta, niewłaściwie zabezpieczonych backendów oraz tokenów, które można przechwycić i wykorzystać ponownie. W praktyce oznacza to, że atakujący może uzyskać dostęp do płatnych usług modeli i generować koszty po stronie dostawcy aplikacji.
W skrócie
- Badacze przeanalizowali 444 aplikacje chatbotów AI dla iPhone’a.
- 282 z nich ujawniały dostęp do płatnych usług LLM poprzez ruch sieciowy.
- Wykryto jawne klucze API, otwarte backendy pośredniczące oraz podatne tokeny sesyjne.
- Po trzech miesiącach od zgłoszenia tylko część aplikacji została jednoznacznie zabezpieczona.
- Zjawisko wpisuje się w trend nadużyć określanych jako LLMjacking.
Kontekst i historia
Opisywane badanie zostało przedstawione jako pierwsza pogłębiona analiza tego problemu w ekosystemie iOS. Zespół badawczy skupił się na aplikacjach dostępnych w amerykańskim App Store pod koniec 2025 roku, analizując ich komunikację sieciową bez potrzeby jailbreaku urządzenia czy pełnej inżynierii wstecznej.
To ważna obserwacja, ponieważ pokazuje, że przechwycenie wrażliwych danych nie wymagało zaawansowanych technik. W wielu przypadkach wystarczała analiza zwykłego ruchu między aplikacją, serwerem pośredniczącym i dostawcą modeli językowych.
Choć podobne błędy były wcześniej opisywane w świecie Androida i szerzej w aplikacjach mobilnych, rozwój generatywnej AI zwiększył skalę ryzyka. Przejęty klucz API nie daje dziś wyłącznie dostępu do funkcji aplikacji, ale może bezpośrednio przekładać się na rosnące koszty usług obliczeniowych.
Analiza techniczna
Badacze podzielili 282 podatne aplikacje na trzy główne kategorie. Pierwsza obejmowała 54 aplikacje, które ujawniały klucze API w postaci jawnego tekstu. Taki model wdrożenia oznacza klasyczny błąd architektoniczny: sekret umieszczony po stronie klienta przestaje być sekretem, ponieważ użytkownik lub atakujący może go przechwycić.
Druga grupa objęła 92 aplikacje, których backendy pośredniczące akceptowały żądania bez skutecznej weryfikacji klienta. W praktyce taki serwer działa jak otwarty przekaźnik do płatnego konta AI. Atakujący nie musi nawet zdobywać głównego klucza, jeśli może bez przeszkód korzystać z serwera aplikacji jako bramy do modelu.
Trzecia i najliczniejsza kategoria, obejmująca 136 aplikacji, wykorzystywała tokeny czasowe lub pośrednie poświadczenia, które miały ograniczać ryzyko. W praktyce również one pojawiały się w ruchu sieciowym i często mogły zostać ponownie użyte. Część z nich zachowywała ważność znacznie dłużej, niż deklarowano, co dodatkowo zwiększało powierzchnię ataku.
Dodatkowym problemem okazał się wyciek promptów systemowych. W części aplikacji wraz z kluczem lub tokenem można było pozyskać również ukryte instrukcje sterujące zachowaniem modelu. To oznacza ryzyko nie tylko finansowe, ale również ujawnienie logiki biznesowej, zasad moderacji i wewnętrznej architektury produktu.
Badanie objęło co najmniej dziesięciu dostawców usług AI i 13 kategorii aplikacji. Najwięcej podatnych przypadków wykryto w obszarze produktywności, a najwyższy odsetek wycieków odnotowano w kategorii zdrowie i fitness, co sugeruje problem systemowy, a nie jednostkowy.
Konsekwencje i ryzyko
Najbardziej bezpośrednim skutkiem jest przejęcie cudzego budżetu na usługi AI. Osoba dysponująca kluczem lub tokenem może wykonywać zapytania do modeli na koszt właściciela aplikacji, a przy zautomatyzowanym nadużyciu skala strat może szybko wzrosnąć.
Kolejne ryzyko dotyczy utraty kontroli nad backendem aplikacji. Jeśli serwer pośredniczący nie rozróżnia legalnych i nielegalnych żądań, może zostać wykorzystany do masowych zapytań, obchodzenia limitów, ukrywania źródła ruchu lub testów obciążeniowych.
Istotne są także skutki związane z własnością intelektualną. Ujawnienie promptów systemowych i reguł sterujących ułatwia klonowanie produktu, omijanie mechanizmów bezpieczeństwa oraz przygotowywanie bardziej precyzyjnych ataków na użytkowników końcowych.
Z perspektywy reputacyjnej problem może być szczególnie dotkliwy dla aplikacji działających w obszarach zdrowia, produktywności i usług konsumenckich. Utrata zaufania użytkowników może okazać się równie kosztowna jak same nadużycia finansowe.
Rekomendacje
Podstawową zasadą bezpieczeństwa powinno być całkowite usunięcie długoterminowych kluczy API z aplikacji klienckiej. Wszystkie wywołania do usług LLM powinny przechodzić przez kontrolowany backend, który egzekwuje tożsamość użytkownika, autoryzację, limity użycia oraz kontekst sesji.
Należy stosować krótkotrwałe tokeny o minimalnym zakresie uprawnień, ściśle powiązane z użytkownikiem, urządzeniem lub sesją. Kluczowe jest również egzekwowanie wygaśnięcia po stronie serwera, a nie tylko deklarowanie go w metadanych klienta.
Organizacje powinny wdrożyć aktywny monitoring wykorzystania sekretów i tokenów. Analiza anomalii w wolumenie ruchu, geolokalizacji, liczbie urządzeń i wzorcach użycia może pomóc w szybkim wykrywaniu nadużyć i wymusić natychmiastową rotację poświadczeń.
W praktyce warto prowadzić regularne testy bezpieczeństwa z perspektywy ruchu sieciowego aplikacji mobilnej. Jeśli poświadczenie można przechwycić podczas zwykłego użycia aplikacji, należy uznać je za skompromitowane i niepolegające na właściwym modelu zaufania.
Po wykryciu incydentu konieczna jest szybka rotacja kluczy, unieważnienie tokenów, przegląd logów oraz ocena, czy nie doszło już do nadużyć finansowych lub masowego wykorzystania przez nieautoryzowane podmioty.
Podsumowanie
Analiza 444 aplikacji AI dla iOS pokazuje, że bezpieczeństwo integracji z modelami językowymi pozostaje jednym z najsłabszych punktów wielu produktów mobilnych. Skala problemu jest znacząca, ponieważ 282 aplikacje ujawniały mechanizmy dostępu do płatnych usług LLM, a część deweloperów nie usunęła błędów nawet po odpowiedzialnym zgłoszeniu.
Najważniejszy wniosek jest jednoznaczny: sekret przesyłany lub ujawniany po stronie klienta nie może być traktowany jako bezpieczny. W architekturze mobilnej klucz lub token widoczny w ruchu sieciowym należy uznać za sekret utracony.