Tysiące aplikacji na Androida nadal otwierają furtkę dla nieszyfrowanego HTTP — analiza 189 779 aplikacji wykazała, że 33,74% wyłącza domyślną blokadę, a jedna biblioteka reklamowa przesyła reklamy jawnym tekstem

63 868 aplikacji na Androida zrobiło coś, czego współczesny system operacyjny domyślnie próbuje uniknąć: zezwoliło na nieszyfrowany ruch HTTP do wszystkich domen. To 33,74% aplikacji, dla których badaczom udało się odczytać konfigurację sieciową. Jeszcze szerszy wynik jest bardziej niepokojący — 84 032 aplikacje, czyli 44,40%, dopuszczały HTTP przynajmniej do jednej domeny.

Problem nie sprowadza się do starych programów, które od lat nie dostały aktualizacji. Analiza objęła 189 779 aplikacji z Google Play, a zaledwie 0,07% badanego zbioru celowało w poziomy API 27 lub niższe, czyli sprzed wprowadzenia obecnej polityki HTTPS-by-default. W części aplikacji wyłączenie ochrony było więc świadomą konfiguracją albo skutkiem zależności i SDK, które wymusiły poluzowanie zasad.

To ważne, bo HTTP nie zapewnia ani poufności przesyłanych danych, ani ochrony przed ich modyfikacją po drodze. W przypadku WebView konsekwencje są jeszcze poważniejsze. Użytkownik często nie widzi paska adresu, kłódki ani żadnej informacji pozwalającej odróżnić prawidłowy ekran aplikacji od treści podmienionej przez napastnika.

Co dokładnie znaleziono w 189 779 aplikacjach

Badacze zbudowali narzędzie WEBVIEWTRACE i wykorzystali je do analizy aplikacji pobranych z Google Play. Statyczne badanie manifestów udało się przeprowadzić dla 189 280 aplikacji, czyli 99,74% całego zbioru. Analizę bytecode’u wykonano dla 188 069 aplikacji, a pełny etap statyczny zakończył się powodzeniem dla 187 979 programów.

Najważniejsze wyniki konfiguracji sieciowej wyglądają następująco:

• 63 868 aplikacji — 33,74% — dopuszczało HTTP do wszystkich domen;

• 84 032 aplikacje — 44,40% — pozwalały na HTTP co najmniej do jednej domeny;

• pod koniec 2025 r. 55,60% aplikacji blokowało ruch jawnym tekstem do wszystkich domen;

• dla porównania wcześniejsze badanie z 2020 r. wykazało taką pełną blokadę jedynie w około 33% aplikacji.

Jest więc postęp, ale tempo zmian trudno uznać za satysfakcjonujące. Android od wersji 9, czyli API 28, domyślnie ustawia cleartextTrafficPermitted="false" w aplikacjach kierowanych na ten lub nowszy poziom API. Programista nie musi dodatkowo „włączać HTTPS”. Jeśli chce korzystać z HTTP, musi zrobić wyjątek.

I właśnie w tych wyjątkach pojawia się problem.

Najczęściej zezwolenia dotyczyły adresów używanych przy lokalnym developmentcie. 127.0.0.1 występował w 19 148 aplikacjach, localhost w 2419, a host emulatora 10.0.2.2 w 1340. Taka konfiguracja może mieć sens w wersji developerskiej. W wydaniu produkcyjnym pozostawienie jej bez potrzeby oznacza jednak zbędne powiększenie powierzchni ataku.

Poza adresami lokalnymi badacze znaleźli m.in. zezwolenia dotyczące amazon-adsystem.com w 1434 aplikacjach i endpointu systemu raportowania awarii Tencent Bugly w 472 aplikacjach. To dobry przykład typowego problemu z aplikacjami mobilnymi: konfiguracji sieciowej nie determinuje już wyłącznie własny backend producenta. Wpływają na nią również reklamy, analityka, raportowanie błędów, moduły płatności i inne biblioteki dostarczane przez podmioty trzecie.

