वेबव्यू – नेटिव ब्रिज

OWASP कैटगरी: MASVS-PLATFORM: प्लैटफ़ॉर्म इंटरैक्शन

खास जानकारी

नेटिव ब्रिज, जिसे कभी-कभी JavaScript ब्रिज भी कहा जाता है, एक ऐसा तरीका है जिससे वेबव्यू और नेटिव Android कोड के बीच कम्यूनिकेशन किया जा सकता है. इसके लिए, addJavascriptInterface तरीके का इस्तेमाल किया जाता है. इससे वेबव्यू में चल रहे JavaScript कोड और Android ऐप्लिकेशन के Java कोड के बीच, दोनों दिशाओं में कम्यूनिकेशन किया जा सकता है. addJavascriptInterface तरीका, वेबव्यू के सभी फ़्रेम के लिए एक Java ऑब्जेक्ट दिखाता है. साथ ही, कोई भी फ़्रेम ऑब्जेक्ट के नाम को ऐक्सेस कर सकता है और उस पर तरीके कॉल कर सकता है. हालांकि, ऐप्लिकेशन के पास यह पुष्टि करने का कोई तरीका नहीं है कि वेबव्यू में कॉल करने वाला फ़्रेम कहां से आया है. इससे सुरक्षा से जुड़ी समस्याएं हो सकती हैं, क्योंकि कॉन्टेंट की भरोसेमंद होने की पुष्टि नहीं की जा सकती.

नेटिव ब्रिज को एचटीएमएल मैसेज चैनलों के साथ भी लागू किया जा सकता है. इसके लिए, Android के WebViewCompat.postWebMessage या WebMessagePort.postMessage का इस्तेमाल करके, JavaScript Window.postMessage के साथ कम्यूनिकेट किया जा सकता है. WebViewCompat.postWebMessage और WebMessagePort.postMessage, Window.postMessage के ज़रिए भेजे गए JavaScript मैसेज स्वीकार कर सकते हैं. इन्हें वेबव्यू में एक्ज़ीक्यूट किया जाएगा.

नेटिव ब्रिज से जुड़े कई जोखिम हैं:

  • JavascriptInterface पर आधारित ब्रिज:
    • addJavascriptInterface तरीका, दिए गए Java ऑब्जेक्ट को वेबव्यू के हर फ़्रेम में इंजेक्ट करता है. इसमें iframe भी शामिल हैं. इसका मतलब है कि नुकसान पहुंचाने वाले तीसरे पक्ष, किसी असली वेबसाइट में फ़्रेम इंजेक्ट करके इस पर हमला कर सकते हैं. एपीआई लेवल 16 या उससे पहले के वर्शन को टारगेट करने वाले ऐप्लिकेशन पर हमले का खतरा ज़्यादा होता है, क्योंकि इस तरीके का इस्तेमाल करके JavaScript को होस्ट ऐप्लिकेशन को कंट्रोल करने की अनुमति दी जा सकती है.
    • नेटिव ब्रिज की सुविधा वाले वेबव्यू में, उपयोगकर्ता की ओर से दिए गए गैर-भरोसेमंद कॉन्टेंट को दिखाने से, क्रॉस-साइट स्क्रिप्टिंग (XSS) के हमले हो सकते हैं.
  • MessageChannel पर आधारित ब्रिज:
    • मैसेज चैनल के एंडपॉइंट पर, ऑरिजिन की जांच न होने का मतलब है कि मैसेज किसी भी भेजने वाले से स्वीकार किए जाएंगे. इनमें नुकसान पहुंचाने वाला कोड शामिल करने वाले मैसेज भी शामिल हैं.
    • ऐसा हो सकता है कि Java को गलती से आर्बिट्रेरी JavaScript के लिए दिखाया जाए.

असर

नुकसान पहुंचाने वाले लोग, addJavascriptInterface, postWebMessage, और postMessage तरीकों का इस्तेमाल करके, वेबव्यू में अपने कंट्रोल वाला कोड ऐक्सेस, उसमें बदलाव या उसे इंजेक्ट कर सकते हैं. इससे उपयोगकर्ताओं को नुकसान पहुंचाने वाली साइटों पर रीडायरेक्ट किया जा सकता है, नुकसान पहुंचाने वाला कॉन्टेंट लोड किया जा सकता है या उनके डिवाइसों पर नुकसान पहुंचाने वाला कोड चलाया जा सकता है. इससे संवेदनशील डेटा निकाला जा सकता है या विशेषाधिकारों को बढ़ाया जा सकता है.

