वेबव्यू – असुरक्षित फ़ाइल शामिल करना

OWASP कैटगरी: MASVS-STORAGE: स्टोरेज

खास जानकारी

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

इस दस्तावेज़ में, इन विषयों के बारे में बताया गया है:

  • WebSettings एक ऐसी क्लास है जिसमें वेबव्यू की सेटिंग के स्टेटस को मैनेज करने वाले तरीके शामिल होते हैं. इन तरीकों की वजह से, वेबव्यू पर अलग-अलग तरह के हमले हो सकते हैं. इनके बारे में बाद में बताया जाएगा. इस दस्तावेज़ में, हम उन तरीकों के बारे में जानेंगे जिनसे फ़ाइलों को ऐक्सेस किया जा सकता है. साथ ही, उस सेटिंग के बारे में भी जानेंगे जिससे JavaScript को एक्ज़ीक्यूट किया जा सकता है:
  • setAllowFileAccess, setAllowFileAccessFromFileURLs, और setAllowUniversalAccessFromFileURLs तरीकों का इस्तेमाल करके, फ़ाइल स्कीम वाले यूआरएल (file://) का इस्तेमाल करके, लोकल फ़ाइलों को ऐक्सेस करने की अनुमति दी जा सकती है. हालांकि, नुकसान पहुंचाने वाली स्क्रिप्ट, इन तरीकों का गलत इस्तेमाल करके, उन लोकल फ़ाइलों को ऐक्सेस कर सकती हैं जिन्हें ऐप्लिकेशन ऐक्सेस कर सकता है. जैसे, उनका अपना /data/ फ़ोल्डर. इस वजह से, इन तरीकों को असुरक्षित के तौर पर फ़्लैग किया गया है. साथ ही, एपीआई 30 में इन्हें बंद कर दिया गया है. इनकी जगह, WebViewAssetLoader जैसे सुरक्षित विकल्पों का इस्तेमाल किया जा सकता है.
  • The setJavascriptEnabled तरीके का इस्तेमाल करके, वेबव्यू में JavaScript को एक्ज़ीक्यूट करने की अनुमति दी जा सकती है. इससे ऐप्लिकेशन में, फ़ाइल-बेस्ड XSS का जोखिम हो सकता है. खास तौर पर, अगर लोकल फ़ाइलों या गैर-भरोसेमंद वेब कॉन्टेंट को लोड करने की अनुमति देने के लिए कॉन्फ़िगर किया गया हो, जिसमें एक्ज़ीक्यूटेबल कोड हो सकता है. साथ ही, अगर बाहरी स्रोतों से बनाई या बदली जा सकने वाली फ़ाइलों को ऐक्सेस करने की अनुमति देने के लिए कॉन्फ़िगर किया गया हो या वेबव्यू को JavaScript को एक्ज़ीक्यूट करने की अनुमति दी गई हो, तो उपयोगकर्ताओं और उनके डेटा को खतरा हो सकता है.
  • WebChromeClient.onShowFileChooser , android.webkit पैकेज का एक तरीका है. यह पैकेज, वेब ब्राउज़ करने के टूल उपलब्ध कराता है. इस तरीके का इस्तेमाल करके, उपयोगकर्ताओं को वेबव्यू में फ़ाइलें चुनने की अनुमति दी जा सकती है. हालांकि, इस सुविधा का गलत इस्तेमाल किया जा सकता है, क्योंकि वेबव्यू में यह पाबंदी नहीं लगाई जाती कि कौनसी फ़ाइल चुनी गई है.

असर

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

जोखिम: file:// के ज़रिए फ़ाइलों को ऐक्सेस करने से जुड़ा जोखिम

setAllowFileAccess, setAllowFileAccessFromFileURLs, और setAllowUniversalAccessFromFileURLs को चालू करने से, नुकसान पहुंचाने वाले इंटेंट और वेबव्यू के अनुरोधों को file:// कॉन्टेक्स्ट के साथ, किसी भी लोकल फ़ाइल को ऐक्सेस करने की अनुमति मिल सकती है. इनमें, वेबव्यू की कुकी और ऐप्लिकेशन का निजी डेटा भी शामिल है. इसके अलावा, onShowFileChooser तरीके का इस्तेमाल करके, उपयोगकर्ताओं को गैर-भरोसेमंद सोर्स से फ़ाइलें चुनने और डाउनलोड करने की अनुमति मिल सकती है.

ऐप्लिकेशन के कॉन्फ़िगरेशन के आधार पर, इन तरीकों की वजह से PII, लॉगिन क्रेडेंशियल या अन्य संवेदनशील डेटा चुराया जा सकता है.

समस्याएं ठीक करने के तरीके

फ़ाइल के यूआरएल की पुष्टि करना

अगर आपके ऐप्लिकेशन को file:// यूआरएल के ज़रिए फ़ाइलों को ऐक्सेस करने की ज़रूरत है, तो सिर्फ़ उन यूआरएल को अनुमति देना ज़रूरी है जो सही हैं. साथ ही, सामान्य गलतियां करने से बचें.

WebViewAssetLoader का इस्तेमाल करना

बताए गए तरीकों के बजाय, WebViewAssetLoader का इस्तेमाल करें. यह तरीका, लोकल फ़ाइल सिस्टम की ऐसेट को ऐक्सेस करने के लिए, file:// स्कीम के बजाय http(s)//: स्कीम का इस्तेमाल करता है. साथ ही, इस पर बताए गए हमले का असर नहीं होता.

Kotlin

val assetLoader: WebViewAssetLoader = Builder()
  .addPathHandler("/assets/", AssetsPathHandler(this))
  .build()

webView.setWebViewClient(object : WebViewClientCompat() {
  @RequiresApi(21)
  override fun shouldInterceptRequest(view: WebView?, request: WebResourceRequest): WebResourceResponse {
    return assetLoader.shouldInterceptRequest(request.url)
  }

  @Suppress("deprecation") // for API < 21
  override fun shouldInterceptRequest(view: WebView?, url: String?): WebResourceResponse {
    return assetLoader.shouldInterceptRequest(Uri.parse(url))
  }
})

val webViewSettings: WebSettings = webView.getSettings()
// Setting this off for security. Off by default for SDK versions >= 16.
webViewSettings.allowFileAccessFromFileURLs = false
// Off by default, deprecated for SDK versions >= 30.
webViewSettings.allowUniversalAccessFromFileURLs = false
// Keeping these off is less critical but still a good idea, especially if your app is not
// using file:// or content:// URLs.
webViewSettings.allowFileAccess = false
webViewSettings.allowContentAccess = false

// Assets are hosted under http(s)://appassets.androidplatform.net/assets/... .
// If the application's assets are in the "main/assets" folder this will read the file
// from "main/assets/www/index.html" and load it as if it were hosted on:
// https://appassets.androidplatform.net/assets/www/index.html
webView.loadUrl("https://appassets.androidplatform.net/assets/www/index.html")

Java

final WebViewAssetLoader assetLoader = new WebViewAssetLoader.Builder()
         .addPathHandler("/assets/", new AssetsPathHandler(this))
         .build();

webView.setWebViewClient(new WebViewClientCompat() {
    @Override
    @RequiresApi(21)
    public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
        return assetLoader.shouldInterceptRequest(request.getUrl());
    }

    @Override
    @SuppressWarnings("deprecation") // for API < 21
    public WebResourceResponse shouldInterceptRequest(WebView view, String url) {
        return assetLoader.shouldInterceptRequest(Uri.parse(url));
    }
});