Szczególnie niebezpieczne jest ustawienie globalne, np. cleartextTrafficPermitted="true" w base-config. Jeden stary endpoint przestaje wtedy być wyjątkiem, a staje się powodem otwarcia HTTP dla całej aplikacji. To wygodne podczas naprawiania problemu „Cleartext HTTP traffic not permitted”, ale z punktu widzenia bezpieczeństwa jest kiepskim skrótem.

Badanie ujawniło jeszcze bardziej prozaiczny błąd. W 42 aplikacjach znaleziono niepoprawne wartości parametru cleartextTrafficPermitted. Parser Androida okazał się bardzo liberalny: wartości, które nie są poprawnym zapisem false, mogą zostać potraktowane jak true. Autorzy znaleźli m.in. FALSE, 0, tekst trust oraz nierozwiązane placeholdery.

To jeden z tych błędów, które podczas przeglądu kodu wyglądają niewinnie, a w działającej aplikacji odwracają sens całego zabezpieczenia.

WebView zwiększa ryzyko, bo aplikacja może przestać zachowywać się jak bezpieczna przeglądarka

Samo zezwolenie na HTTP nie dowodzi jeszcze, że aplikacja faktycznie wysyła nieszyfrowany ruch. Dlatego badacze nie zatrzymali się na analizie plików konfiguracyjnych.

Z grupy programów wykorzystujących WebView i dopuszczających HTTP do wszystkich domen wybrano 35 000 aplikacji do analizy dynamicznej. Pełny proces zakończył się powodzeniem w przypadku 34 200.

W 25 186 z nich udało się podczas testów wywołać API WebView. W 2790 aplikacjach rzeczywiście zaobserwowano ruch HTTP wychodzący z WebView przez interfejs sieciowy. Stanowiło to 11,08% programów korzystających z WebView i jednocześnie dopuszczających HTTP globalnie.

To wynik szczególnie istotny, bo zwykła przeglądarka i WebView nie dają użytkownikowi tego samego poziomu kontroli. Chrome, Firefox czy Brave pokazują adres strony i sygnalizują problemy z bezpieczeństwem połączenia. WebView jest częścią interfejsu aplikacji. Ekran logowania, reklama, formularz czy komunikat wyglądają jak element programu, nawet gdy ich zawartość została pobrana z sieci.

Jeżeli taka treść idzie przez HTTP, osoba kontrolująca fragment połączenia — przykładowo złośliwy punkt dostępowy Wi-Fi albo urządzenie wykonujące atak typu man-in-the-middle — może nie tylko zobaczyć odpowiedź serwera, lecz także próbować ją zmienić przed dotarciem do telefonu.

W praktyce groźniejsze od samego podsłuchu jest właśnie wstrzykiwanie treści. Można podmienić:

• formularz logowania,

• odnośnik prowadzący do serwisu płatniczego,

• fragment JavaScript,

• obraz lub reklamę,

• adres następnego zasobu pobieranego przez WebView,

• komunikat nakłaniający użytkownika do wykonania określonej czynności.

Do tego dochodzi Mixed Content Policy. Jej zadaniem jest ograniczanie sytuacji, w których bezpieczna strona HTTPS dołącza zasób pobrany przez HTTP. Spośród testowanych aplikacji używających WebView i zezwalających globalnie na HTTP aż 69,96% dopuszczało co najmniej pasywną treść mieszaną albo całkowicie ją zezwalało.

Dokładniej: 3312 aplikacji, czyli 13,15%, pozwalało na wszystkie typy mixed content, również skrypty, iframe’y i arkusze stylów. Kolejne 15 578 aplikacji, czyli 61,85%, pracowało w trybie kompatybilności pozwalającym na część treści mieszanej.

To nie jest kosmetyczna różnica w ustawieniach. HTTP połączone z wykonywalnym JavaScriptem w WebView daje napastnikowi znacznie ciekawszy cel niż pojedynczy obrazek pobrany bez TLS.

