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

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(), setAllowFileAccessFromFileURLs(), और setAllowUniversalAccessFromFileURLs() तरीकों की वैल्यू डिफ़ॉल्ट रूप से TRUE पर सेट होती है. वहीं, एपीआई लेवल 30 और इसके बाद के लेवल में, इनकी वैल्यू FALSE पर सेट होती है.

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

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

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

जोखिम कम करने के तरीके

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

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

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

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

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

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

संसाधन