flawopen.com/Android WebView सुरक्षा/addJavascriptInterface

Android addJavascriptInterface: जोखिम और सुरक्षित उपयोग

संदर्भ पृष्ठ

संक्षिप्त उत्तर

addJavascriptInterface वाले WebView को विशेषाधिकार वाली सीमा मानें। Android इस object को हर frame में inject करता है और app यह नहीं पहचान सकता कि किस frame ने method बुलाया। यदि हमलावर-नियंत्रित JavaScript किसी frame तक पहुँच जाए, तो वह app की permissions से exposed methods बुला सकती है। Bridge वाले WebView में केवल app-नियंत्रित सामग्री रखें और अविश्वसनीय पेज को बिना bridge वाले अलग WebView में खोलें।

Bridge से XSS का असर क्यों बदलता है

Bridge JavaScript को host app में बुलाए जा सकने वाले entry points देता है। Android object को iframe सहित सभी frames में expose करता है और addJavascriptInterface caller frame का origin नहीं जाँचता। इसलिए injected script annotated bridge methods तक पहुँच सकती है; आगे की क्षमता उन methods और app के authorization checks पर निर्भर करती है। target API 16 या उससे कम वाले apps के लिए Android अधिक गंभीर legacy behavior बताता है: सभी public methods expose हो सकते हैं। API 17 से @JavascriptInterface आवश्यक है, पर यह annotation अविश्वसनीय सामग्री को सुरक्षित नहीं बनाता।

Bridge को अविश्वसनीय पेज से अलग रखें

जोखिमपूर्ण — एक WebView में bridge और अविश्वसनीय navigation

webView.addJavascriptInterface(
  NativeBridge(), "Android"
)
webView.loadUrl(untrustedUrl)

अधिक सुरक्षित — विश्वसनीय और अविश्वसनीय सामग्री अलग रखें

// यह WebView app द्वारा नियंत्रित bundled UI के लिए है।
trustedWebView.settings.javaScriptEnabled = true
trustedWebView.addJavascriptInterface(
  NativeBridge(), "Android"
)
trustedWebView.loadUrl("file:///android_asset/index.html")

// दूसरा WebView remote या user-controlled पेज संभालता है।
untrustedWebView.removeJavascriptInterface("Android")
untrustedWebView.settings.javaScriptEnabled = false
// HTTPS और स्पष्ट host allowlist दोनों जाँचें।
untrustedWebView.loadUrl(validatedHttpsUrl)

सबसे मजबूत सीमा architecture से आती है: bridge वाले WebView को remote, user-generated या हमलावर-प्रभावित पेज पर navigate न करें। यदि अविश्वसनीय सामग्री लोड करना आवश्यक हो, तो लोड से पहले interface हटाएँ और अलग WebView में JavaScript बंद रखें, जब तक इसकी जरूरत न हो। Android के अनुसार injected object सभी frames में उपलब्ध होता है और interface हटाने का असर अगले page load के बाद होता है। HTTPS transport सुरक्षित करता है; इससे host या सामग्री विश्वसनीय नहीं बनती। URL का scheme और host जाँचें और allowlist से बाहर के links system browser में खोलें। Bridge methods सीमित रखें, हर argument validate करें और caller page पर भरोसा करने के बजाय native code में authorization लागू करें।

Android WebView bridge सुरक्षा के आम सवाल

क्या API 17 या नया version addJavascriptInterface को सुरक्षित बना देता है?

नहीं। API 17+ exposure को @JavascriptInterface वाले public methods तक सीमित करता है; यह caller frame का origin नहीं जाँचता और हमलावर-नियंत्रित सामग्री को विश्वसनीय नहीं बनाता। Bridge केवल उस WebView में रखें जो app-नियंत्रित सामग्री लोड करता हो।

संदर्भ

यह भी देखें क्रॉस-साइट स्क्रिप्टिंग (XSS, CWE-79): यह कैसे काम करती है और हर भाषा में इसे कैसे रोकें — flawopen.com Angular XSS सुरक्षा: सुरक्षित defaults और bypass APIs MIME sniffing XSS: Content-Type और nosniff CSP और output escaping: क्या दोनों चाहिए? क्या React का dangerouslySetInnerHTML सुरक्षित है? क्या innerHTML के लिए DOMPurify पर्याप्त है? क्या Markdown रेंडरिंग XSS से सुरक्षित है?