Szczególną ostrożność trzeba zachować przy mostach JavaScript udostępniających funkcje aplikacji kodowi działającemu w WebView. Jeżeli zdalny skrypt można zmodyfikować, a jednocześnie otrzymuje on dostęp do metod natywnych, błąd transportowy przestaje być wyłącznie problemem warstwy sieciowej.

W europejskiej aplikacji przetwarzającej dane użytkownika dochodzi jeszcze aspekt organizacyjny. RODO w art. 32 wymaga zabezpieczeń adekwatnych do ryzyka i wskazuje szyfrowanie danych jako jeden ze środków technicznych. Sama obecność HTTP nie przesądza automatycznie o naruszeniu przepisów, ale przesyłanie tą drogą identyfikatorów, danych konta czy innych danych osobowych wymaga już konkretnej oceny bezpieczeństwa, a nie stwierdzenia „to tylko jeden stary endpoint”.

Biblioteka reklamowa może osłabić aplikację bez dotykania jej własnego backendu

Najciekawszy fragment badania dotyczy sytuacji, w której źródłem ryzyka nie jest kod napisany przez autora aplikacji, lecz zewnętrzny SDK reklamowy.

Badacze przeanalizowali DT Exchange SDK, wcześniej znany jako Fyber SDK. Biblioteka wykorzystuje metodę loadDataWithBaseURL() do renderowania reklam pobranych dynamicznie. Krytyczny jest sposób wyboru adresu bazowego: gdy aplikacja zezwala na ruch jawnym tekstem, SDK potrafi ustawić dla WebView bazę korzystającą ze schematu http://.

Efekt jest gorszy niż zwykłe pobranie pojedynczego obrazka bez TLS. Z punktu widzenia WebView cała reklama znajduje się wtedy w niezabezpieczonym kontekście HTTP. Ochrona przed mixed content przestaje działać tak, jak oczekiwałby programista.

W czasie pomiarów zaobserwowano reklamy dostarczane m.in. przez sieci Liftoff, Adform i Remerge, które w takim kontekście ładowały zasoby JavaScript również przez HTTP. Ruch inicjowany przez http://wv.inner-active.mobi wykryto w 290 aplikacjach.

DT Exchange udostępnia tryb Secure Only Mode, który ma ograniczać pobieranie reklam do bezpiecznych źródeł. Problem jest bardzo praktyczny: w analizowanej konfiguracji nie był to mechanizm działający domyślnie.

To dokładnie ten rodzaj zależności, który najłatwiej przeoczyć podczas typowego code review. Zespół sprawdza Retrofit, OkHttp, własne endpointy REST i widzi wszędzie https://. Aplikacja nadal może jednak uruchamiać WebView za pośrednictwem SDK, którego zachowanie zależy od globalnej polityki usesCleartextTraffic lub Network Security Configuration.

Co gorsza, mobilne reklamy nie zawsze są statycznym obrazkiem. Standard MRAID pozwala reklamom wykonywać interakcje powiązane z urządzeniem. W zależności od wersji i implementacji obejmuje to m.in. funkcje związane z zapisywaniem obrazu czy tworzeniem wydarzenia w kalendarzu. Jeśli kod reklamy jest pobierany przez niezabezpieczony kanał i może zostać podmieniony, trzeba analizować nie tylko treść reklamy, ale także uprawnienia oraz interfejsy dostępne dla kodu uruchomionego w WebView.

Dla zespołu utrzymującego aplikację oznacza to zmianę sposobu audytu. Nie wystarczy wyszukać w repozytorium ciągu http://. Część adresów jest generowana dynamicznie, zwracana przez serwer reklamowy albo ukryta wewnątrz skompilowanego SDK.

Praktyczna kolejność kontroli powinna być taka:

1. sprawdzić android:usesCleartextTraffic w finalnym, scalonym AndroidManifest.xml, a nie tylko w pliku manifestu modułu aplikacji;

2. przejrzeć network_security_config.xml, szczególnie base-config;

3. sprawdzić wszystkie domain-config z cleartextTrafficPermitted="true";

4. porównać konfigurację buildów debug, staging i release, aby wyjątek developerski nie trafił do produkcji;

