Перейти к содержанию

Включена отладка WebView (remote debugging)

Критичность: СРЕДНИЙ
Способ обнаружения: DAST, WEBVIEW

Описание

Вызов WebView.setWebContentsDebuggingEnabled(true) включает удалённую отладку содержимого WebView. После этого к WebView на устройстве можно подключиться с компьютера через chrome://inspect (протокол Chrome DevTools) и инспектировать DOM, cookies, локальное хранилище, сетевые запросы, а также исполнять произвольный JavaScript в контексте страницы. Эта настройка предназначена для разработки, но нередко остаётся включённой в production-сборках.

Важно: метод статический и действует на весь процесс — один вызов setWebContentsDebuggingEnabled(true) делает отлаживаемыми все WebView приложения.

Пример небезопасного кода:

// включено безусловно — остаётся активным в release-сборке
WebView.setWebContentsDebuggingEnabled(true);

Проблема

  1. Инспекция и изменение содержимого. Через DevTools злоумышленник с доступом к устройству (в том числе по ADB) может просматривать и изменять DOM, перехватывать данные, исполнять JavaScript в контексте приложения.
  2. Доступ к чувствительным данным. Cookies, токены, локальное хранилище, содержимое форм и сетевой трафик WebView становятся доступны для просмотра.
  3. Обход клиентской логики и реверс-инжиниринг. Включённая отладка облегчает анализ и обход проверок, выполняемых в веб-части приложения.

Рекомендации

  1. Привязывайте включение отладки строго к debug-сборке. Никогда не вызывайте метод с безусловным true: 

    if (BuildConfig.DEBUG) {
    WebView.setWebContentsDebuggingEnabled(true);
}

  2. Задавайте флаг централизованно и один раз (например, в Application.onCreate()), опираясь на тип сборки, чтобы исключить «забытые» включения в отдельных экранах. Поскольку настройка глобальна на процесс, единая точка управления надёжнее разрозненных вызовов.

  3. В release-сборке метод не должен вызываться с true вообще. Не полагайтесь на runtime-условия из внешних источников (конфиги, флаги фич) — значение должно определяться только типом сборки.

  4. Защитите релиз автоматическими проверками. Добавьте в CI/линтер правило, запрещающее setWebContentsDebuggingEnabled(true) без обёртки BuildConfig.DEBUG, и проверяйте итоговый APK/AAB (например, поиском вызова в декомпилированном коде) перед публикацией.

  5. Используйте обфускацию и анти-отладочные механизмы как дополнительный барьер (проверки root/отладчика), но помните: они не заменяют отключение флага — отладка WebView должна быть выключена в релизе независимо от них.

  6. Проверяйте сторонние SDK и гибридные фреймворки. Некоторые библиотеки (рекламные, аналитические, кросс-платформенные движки) включают отладку WebView самостоятельно — убедитесь, что в релизе она отключена и на их стороне.

Ссылки

  1. https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean)
  2. https://developer.chrome.com/docs/devtools/remote-debugging/webviews/
  3. https://developer.android.com/privacy-and-security/risks/webview-debuggable-enabled
  4. https://mas.owasp.org/MASTG/tests/android/MASVS-RESILIENCE/MASTG-TEST-0046/
  5. https://cwe.mitre.org/data/definitions/489.html
  6. https://cwe.mitre.org/data/definitions/215.html
К началу