हमने 2015 के बड़े पैमाने पर शोध कार्य को दोहराने का फैसला किया और दुनिया के अग्रणी बैंकों के वेब संसाधनों की सुरक्षा का विश्लेषण किया। तब से, ऑनलाइन बैंकिंग न केवल अधिक व्यापक हो गई है, बल्कि व्यापक भी हो गई है। वास्तव में, यह तेज़ और सुविधाजनक है, लेकिन कितना सुरक्षित है? क्या बैंक सर्वोत्तम प्रथाओं का पालन करते हैं?

पिछली बार की तरह, अनुसंधान की प्रक्रिया में, हमने बैंकों के साथ हस्तक्षेप किए बिना साधारण HTTP और DNS प्रश्न भेजे। यही है, एक संसाधन पर जाकर एक सामान्य उपयोगकर्ता के रूप में सभी डेटा एकत्र किए जाते हैं। विश्लेषण के लिए, हमने 200 रूसी और 400 विदेशी बैंकों का चयन किया। अध्ययन से प्राप्त अंशों के तहत। पूर्ण पाठ हमारी वेबसाइट पर पाया जा सकता है।

इस बार हमने विदेशी बैंकों के ऑनलाइन संसाधनों को दायरे में जोड़कर अनुसंधान के क्षेत्र का विस्तार किया। यह आपको रूस और दुनिया के अन्य देशों में वेब सुरक्षा के दृष्टिकोण की तुलना करने की अनुमति देता है।

आगे देखते हुए, हमें यह ध्यान देते हुए खेद है कि सुरक्षा के स्तर को बढ़ाने के क्लासिक तरीकों को अक्सर बैंकों द्वारा अनदेखा किया जाता है, हालांकि उन्हें वैश्विक वित्तीय और तकनीकी संसाधनों की आवश्यकता नहीं होती है। अवसरों को चूकना स्वैच्छिक है, लेकिन उन्हें गलत तरीके से इस्तेमाल करना पूरी तरह से अलग है। उदाहरण के लिए, सामग्री सुरक्षा नीति के मामले में, सभी माना संसाधनों में से एक पांचवें में सेटिंग्स हैं, और उनमें से लगभग हर एक में कॉन्फ़िगरेशन त्रुटियां हैं। अध्ययन के हिस्से के रूप में, हमने इस पर विचार करने की कोशिश की कि इस प्रकार की सेटिंग्स को सही तरीके से कैसे काम किया जाए, और सबसे अधिक बार क्या त्रुटियां होती हैं।

अनुसंधान उद्देश्य

अध्ययन का मुख्य उद्देश्य सार्वजनिक रूप से उपलब्ध बैंकिंग संसाधनों की सुरक्षा के स्तर का आकलन करना है: आधिकारिक वेबसाइट और आरबीएस, वेब संसाधनों की स्थापना के लिए सर्वोत्तम प्रथाओं के अनुसार। हमने कई बिंदुओं का चयन किया है, जिनके अनुपालन की जाँच की जा सकती है, किसी भी तकनीकी क्षति को छोड़कर और बैंक के काम में हस्तक्षेप किए बिना। यह ध्यान रखना महत्वपूर्ण है कि हमारे द्वारा एकत्रित की गई सभी जानकारी सार्वजनिक रूप से उपलब्ध है, और इस डेटा में हेरफेर करने के लिए गहराई से कौशल की आवश्यकता नहीं है: यदि आप चाहें, तो कोई भी इच्छुक उपयोगकर्ता इस तरह के परिणामों पर आ सकता है।

अध्ययन का उद्देश्य

परीक्षण के लिए, हमने रूस में TOP-200 बैंकों को लिया। पूरी सूची यहां पाई जा सकती है: http://www.banki.ru/banks/ratings/ (मार्च 2019 के अनुसार वर्तमान डेटा)।