रिस्क: addJavascriptInterface से जुड़े जोखिम

वेबव्यू, ब्राउज़र के बुनियादी फ़ंक्शन लागू करता है. जैसे, पेज रेंडर करना, नेविगेशन, और JavaScript को एक्ज़ीक्यूट करना. किसी ऐप्लिकेशन में वेबव्यू का इस्तेमाल करके, गतिविधि के लेआउट के हिस्से के तौर पर वेब कॉन्टेंट दिखाया जा सकता है. addJavascriptInterface तरीके का इस्तेमाल करके, वेबव्यू में नेटिव ब्रिज लागू करने से सुरक्षा से जुड़ी समस्याएं हो सकती हैं. जैसे, क्रॉस-साइट स्क्रिप्टिंग (XSS). इसके अलावा, हमलावर इंटरफ़ेस इंजेक्शन के ज़रिए गैर-भरोसेमंद कॉन्टेंट लोड कर सकते हैं और होस्ट ऐप्लिकेशन में अनचाहे तरीके से बदलाव कर सकते हैं. साथ ही, होस्ट ऐप्लिकेशन की अनुमतियों के साथ Java कोड को एक्ज़ीक्यूट कर सकते हैं.

कम करने के तरीके

JavaScript बंद करें

ऐसे मामलों में जहां वेबव्यू को JavaScript की ज़रूरत नहीं होती, वहां setJavaScriptEnabled में WebSettings को कॉल न करें. उदाहरण के लिए, स्टैटिक एचटीएमएल कॉन्टेंट दिखाते समय. डिफ़ॉल्ट रूप से, वेबव्यू में JavaScript को एक्ज़ीक्यूट करने की सुविधा बंद होती है.

गैर-भरोसेमंद कॉन्टेंट लोड करते समय, JavaScript इंटरफ़ेस हटाएं

पक्का करें कि वेबव्यू से गैर-भरोसेमंद कॉन्टेंट लोड होने से पहले, removeJavascriptInterface को कॉल करके JavaScript इंटरफ़ेस से ऑब्जेक्ट हटा दिए जाएं. उदाहरण के लिए, ऐसा shouldInterceptRequest को कॉल करके किया जा सकता है.

Kotlin

webView.removeJavascriptInterface("myObject")

Java

webView.removeJavascriptInterface("myObject");

सिर्फ़ एचटीटीपीएस पर वेब कॉन्टेंट लोड करें

अगर आपको गैर-भरोसेमंद कॉन्टेंट लोड करना है, तो पक्का करें कि वेबव्यू, एन्क्रिप्ट किए गए कनेक्शन पर वेब कॉन्टेंट लोड करे. इसके अलावा, सादे टेक्स्ट में कम्यूनिकेशन से जुड़ी हमारी गाइडलाइन भी देखें. AndroidManifest फ़ाइल में android:usesCleartextTraffic को false पर सेट करके या नेटवर्क सुरक्षा कॉन्फ़िगरेशन में एचटीटीपी ट्रैफ़िक को अनुमति न देकर, एन्क्रिप्ट नहीं किए गए कनेक्शन पर शुरुआती पेज लोड होने से रोकें. ज़्यादा जानकारी के लिए, usesCleartextTraffic का दस्तावेज़ देखें.

एक्सएमएल

<application
    android:usesCleartextTraffic="false">
    <!-- Other application elements -->
</application>

यह पक्का करने के लिए कि एन्क्रिप्ट नहीं किए गए ट्रैफ़िक पर रीडायरेक्ट और ऐप्लिकेशन ब्राउज़िंग न हो, loadUrl या shouldInterceptRequest में एचटीटीपी स्कीम की जांच करें:

Kotlin

fun loadSecureUrl(webView: WebView?, url: String?) {
    webView?.let { wv ->  // Ensure valid WebView and URL
        url?.let {
            try {
                val uri = URI(url)
                if (uri.scheme.equals("https", ignoreCase = true)) { // Enforce HTTPS scheme for security
                    wv.loadUrl(url)
                } else {
                    // Log an error or handle the case where the URL is not secure
                    System.err.println("Attempted to load a non-HTTPS URL: $url")
                }
            } catch (e: Exception) {
                // Handle exception for improper URL format
                System.err.println("Invalid URL syntax: $url")
            }
        }
    }
}

