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

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

खास जानकारी

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

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

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

असर

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

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

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

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

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

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

अगर आपके ऐप्लिकेशन को 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 के खतरनाक तरीके बंद करना

setAllowFileAccess(), setAllowFileAccessFromFileURLs(), और setAllowUniversalAccessFromFileURLs() तरीकों की वैल्यू, डिफ़ॉल्ट रूप से एपीआई लेवल 29 और उससे पहले के वर्शन में 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 सेट करें.

संसाधन