पहला कदम हमने व्यक्तियों और कानूनी संस्थाओं के लिए आरबी की सभी आधिकारिक वेबसाइटों और इंटरनेट संसाधनों की पहचान की। फिर, प्रत्येक बैंक के लिए, चेक / HTTP / HTTPS / DNS प्रोटोकॉल का उपयोग करके कई मानक अनुरोधों का उपयोग करते हुए चेक बनाए गए, जो कि बैंक ग्राहकों के लिए सामान्य अनुरोधों के समान हैं। समूहीकृत सूची:

1. एसएसएल सेटिंग्स - एसएसएल से संबंधित कई हमलों में से एक को लागू करने का अवसर प्रदान करता है;
2. DNS सेटिंग्स - आपको कंपनी उप-डोमेन के बारे में जानकारी प्राप्त करने की अनुमति देती है।

निम्नलिखित कुछ जांचों का विवरण और परिणाम है। हम सामग्री सुरक्षा नीति के लिए समर्पित अनुभाग पर विशेष ध्यान देते हैं: इसमें हमने मुख्य त्रुटियों को उजागर करने की कोशिश की और बताया कि उन्हें कैसे टाला जा सकता है। सभी जांचों का पूरा विवरण और परिणाम अध्ययन में हैं ।

परीक्षण

एसएसएल / टीएलएस

सबसे महत्वपूर्ण बिंदुओं में से एक एसएसएल / टीएलएस सेटिंग्स की जाँच कर रहा है, जैसा कि आज, ये क्रिप्टोग्राफ़िक प्रोटोकॉल इंटरनेट पर सुरक्षित डेटा विनिमय प्रदान करने का सबसे लोकप्रिय तरीका है। मुख्य संभावित खतरा यातायात अवरोधन के हमलों का उपयोग है।
निम्नलिखित चेक चुने गए:

रेटिंग

एसएसएल / टीएलएस में बड़ी संख्या में सेटिंग्स और विशेषताएं हैं, जो एक डिग्री या किसी अन्य के लिए, स्वयं कनेक्शन और संपूर्ण रूप से इसके प्रतिभागियों की सुरक्षा को प्रभावित करती हैं। इस सेटिंग का समग्र मूल्यांकन करने के लिए, हमने Qualys (www.ssllabs.com) द्वारा प्रदान की गई कार्यक्षमता का उपयोग किया। यह ए से एफ तक एक सामान्य रेटिंग बनाने के लिए कई मापदंडों के आधार पर अनुमति देता है, जहां "ए +" सबसे अच्छा परिणाम है जो सुरक्षा के संदर्भ में प्राप्त किया जा सकता है। बहुत कम कंपनियों, यहां तक ​​कि सबसे बड़े इंटरनेट निगमों के पास भी है। तदनुसार, "एफ" सबसे खराब परिणाम है। यह प्राप्त किया जा सकता है यदि सर्वर किसी भी महत्वपूर्ण भेद्यता के संपर्क में है, पुराने प्रोटोकॉल का समर्थन करता है और अन्य समस्याएं हैं। "ए +" रेटिंग की तरह, सबसे खराब परिणाम दुर्लभ है, और मुख्य रूप से अव्यवसायिक कर्मचारियों के साथ जुड़ा हुआ है।

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

HTTP हेडर

वेब सर्वर की प्रतिक्रिया में हेडर आपको कुछ स्थितियों में ब्राउज़र के व्यवहार को निर्धारित करने की अनुमति देता है। उनकी उपस्थिति कुछ हमलों से बचने या उनके आचरण को जटिल बनाने में मदद करती है, जबकि हेडर जोड़ने से किसी भी जटिल कार्रवाई या सेटिंग्स की आवश्यकता नहीं होती है। हालांकि, कुछ सेटिंग्स, उदाहरण के लिए, सीएसपी, बहुत सारे विकल्पों द्वारा प्रतिष्ठित हैं, जिनका गलत उपयोग सुरक्षा का भ्रम पैदा कर सकता है या कुछ साइट कार्यक्षमता को भी नुकसान पहुंचा सकता है। हमने निम्नलिखित शीर्षकों की समीक्षा की:

