WebViews – niebezpieczne łączenie plików

Kategoria OWASP: MASVS-STORAGE: Storage

Przegląd

Ten dokument obejmuje kilka problemów związanych z dołączaniem plików, które mają podobne rozwiązania. Problemy te dotyczą luk w zabezpieczeniach wynikających z dostępu do plików w komponentach WebView i obejmują niebezpieczne WebSettings umożliwiające dostęp do plików lub włączanie JavaScriptu, a także metodę WebKit, która tworzy żądanie wyboru pliku. Ten dokument może być przydatny, jeśli szukasz wskazówek dotyczących rozwiązywania problemów w WebView wynikających z użycia schematu file://, nieograniczonego dostępu do plików lokalnych i ataków typu cross-site scripting.

Ten dokument obejmuje te tematy:

  • WebSettings to klasa zawierająca metody, które zarządzają stanami ustawień komponentów WebView. Metody te mogą narażać komponenty WebView na różne ataki, które zostaną opisane później. W tym dokumencie przyjrzymy się metodom związanym z dostępem do plików oraz ustawieniu, które umożliwia wykonywanie JavaScriptu:
  • Metody setAllowFileAccess, setAllowFileAccessFromFileURLs i setAllowUniversalAccessFromFileURLs mogą służyć do przyznawania dostępu do plików lokalnych za pomocą adresu URL ze schematem pliku (file://). Mogą one jednak zostać wykorzystane przez złośliwe skrypty do uzyskania dostępu do dowolnych plików lokalnych, do których aplikacja ma dostęp, np. do własnego folderu /data/. Z tego powodu, metody te zostały oznaczone jako niebezpieczne i wycofane w interfejsie API 30 na rzecz bezpieczniejszych alternatyw, takich jak WebViewAssetLoader.
  • Metoda setJavascriptEnabled może służyć do włączania wykonywania JavaScriptu w komponentach WebView. Powoduje to, że aplikacje są podatne na ataki typu XSS na poziomie pliku. Szczególnie gdy jest skonfigurowana tak, aby zezwalać na wczytywanie plików lokalnych lub niezaufanych treści internetowych, które mogą zawierać kod wykonywalny, lub gdy jest skonfigurowana tak, aby zezwalać na dostęp do plików, które mogą być tworzone lub zmieniane przez źródła zewnętrzne, lub gdy zezwala na wykonywanie JavaScriptu w komponentach WebView, użytkownicy i ich dane są narażeni na ryzyko.
  • WebChromeClient.onShowFileChooser to metoda należąca do pakietu android.webkit, która udostępnia narzędzia do przeglądania internetu. Ta metoda może służyć do umożliwienia użytkownikom wybierania plików w WebView. Ta funkcja może jednak zostać wykorzystana, ponieważ komponenty WebView nie wymuszają ograniczeń dotyczących tego, który plik jest wybierany.

Wpływ

Wpływ dołączania plików może zależeć od tego, które ustawienia WebSettings są skonfigurowane w WebView. Zbyt szerokie uprawnienia do plików mogą umożliwić osobom przeprowadzającym atak dostęp do plików lokalnych i kradzież danych wrażliwych, informacji umożliwiających identyfikację (PII) lub prywatnych danych aplikacji. Włączenie wykonywania JavaScriptu może umożliwić osobom przeprowadzającym atak uruchamianie JavaScriptu w WebView lub na urządzeniu użytkownika. Pliki wybrane za pomocą metody onShowFileChooser mogą naruszyć bezpieczeństwo użytkownika, ponieważ metoda ani WebView nie mogą zapewnić, że źródło pliku jest zaufane.

Ryzyko: ryzykowny dostęp do plików przez file://

Włączenie setAllowFileAccess, setAllowFileAccessFromFileURLs i setAllowUniversalAccessFromFileURLs może umożliwić złośliwym intencjom i żądaniom WebView z kontekstem file:// dostęp do dowolnych plików lokalnych, w tym plików cookie WebView i prywatnych danych aplikacji. Ponadto użycie metody onShowFileChooser może umożliwić użytkownikom wybieranie i pobieranie plików z niezaufanych źródeł.

W zależności od konfiguracji aplikacji wszystkie te metody mogą prowadzić do wycieku danych osobowych, danych logowania lub innych danych wrażliwych.

Środki zaradcze

Sprawdzanie poprawności adresów URL plików

Jeśli Twoja aplikacja wymaga dostępu do plików za pomocą adresów URL file://, ważne jest, aby zezwalać tylko na określone adresy URL, które są uznawane za prawidłowe, i unikać typowych błędów.

Używanie WebViewAssetLoader

Zamiast wymienionych metod użyj WebViewAssetLoader. Ta metoda używa schematu http(s)//: zamiast schematu file:// do uzyskiwania dostępu do zasobów lokalnego systemu plików i nie jest podatna na opisany atak.

Kotlin

val assetLoader: WebViewAssetLoader = Builder()
  .addPathHandler("/assets/", AssetsPathHandler(this))
  .build()

webView.setWebViewClient(object : WebViewClientCompat() {
  @RequiresApi(21)
  override fun shouldInterceptRequest(view: WebView?, request: WebResourceRequest): WebResourceResponse {
    return assetLoader.shouldInterceptRequest(request.url)
  }

  @Suppress("deprecation") // for API < 21
  override fun shouldInterceptRequest(view: WebView?, url: String?): WebResourceResponse {
    return assetLoader.shouldInterceptRequest(Uri.parse(url))
  }
})

val webViewSettings: WebSettings = webView.getSettings()
// Setting this off for security. Off by default for SDK versions >= 16.
webViewSettings.allowFileAccessFromFileURLs = false
// Off by default, deprecated for SDK versions >= 30.
webViewSettings.allowUniversalAccessFromFileURLs = false
// Keeping these off is less critical but still a good idea, especially if your app is not
// using file:// or content:// URLs.
webViewSettings.allowFileAccess = false
webViewSettings.allowContentAccess = false

// Assets are hosted under http(s)://appassets.androidplatform.net/assets/... .
// If the application's assets are in the "main/assets" folder this will read the file
// from "main/assets/www/index.html" and load it as if it were hosted on:
// https://appassets.androidplatform.net/assets/www/index.html
webView.loadUrl("https://appassets.androidplatform.net/assets/www/index.html")

Java

final WebViewAssetLoader assetLoader = new WebViewAssetLoader.Builder()
         .addPathHandler("/assets/", new AssetsPathHandler(this))
         .build();

webView.setWebViewClient(new WebViewClientCompat() {
    @Override
    @RequiresApi(21)
    public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
        return assetLoader.shouldInterceptRequest(request.getUrl());
    }

    @Override
    @SuppressWarnings("deprecation") // for API < 21
    public WebResourceResponse shouldInterceptRequest(WebView view, String url) {
        return assetLoader.shouldInterceptRequest(Uri.parse(url));
    }
});