WebSettings webViewSettings = webView.getSettings();
// Setting this off for security. Off by default for SDK versions >= 16.
webViewSettings.setAllowFileAccessFromFileURLs(false);
// Off by default, deprecated for SDK versions >= 30.
webViewSettings.setAllowUniversalAccessFromFileURLs(false);
// Keeping these off is less critical but still a good idea, especially if your app is not
// using file:// or content:// URLs.
webViewSettings.setAllowFileAccess(false);
webViewSettings.setAllowContentAccess(false);

// Assets are hosted under http(s)://appassets.androidplatform.net/assets/... .
// If the application's assets are in the "main/assets" folder this will read the file
// from "main/assets/www/index.html" and load it as if it were hosted on:
// https://appassets.androidplatform.net/assets/www/index.html
webview.loadUrl("https://appassets.androidplatform.net/assets/www/index.html");

WebSettings के खतरनाक तरीकों को बंद करना

एपीआई लेवल 29 और उससे पहले के वर्शन में, setAllowFileAccess() तरीके की वैल्यू डिफ़ॉल्ट रूप से TRUE पर सेट होती है. वहीं, एपीआई लेवल 30 और उसके बाद के वर्शन में, यह वैल्यू FALSE पर सेट होती है. एपीआई लेवल 16 और उसके बाद के वर्शन में, setAllowFileAccessFromFileURLs() और setAllowUniversalAccessFromFileURLs() तरीके डिफ़ॉल्ट रूप से FALSE पर सेट होते हैं. (एपीआई लेवल 16 में, इन डिफ़ॉल्ट वैल्यू को बदला गया था. ऐसा, लोकल फ़ाइलों के लिए सेम-ऑरिजिन ऐक्सेस को सीमित करके, सुरक्षा को बेहतर बनाने के लिए किया गया था. इससे, ऐप्लिकेशन को क्रॉस-साइट स्क्रिप्टिंग (XSS) और बिना अनुमति के फ़ाइल ऐक्सेस से बचाया जा सकता है.)

अगर आपको अन्य WebSettings कॉन्फ़िगर करने की ज़रूरत है, तो इन तरीकों को साफ़ तौर पर बंद करना सबसे अच्छा होगा. खास तौर पर, एपीआई लेवल 29 या उससे पहले के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए.

जोखिम: फ़ाइल-बेस्ड XSS

setJavacriptEnabled तरीके को TRUE पर सेट करने से, वेबव्यू में JavaScript को एक्ज़ीक्यूट करने की अनुमति मिलती है. साथ ही, पहले बताए गए तरीके से फ़ाइल ऐक्सेस की अनुमति देने पर, किसी भी फ़ाइल में कोड को एक्ज़ीक्यूट करके या वेबव्यू में खोली गई नुकसान पहुंचाने वाली वेबसाइटों के ज़रिए, फ़ाइल-बेस्ड XSS का जोखिम हो सकता है.

समस्याएं ठीक करने के तरीके

वेबव्यू को लोकल फ़ाइलें लोड करने से रोकना

पहले बताए गए जोखिम की तरह, फ़ाइल-बेस्ड XSS से बचा जा सकता है. इसके लिए, setAllowFileAccess(), setAllowFileAccessFromFileURLs(), और setAllowUniversalAccessFromFileURLs() को FALSE पर सेट करें.

वेबव्यू को JavaScript को एक्ज़ीक्यूट करने से रोकना

setJavascriptEnabled तरीके को FALSE पर सेट करें, ताकि वेबव्यू में JavaScript को एक्ज़ीक्यूट न किया जा सके.

पक्का करना कि वेबव्यू, गैर-भरोसेमंद कॉन्टेंट लोड न करें

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

संसाधन