यदि पहले दस शीर्षक प्रकृति में "सकारात्मक" हैं, और यह वांछनीय है (सही ढंग से!) उनका उपयोग करने के लिए, तो पिछले तीन "हमलावर" को बताएं कि कौन सी प्रौद्योगिकियों का उपयोग किया जाता है। स्वाभाविक रूप से, ऐसे शीर्षकों को छोड़ दिया जाना चाहिए।

रेटिंग

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

"डी" से "ए +" तक रेटिंग, जहां "ए +" सबसे अच्छा परिणाम है जिसे सुरक्षा के संदर्भ में प्राप्त किया जा सकता है। सबसे खराब परिणाम काफी दुर्लभ था, हालांकि, सर्वश्रेष्ठ की तरह।

रेटिंग वितरण

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

सामग्री सुरक्षा नीति

एक "कंटेंट प्रोटेक्शन पॉलिसी" या CSP, XSS हमलों के साथ जुड़े जोखिमों को कम करने के मुख्य तरीकों में से एक है। यह उपकरण साइट व्यवस्थापक को यह निर्धारित करने की अनुमति देता है कि कौन से वेब संसाधनों को पृष्ठों पर उपयोग करने की अनुमति है - फ़ॉन्ट, शैली, चित्र, जेएस स्क्रिप्ट, एसडब्ल्यूएफ और इतने पर। यहां जानें कि कौन से ब्राउज़र CSP का समर्थन करते हैं ।

CSP के लिए धन्यवाद, आप ब्राउज़र को लोड करने से पूरी तरह से रोक सकते हैं, उदाहरण के लिए, फ्लैश ऑब्जेक्ट्स, या डोमेन की सफेद सूची को समायोजित करें - इस मामले में, ब्राउज़र केवल उन एसडब्ल्यूएफ को प्रदर्शित करेगा जो अनुमत डोमेन पर स्थित हैं। एक और फायदा जो सीएसपी नीति प्रदान करती है वह है एक नियंत्रित संसाधन की विशालता में नए XSS की उपस्थिति के बारे में जल्दी से जानने की क्षमता। "रिपोर्ट-उरी" विकल्प का उपयोग करके, हमलावर या पीड़ित उपयोगकर्ता का ब्राउज़र सीएसपी के ट्रिगर होते ही निर्दिष्ट URL को एक रिपोर्ट भेजता है।

CSP नीति से संबंधित मुख्य त्रुटियों में, निम्नलिखित श्रेणियां प्रतिष्ठित की जा सकती हैं:

