'क्रॉस-ऐप्लिकेशन स्क्रिप्टिंग' के जोखिम की संभावना को ठीक करना

यह जानकारी उन डेवलपर के लिए है जिनके पास मौजूद ऐप्लिकेशन में, 'क्रॉस-ऐप्लिकेशन स्क्रिप्टिंग' का जोखिम हो सकता है.

क्या हो रहा है

आपके एक या उससे ज़्यादा ऐप्लिकेशन में 'WebView क्रॉस-ऐप्लिकेशन स्क्रिप्टिंग' की समस्या है. इससे उपयोगकर्ता की कुकी और अन्य डेटा चुराने में, नुकसान पहुंचाने वाले ऐप्लिकेशन को मदद मिलती है. कृपया अपने Play Console में सूचना देखें. आपके Play Console में दिख रही समयसीमा के बाद, ऐसे ऐप्लिकेशन को Google Play से हटाया जा सकता है जिनमें सुरक्षा की गड़बड़ियों को ठीक नहीं किया गया है.

कार्रवाई करना ज़रूरी है​

1. अपनेPlay Console में साइन इन करें और 'अलर्ट' सेक्शन पर जाकर देखें कि किन ऐप्लिकेशन पर असर हुआ है और इन समस्याओं को ठीक करने की आखिरी तारीखें क्या हैं.
2. आपके जिन ऐप्लिकेशन में समस्याएं हैं उन्हें अपडेट करें और जोखिम की संभावना को ठीक करें.
3. आपके जिन ऐप्लिकेशन पर असर हुआ है उनके अपडेट किए गए वर्शन सबमिट करें.

जब तक आपके अनुरोध की समीक्षा नहीं हो जाती, तब तक आपके नए ऐप्लिकेशन या ऐप्लिकेशन के अपडेट की स्थिति अभी प्रकाशन होना बाकी है रहेगी. ऐप्लिकेशन को सही तरीके से अपडेट नहीं करने पर, आपको चेतावनी दिखती रहेगी.

कुछ और जानकारी

ऐसे वेबव्यू जो JavaScript चालू करते हैं और गैर-भरोसेमंद इंटेट से 'डेटा रीड' लोड करते हैं, नुकसान पहुंचाने वाले ऐप्लिकेशन उनसे धोखे से किसी असुरक्षित तरीके से JavaScript कोड का इस्तेमाल करवा सकते हैं. हमारा सुझाव है कि आप आगे बताए गए किसी एक तरीके का इस्तेमाल करके इस जोखिम को रोकें:

विकल्प एक: पक्का करें कि जिन गतिविधियों पर असर हुआ है उन्हें एक्सपोर्ट न किया गया हो

ऐसी सभी Activities ढूंढें जिन पर WebViews का असर हुआ है. अगर इन Activities को दूसरे ऐप्लिकेशन से Intents पाने की ज़रूरत नहीं है, तो अपने manifest में Activities के लिए android:exported=false सेट कर सकते हैं. इससे यह पक्का हो जाएगा कि नुकसान पहुंचाने वाले ऐप्लिकेशन इन गतिविधियों में किसी भी WebViews को नुकसान पहुंचाने वाले इनपुट नहीं भेज सकते.

विकल्प दो: एक्सपोर्ट की गई गतिविधियों में WebViews सुरक्षित रखें

अगर आप किसी Activity को 'एक्सपोर्ट की गई' के तौर पर सेट करना चाहते हैं जिस पर WebView का असर हुआ है, तो हमारा सुझाव है कि आप ये बदलाव करें:

1. evaluateJavascript और loadUrl पर सुरक्षित कॉल करना

   यह पक्का करें कि evaluateJavascript के पैरामीटर हमेशा भरोसेमंद हों. गैर-भरोसेमंद Intents के सैनिटाइज़ नहीं किए गए इनपुट का इस्तेमाल करके evaluateJavascript को कॉल करने से, हमलावर उस WebView में नुकसान पहुंचाने वाली स्क्रिप्ट लागू कर सकते हैं जिस पर असर हुआ है. इसी तरह, loadUrl को सैनिटाइज़ नहीं किए गए ऐसे इनपुट के साथ कॉल करने से, हमलावर नुकसान पहुंचाने वाली स्क्रिप्ट लागू कर सकते हैं. जिसमें javascript: scheme URLs शामिल हैं.

2. असुरक्षित फ़ाइल लोड होने से रोकना

   यह पक्का करें कि ऐसे WebViews कुकी डेटाबेस लोड नहीं करते हों जिन पर असर हुआ है. जो WebViews, गैर-भरोसेमंद Intents के सैनिटाइज़ नहीं किए गए file:// URLs को लोड करते हैं उन पर नुकसान पहुंचाने वाले ऐप्लिकेशन, दो चरणों में हमला कर सकते हैं. पहला चरण: नुकसान पहुंचाने वाला वेब पेज, कुकी डेटाबेस में <script> टैग लिख सकता है. दूसरा चरण: अगर नुकसान पहुंचाने वाला ऐप्लिकेशन, आपके WebView कुकी डेटाबेस को पॉइंट करते हुए file:// URL वाला Intent भेजता है या नुकसान पहुंचाने वाला वेबपेज आपके WebView को फ़ाइल यूआरएल पर भेजता है, तो बदली गई कुकी डेटाबेस फ़ाइल लोड हो सकती है. कुकी डेटाबेस में सेव किया गया नुकसान पहुंचाने वाला <script> लोड होकर काम करेगा, जो सत्र की जानकारी चुरा सकता है.

   आप तीन तरीकों से यह पक्का कर सकते हैं कि ऐसे WebView जिन पर असर हुआ है वे WebView कुकी डेटाबेस लोड न कर सकते हों.

   1. सभी फ़ाइल का ऐक्सेस बंद करें.
   2. यह पक्का करें कि WebView सिर्फ़ file:// URLs को लोड करता हो. साथ ही, पुष्टि कर सकते हैं कि लोड किया गया कोई file:// URLs सुरक्षित फ़ाइलों की तरफ़ पॉइंट करता हो. ध्यान दें कि कोई हमलावर यूआरएल पाथ की जांच से बचने के लिए symbolic link का इस्तेमाल कर सकता है. ऐसे किसी हमले को रोकने के लिए, लोड करने से पहले सिर्फ़ यूआरएल पाथ की जांच करने के बजाय, किसी गैर-भरोसेमंद file:// URL का canonical path जांचें.
   3. अगर आप http:// URLs और file:// URLs दोनों को अनुमति देना चाहते हैं, तो WebViewClient में shouldOverrideUrlLoading और shouldInterceptRequest का इस्तेमाल करके file:// URL की पुष्टि लागू करें. इससे यह पक्का हो जाता है कि WebView में लोड किए गए सभी यूआरएल की पुष्टि हो चुकी है. हालांकि यह सिर्फ़ ऐसे यूआरएल तक ही सीमित नहीं हैं जो सीधे loadUrl() फ़ंक्शन कॉल को दिए गए हैं.

हम आपकी मदद के लिए हमेशा तैयार हैं
अगर आप जोखिम की संभावना से जुड़े तकनीकी सवाल पूछना चाहते हैं, तो आप उन्हें Stack Overflow पर पोस्ट कर सकते हैं और “android-security” टैग का इस्तेमाल कर सकते हैं. इस समस्या को ठीक करने के लिए आपको जो कदम उठाने हैं उनके बारे में ज़्यादा जानकारी के लिए, आप हमारी डेवलपर सहायता टीम से संपर्क कर सकते हैं.