5. uruchomić aplikację przez kontrolowany proxy i zarejestrować rzeczywisty ruch sieciowy;

6. przetestować ekrany zawierające WebView, reklamy, logowanie, płatności, formularze zgód i zewnętrzne materiały;

7. przejrzeć dokumentację każdego SDK, który tworzy WebView lub ładuje zdalną treść;

8. dopiero później usuwać pojedyncze domeny z allowlisty.

Najczęstszy błąd polega na wykonaniu punktu ósmego bez pierwszych siedmiu. Programista usuwa stary URL z kodu i uznaje problem za rozwiązany, choć base-config nadal pozwala na HTTP wszędzie, a biblioteka reklamowa sama wybiera niezabezpieczony schemat.

W aplikacji produkcyjnej globalne cleartextTrafficPermitted="true" powinno być traktowane jako konfiguracja wymagająca konkretnego, udokumentowanego uzasadnienia, a nie wygodny sposób na uciszenie błędu sieciowego. Jeżeli stary serwer naprawdę nie obsługuje TLS, lepszym rozwiązaniem przejściowym jest wyjątek ograniczony do jednej niezbędnej domeny. Następny krok to migracja tego endpointu do HTTPS i usunięcie wyjątku.

FAQ

Czy samo cleartextTrafficPermitted="true" oznacza, że aplikacja wysyła dane przez HTTP?
Nie. Ustawienie daje aplikacji możliwość wykonania takiego połączenia, ale nie dowodzi, że faktycznie do niego dochodzi. Dlatego konfigurację trzeba uzupełnić testem dynamicznym i przechwyceniem ruchu sieciowego.

Czy Android 9 i nowsze wersje automatycznie rozwiązują problem HTTP?
Nie, jeśli aplikacja sama wyłączy domyślną ochronę. Dla aplikacji kierowanych na API 28 lub wyższe Android domyślnie blokuje cleartext, ale programista może ponownie zezwolić na niego globalnie albo dla wybranych domen.

Czy wystarczy zamienić wszystkie adresy http:// na https:// w kodzie?
Nie. Adres może pochodzić z backendu, Remote Config, pliku konfiguracyjnego, biblioteki reklamowej albo innego SDK. Trzeba sprawdzić ruch działającej aplikacji, a nie tylko tekst występujący w repozytorium.

Czy HTTP jest niebezpieczne tylko wtedy, gdy przesyłane jest hasło lub numer karty?
Nie. Nieszyfrowaną odpowiedź można również modyfikować. W WebView pozwala to m.in. podmieniać elementy interfejsu, odnośniki i — przy niekorzystnej konfiguracji — kod JavaScript.

Czy dopuszczenie HTTP wyłącznie do localhost jest równie groźne jak globalne zezwolenie?
Nie. Zakres ryzyka jest znacznie mniejszy niż przy base-config cleartextTrafficPermitted="true". Mimo to wyjątek developerski powinien zostać usunięty z wersji produkcyjnej, jeśli aplikacja go nie potrzebuje.

Co sprawdzić najpierw w istniejącej aplikacji?
Finalny manifest wersji release i Network Security Configuration. Jeżeli znajduje się tam globalne zezwolenie na cleartext, właśnie od niego trzeba zacząć. Najpierw zmień politykę na blokującą HTTP, uruchom testy i zobacz, które funkcje faktycznie przestają działać. Dopiero wtedy twórz wąskie wyjątki dla konkretnych domen. To znacznie bezpieczniejsze niż utrzymywanie otwartej furtki dla całej aplikacji.

Pierwszy błąd do usunięcia to więc cleartextTrafficPermitted="true" ustawione globalnie bez bezwzględnej potrzeby. Nie zaczynaj od kosmetycznej wymiany pojedynczych URL-i. Najpierw zamknij możliwość HTTP dla całej aplikacji, sprawdź pod kontrolowanym proxy, co rzeczywiście wymaga wyjątku, a następnie zweryfikuj SDK reklamowe i wszystkie WebView.

Więcej informacji na: ANCHOR