1. गलत कॉन्फ़िगरेशन
   
   • अनुपस्थित निर्देश (स्क्रिप्ट- src | object-src | default-src | base-uri)
   • निरर्थक विकल्प (असुरक्षित इनलाइन | असुरक्षित- eval | https: | data: | * |
2. मेजबानों की कमजोरी और सफेदी
   
   • मनमाने ढंग से JS फ़ाइलों को लोड करने की क्षमता
   • कॉलबैक कार्य ( "कॉलबैक")
   • एंगुलर और इसी तरह के टेम्पलेट इंजन में स्क्रिप्ट गैजेट्स
3. जेएस-मुक्त हमले ("स्क्रिप्ट रहित")
   
   • अशुद्ध टैग के माध्यम से रिसाव
   • फ़िशिंग फ़ॉर्म लागू करें

अधिक विस्तृत जानकारी, त्रुटियों के विशिष्ट उदाहरण और उनसे बचने के तरीके अध्ययन के पूर्ण पाठ में पाए जा सकते हैं।

CSP का मुख्य लक्ष्य XSS हमलों के दोहन की संभावना को कम करना है, लेकिन, जैसा कि अनुसंधान ने दिखाया है, कुछ इस नीति को सही ढंग से प्रबंधित करते हैं: केवल 3% CSP का उपयोग करते हैं।
ग्राफ सीएसपी साइटों की समीक्षा में सबसे आम त्रुटियों को दर्शाता है।

सख्त-परिवहन-सुरक्षा

HSTS (HTTP सख्त परिवहन सुरक्षा) सुरक्षा नीति आपको HTTP प्रोटोकॉल का उपयोग करने के बजाय एक सुरक्षित कनेक्शन स्थापित करने की अनुमति देती है। ऐसा करने के लिए, स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी हेडर का उपयोग करें, जो ब्राउज़र को HTTPS के उपयोग के लिए मजबूर करता है। यह कुछ MITM हमलों को रोकता है, विशेष रूप से, कुकीज़ की सुरक्षा और चोरी की कम डिग्री के साथ हमले। तंत्र का सिद्धांत इस प्रकार है: जब आप पहली बार HTTP (S) प्रोटोकॉल का उपयोग करते हुए किसी साइट पर जाते हैं, तो ब्राउज़र को स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी हेडर प्राप्त होता है और याद आता है कि जब आप इस साइट से दोबारा कनेक्ट होने का प्रयास करते हैं, तो आपको केवल HTPPS का उपयोग करने की आवश्यकता होती है।
यह एक परिदृश्य को रोक देगा जहां एक हमलावर, HTTP अनुरोधों को रोककर, उपयोगकर्ता को अपने डेटा को प्राप्त करने के लिए क्लोन पृष्ठ पर पुनर्निर्देशित करता है।

सख्त परिवहन-सुरक्षा HTTP हेडर का उपयोग करके बैंकों का प्रतिशत

कुकी सेट करें

HTTP अनुरोध प्राप्त करने के बाद, सर्वर प्रतिक्रिया के साथ सेट-कुकी हेडर भेज सकता है।
SSL और HTTPS पर रिक्वेस्ट करने पर सिक्योर फ्लैग वाले कुकीज सर्वर पर भेजे जाते हैं। हालांकि, महत्वपूर्ण डेटा को कभी भी कुकी में प्रेषित या संग्रहीत नहीं किया जाना चाहिए, क्योंकि इसका तंत्र बहुत कमजोर है, और सुरक्षित ध्वज अतिरिक्त एन्क्रिप्शन या सुरक्षा उपाय प्रदान नहीं करता है। HTTP.Conie फ्लैगशिप के साथ कुकीज़ डॉक्युमेंट.कॉकी एपीआई संपत्तियों के माध्यम से जावास्क्रिप्ट से सुलभ नहीं हैं, जो XSS हमले के मामले में क्लाइंट से कुकी की चोरी से बचने में मदद करता है। यह ध्वज कुकीज़ के लिए सेट किया जाना चाहिए जिन्हें जावास्क्रिप्ट के माध्यम से एक्सेस करने की आवश्यकता नहीं है। विशेष रूप से, यदि कुकीज़ का उपयोग केवल सत्र का समर्थन करने के लिए किया जाता है, तो जावास्क्रिप्ट में उन्हें ज़रूरत नहीं है और आप HTTPOnly ध्वज का उपयोग कर सकते हैं। HTTP प्रतिक्रिया शीर्ष लेख में HTTPOnly और Secure झंडे के बिना, आप वेब एप्लिकेशन सत्र और कुकीज़ चुरा सकते हैं या संसाधित कर सकते हैं।

बोस्निया और हर्जेगोविना, जापान, चीन, ब्राजील, बुल्गारिया, लक्समबर्ग, फिनलैंड, इजरायल, फ्रांस, ग्रेट ब्रिटेन और स्पेन में बैंक के हर दूसरे आधिकारिक वेबसाइट पर इस हेडर में सुरक्षित और HTTPonly झंडे अधिक बार नहीं पाए जाते हैं।
भौतिक के लिए DBO के बीच। व्यक्ति - चीन, आयरलैंड, इज़राइल और जापान।
जूर के लिए आरबीएस के बीच। व्यक्तियों - बोस्निया और हर्ज़ेगोविना, ब्राजील और चीन।

रूसी बैंकों में, आंकड़े इस प्रकार हैं:
बैंक की आधिकारिक वेबसाइट - 42%;
शारीरिक के लिए आर.बी.एस. व्यक्तियों - 37%;
कानूनी के लिए आरबीएस व्यक्तियों - 67%।

सर्वर हैडर

यह हेडर आपको बताता है कि वेब सर्वर किस सॉफ्टवेयर पर चल रहा है, और उदाहरण के लिए निम्नलिखित अर्थ हो सकते हैं:

Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l 

इस जानकारी के प्रकटीकरण से सीधा खतरा नहीं है, लेकिन हमले के समय को कम कर सकता है। किसी विशेष भेद्यता के लिए जाँच करने के बजाय, आप तुरंत सॉफ्टवेयर के एक विशिष्ट संस्करण पर डेटा की तलाश शुरू कर सकते हैं। उदाहरण के लिए, अध्ययन के दौरान, निम्नलिखित डेटा पाए गए:

अध्ययन से पता चला कि 64% बैंकों की साइटें सर्वर संस्करण की रिपोर्ट करती हैं, जबकि इनमें से 24% सर्वर असुरक्षित हैं।

निष्कर्ष

बैंक वेब संसाधनों की सुरक्षा का एक सामान्य विचार प्राप्त करने के बाद, हम मुख्य निष्कर्ष पर आए: कई बैंक अपने वेब संसाधनों की सुरक्षा में सुधार के लिए सबसे आम और आसानी से लागू होने वाले सुझावों की उपेक्षा करते हैं।

हमने जिन कमजोरियों और त्रुटियों की खोज की है, वे हमलावरों को बहुत प्रयास किए बिना संसाधनों पर हमलों को लागू करने की अनुमति देते हैं। लेकिन इन हमलों के परिणाम काफी गंभीर हैं: ग्राहकों की नकदी हानि, लंबी अवधि में बैंक के वित्तीय और प्रतिष्ठित नुकसान। कुछ लोग अपने पैसे को एक बैंक पर भरोसा करते हैं जिनकी प्रतिष्ठा सुरक्षा घटनाओं से धूमिल होती है।

बेशक, सुरक्षा के स्तर को बढ़ाने के मानक अभ्यास के बाद - कमजोरियों को खोजना और बंद करना - जोखिमों को कम करना और कम करना है। हालांकि, बैंकिंग वेब एप्लिकेशन के अधिकांश डेवलपर्स सरलतम सिफारिशों और तरीकों के बारे में भूल जाते हैं जो जोखिम को कम कर सकते हैं या कमजोरियों के शोषण को जटिल कर सकते हैं (जैसे, उदाहरण के लिए, उपयोग किए गए सॉफ़्टवेयर या सीएसपी को स्थापित करने की जानकारी के साथ सर्वर हेडर से छिपाना)। ऐसी तकनीकों का उपयोग करने के लाभ तुरंत दिखाई नहीं देते हैं, लेकिन यह स्पष्ट नहीं हो सकता है: उनका सामना करना पड़ रहा है, एक हमलावर एक हमले को अंजाम देने में सक्षम नहीं होगा, और उसकी कार्रवाई सुरक्षा के लिए जिम्मेदार लोगों की दृष्टि से बाहर रहेगी।

विभिन्न कोणों से रूसी बैंकों के वेब संसाधनों की जांच करने के बाद, हमें पता चला कि काफी जानी-मानी कमजोरियां और सुरक्षा समस्याएं अभी भी उनमें मौजूद हैं। यह हमलावरों को इन वित्तीय संस्थानों पर हमलों के सफल कार्यान्वयन पर भरोसा करने की अनुमति देता है। और अधिक समस्याएं, बैंकों के वित्तीय और प्रतिष्ठा जोखिम अधिक हैं।
पूरी दुनिया में स्थिति विशेष रूप से भिन्न नहीं है। सुरक्षा के मामले में स्पष्ट रूप से पिछड़ने के बीच, निम्नलिखित देशों के ऑनलाइन बैंकिंग संसाधनों की पहचान की जा सकती है: चीन, जापान, ब्राजील, इजरायल, स्पेन। विरोधाभासी रूप से, ज्यादातर मामलों में, विदेशी बैंक बैंकिंग प्रणाली की तुलना में अपने मुख्य पृष्ठों की सुरक्षा पर अधिक ध्यान देते हैं। यह ध्यान देने योग्य है कि अध्ययन में विदेशी बैंकों के विश्लेषण का हिस्सा इतना व्यापक नहीं है और बल्कि, परिचित है।