WebSettings webViewSettings = webView.getSettings();
// Setting this off for security. Off by default for SDK versions >= 16.
webViewSettings.setAllowFileAccessFromFileURLs(false);
// Off by default, deprecated for SDK versions >= 30.
webViewSettings.setAllowUniversalAccessFromFileURLs(false);
// Keeping these off is less critical but still a good idea, especially if your app is not
// using file:// or content:// URLs.
webViewSettings.setAllowFileAccess(false);
webViewSettings.setAllowContentAccess(false);

// Assets are hosted under http(s)://appassets.androidplatform.net/assets/... .
// If the application's assets are in the "main/assets" folder this will read the file
// from "main/assets/www/index.html" and load it as if it were hosted on:
// https://appassets.androidplatform.net/assets/www/index.html
webview.loadUrl("https://appassets.androidplatform.net/assets/www/index.html");

Wyłączanie niebezpiecznych metod WebSettings

Wartość metody setAllowFileAccess() jest domyślnie ustawiona na TRUE w interfejsie API 29 i starszych oraz na FALSE w interfejsie API 30 i nowszych. Metody setAllowFileAccessFromFileURLs() i setAllowUniversalAccessFromFileURLs() są domyślnie ustawione na FALSE w interfejsie API 16 i nowszych. (Te ustawienia domyślne zostały zmienione w interfejsie API 16, aby wymusić większe bezpieczeństwo przez ograniczenie dostępu do plików lokalnych z tej samej domeny, co chroni aplikacje przed potencjalnymi atakami typu cross-site scripting (XSS) i nieautoryzowanym dostępem do plików).

Jeśli trzeba skonfigurować inne ustawienia WebSettings, najlepiej wyraźnie wyłączyć te metody, zwłaszcza w przypadku aplikacji kierowanych na interfejsy API w wersji 29 lub starszej.

Ryzyko: ataki typu XSS na poziomie pliku

Ustawienie metody setJavacriptEnabled na TRUE umożliwia wykonywanie JavaScriptu w WebView, a w połączeniu z włączonym dostępem do plików, jak opisano wcześniej, możliwe jest przeprowadzenie ataku typu XSS na poziomie pliku przez wykonanie kodu w dowolnych plikach lub złośliwych witrynach otwartych w WebView.

Środki zaradcze

Blokowanie wczytywania plików lokalnych przez komponenty WebView

Podobnie jak w przypadku poprzedniego ryzyka, można uniknąć ataków typu XSS na poziomie pliku, jeśli metody setAllowFileAccess(), setAllowFileAccessFromFileURLs() i setAllowUniversalAccessFromFileURLs() są ustawione na FALSE.

Blokowanie wykonywania JavaScriptu przez komponenty WebView

Ustaw metodę setJavascriptEnabled na FALSE, aby JavaScript nie mógł być wykonywany w komponentach WebView.

Upewnij się, że komponenty WebView nie wczytują niezaufanych treści

Czasami włączenie tych ustawień jest konieczne w komponentach WebView. W takim przypadku ważne jest, aby wczytywać tylko zaufane treści. Ograniczenie wykonywania JavaScriptu tylko do tego, nad którym masz kontrolę, i niedozwalanie na dowolny JavaScript to dobry sposób na zapewnienie, że treści są zaufane. W przeciwnym razie, uniemożliwienie wczytywania ruchu w postaci tekstu nieszyfrowanego zapewni, że komponenty WebView z niebezpiecznymi ustawieniami nie będą mogły wczytywać adresów URL HTTP. Można to zrobić albo w pliku manifestu, ustawiając android:usesCleartextTraffic na False, albo konfigurując Network Security Config, która zabrania ruchu HTTP.

Zasoby