Naprawianie podatności na ataki Cross App Scripting (CAS)

Te informacje są przeznaczone dla deweloperów aplikacji, które zawierają lukę umożliwiającą ataki CAS.

O co chodzi?

Co najmniej jedna z Twoich aplikacji zawiera komponent WebView podatny na ataki CAS, co może umożliwiać złośliwym aplikacjom wykradanie plików cookie użytkowników, a także innych danych.Zapoznaj się z powiadomieniem w Konsoli Play.Po przekroczeniu terminów wskazanych w Konsoli Play wszystkie aplikacje z lukami w zabezpieczeniach mogą zostać usunięte z Google Play.

Wymagane działania​

1. Zaloguj się w Konsoli Play i przejdź do sekcji Alerty, by sprawdzić, których aplikacji dotyczy problem i jaki jest termin jego rozwiązania.
2. Zaktualizuj te aplikacje i usuń lukę w zabezpieczeniach.
3. Prześlij zaktualizowane wersje tych aplikacji.

Do czasu rozpatrzenia Twojego zgłoszenia nowa aplikacja lub aktualizacja aplikacji będzie miała status Czeka na publikację. Jeśli nie została poprawnie zaktualizowana, ostrzeżenie nadal będzie się pojawiać.

Dodatkowe szczegóły

Elementy WebView, które włączają JavaScript i ładują dane pochodzące z niezaufanych intencji, mogą zostać wykorzystane przez złośliwe aplikacje do wykonania kodu JavaScript w niebezpiecznym kontekście. Aby zabezpieczyć aplikacje przed atakiem wykorzystującym tę lukę, skorzystaj z jednego z tych rozwiązań:

Opcja 1. Upewnij się, że działania, których dotyczy problem, nie są eksportowane

Znajdź wszystkie działania z podatnymi na ataki komponentami WebView. Jeśli te działania nie muszą korzystać z intencji z innych aplikacji, w swoim pliku manifestu dla tych działań możesz ustawić parametr android:exported=false. Dzięki temu złośliwe aplikacje nie będą mogły wysyłać szkodliwych danych do komponentów WebView w tych działaniach.

Opcja 2. Zabezpiecz komponenty WebView w wyeksportowanych działaniach

Jeśli chcesz wyeksportować działanie z podatnym na ataki komponentem WebView, zalecamy wprowadzenie tych zmian:

1. Zabezpiecz wywołania evaluateJavascript i loadUrl

   Upewnij się, że parametry do wykonania działania evaluateJavascript są zawsze zaufane. Wywołanie evaluateJavascript za pomocą niesprawdzonych danych wejściowych z niezaufanych intencji pozwala osobom przeprowadzającym atak na wykonanie złośliwych skryptów w podatnym na ataki komponencie WebView. Na podobnej zasadzie wywołania loadUrl przeprowadzone za pomocą niesprawdzonych danych wejściowych zawierających adresy URL według schematu javascript: również umożliwiają osobom przeprowadzającym atak wykonanie szkodliwych skryptów.

2. Zablokuj niebezpieczne ładowania plików

   Dopilnuj, aby podatne na ataki komponenty WebView nie mogły wczytywać baz danych z plikami cookie.Komponenty WebView, które ładują niesprawdzone adresy URL typu file:// z niezaufanych intencji, mogą paść ofiarą ataku ze strony szkodliwych aplikacji. Taki atak przebiega w dwóch etapach: Pierwszy etap: szkodliwa strona internetowa może zapisać tagi <script> w bazie danych z plikami cookie. Drugi etap: ten zmodyfikowany plik bazy danych z plikami cookie może zostać wczytany, jeśli szkodliwa aplikacja wyśle intencję z adresem URL typu file:// wskazującym Twoją bazę danych z plikami cookie w komponencie WebView lub jeśli sama szkodliwa strona przekierowuje komponent WebView do adresu URL z plikiem. Szkodliwy element <script> przechowywany w bazie danych z plikami cookie zostanie wczytany i wykonany, co może prowadzić do kradzieży informacji o sesji.

   Istnieją 3 sposoby blokowania wczytywania bazy danych z plikami cookie zawartej w komponentach WebView przez podatne na ataki komponenty WebView.

   1. Wyłącz dostęp do wszystkich plików
   2. Dopilnuj, aby komponent WebView wczytywał tylko adresy URL typu file://, i upewnij się, że wszystkie wczytywane adresy URL tego typu wskazują bezpieczne pliki. Pamiętaj, że osoba przeprowadzająca atak może użyć dowiązania symbolicznego, aby sfałszować wyniki sprawdzania ścieżki adresu URL. Aby uchronić się przed takim atakiem, sprawdź ścieżkę kanoniczną wszystkich niezaufanych adresów URL typu file://, zanim zostaną wczytane. Nie wystarczy samo sprawdzenie ścieżki adresu URL.
   3. Aby dopuścić zarówno adresy URL typu http://, jak i file://, zaimplementuj weryfikację adresu URL typu file:// za pomocą działań shouldOverrideUrlLoading i shouldInterceptRequest w komponencie WebViewClient. W ten sposób będziesz mieć pewność, że zweryfikowane są wszystkie adresy URL wczytane do komponentu WebView, a nie tylko te udostępnione w wywołaniu funkcji loadUrl().

Chętnie pomożemy
Jeśli masz pytania techniczne związane z tą luką, możesz je opublikować na Stack Overflow, używając tagu „android-security”. Jeśli potrzebujesz wyjaśnienia czynności niezbędnych do rozwiązania tego problemu, skontaktuj się z naszym zespołem pomocy dla deweloperów.