Java

public void loadSecureUrl(WebView webView, String url) {
    if (webView != null && url != null) { // Ensure valid WebView and URL
        try {
            URI uri = new URI(url);
            String scheme = uri.getScheme();
            if ("https".equalsIgnoreCase(scheme)) { // Enforce HTTPS scheme for security
                webView.loadUrl(url);
            } else {
                // Log an error or handle the case where the URL is not secure
                System.err.println("Attempted to load a non-HTTPS URL: " + url);
            }
        } catch (URISyntaxException e) {
            // Handle exception for improper URL format
            System.err.println("Invalid URL syntax: " + url);
        }
    }
}

गैर-भरोसेमंद कॉन्टेंट की पुष्टि करें

अगर किसी वेबव्यू में बाहरी लिंक लोड किए जाते हैं, तो स्कीम और होस्ट (अनुमति वाली सूची में शामिल डोमेन) दोनों की पुष्टि करें. अनुमति वाली सूची में शामिल नहीं किए गए डोमेन को डिफ़ॉल्ट ब्राउज़र से खोला जाना चाहिए.

गैर-भरोसेमंद कॉन्टेंट लोड न करें

अगर मुमकिन हो, तो वेबव्यू में सिर्फ़ पूरी तरह से स्कोप किए गए यूआरएल और ऐप्लिकेशन डेवलपर के मालिकाना हक वाला कॉन्टेंट लोड करें.

संवेदनशील डेटा न दिखाएं

अगर आपका ऐप्लिकेशन, वेबव्यू की मदद से संवेदनशील डेटा ऐक्सेस करता है, तो स्थानीय तौर पर सेव की गई किसी भी फ़ाइल को मिटाने के लिए, clearCache तरीके का इस्तेमाल करें. JavaScript इंटरफ़ेस का इस्तेमाल करने से पहले. सर्वर-साइड हेडर का भी इस्तेमाल किया जा सकता है. जैसे, no-store. इससे यह बताया जा सकता है कि किसी ऐप्लिकेशन को खास कॉन्टेंट को कैश नहीं करना चाहिए.

संवेदनशील फ़ंक्शन न दिखाएं

अगर आपके ऐप्लिकेशन को संवेदनशील अनुमतियों की ज़रूरत है या वह संवेदनशील डेटा इकट्ठा करता है, तो पक्का करें कि उसे ऐप्लिकेशन में मौजूद कोड से कॉल किया जाए और उपयोगकर्ताओं को साफ़ तौर पर जानकारी दी जाए. संवेदनशील कार्रवाइयों या उपयोगकर्ता के डेटा के लिए, JavaScript इंटरफ़ेस का इस्तेमाल करने से बचें.

एपीआई लेवल 21 या उससे ज़्यादा को टारगेट करें

addJavascriptInterface तरीके का सुरक्षित तरीके से इस्तेमाल करने का एक तरीका यह है कि एपीआई लेवल 21 या उससे ज़्यादा को टारगेट किया जाए. इसके लिए, यह पक्का करें कि इस तरीके को सिर्फ़ एपीआई लेवल 21 या उससे ज़्यादा पर चलाने पर कॉल किया जाए. एपीआई 21 से पहले, JavaScript, रिफ़्लेक्शन का इस्तेमाल करके, इंजेक्ट किए गए ऑब्जेक्ट के सार्वजनिक फ़ील्ड को ऐक्सेस कर सकता था.

रिस्क: MessageChannel से जुड़े जोखिम

postWebMessage() और postMessage() में ऑरिजिन कंट्रोल न होने की वजह से, हमलावर मैसेज इंटरसेप्ट कर सकते हैं या नेटिव हैंडलर को मैसेज भेज सकते हैं.

कम करने के तरीके

postWebMessage() या postMessage() सेट अप करते समय, सिर्फ़ भरोसेमंद डोमेन से मैसेज स्वीकार करें. इसके लिए, टारगेट ऑरिजिन के तौर पर * का इस्तेमाल करने से बचें. इसके बजाय, भेजने वाले डोमेन के बारे में साफ़ तौर पर बताएं.

संसाधन