एमसीएस क्लाउड प्लेटफ़ॉर्म का सुरक्षा ऑडिट

स्काईशिप डस्क सीयरलाइट द्वारा

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

यह लेख बाहरी विशेषज्ञों के इस सबसे सीधे दृष्टिकोण के बारे में है जिन्होंने Mail.ru क्लाउड सॉल्यूशंस (MCS) टीम को क्लाउड सेवा का परीक्षण करने में मदद की, और उन्होंने क्या पाया। एक "बाहरी ताकत" के रूप में एमसीएस ने डिजिटल सुरक्षा कंपनी को चुना, जो सूचना सुरक्षा क्षेत्रों में अपनी उच्च विशेषज्ञता के लिए जानी जाती है। और इस लेख में हम बाहरी ऑडिट के हिस्से के रूप में पाई गई कुछ दिलचस्प कमजोरियों का विश्लेषण करेंगे - ताकि आप अपनी खुद की क्लाउड सेवा बनाते समय उसी रेक से बचें।

Описание продукта

Mail.ru क्लाउड सॉल्यूशंस (एमसीएस) क्लाउड में वर्चुअल इंफ्रास्ट्रक्चर के निर्माण के लिए एक मंच है। इसमें IaaS, PaaS और डेवलपर्स के लिए तैयार एप्लिकेशन छवियों का बाज़ार शामिल है। एमसीएस वास्तुकला को ध्यान में रखते हुए, निम्नलिखित क्षेत्रों में उत्पाद की सुरक्षा की जांच करना आवश्यक था:

• वर्चुअलाइजेशन वातावरण के बुनियादी ढांचे की सुरक्षा: हाइपरविजर, रूटिंग, फ़ायरवॉल;
• ग्राहकों के आभासी बुनियादी ढांचे की सुरक्षा: एसडीएन में नेटवर्क, निजी नेटवर्क सहित एक दूसरे से अलगाव;
• ओपनस्टैक और इसके खुले घटक;
• हमारे अपने डिज़ाइन का S3;
• आईएएम: एक रोल मॉडल के साथ बहु-किरायेदार परियोजनाएं;
• विज़न (कंप्यूटर विज़न): छवियों के साथ काम करते समय एपीआई और कमजोरियाँ;
• वेब इंटरफ़ेस और क्लासिक वेब हमले;
• PaaS घटकों की कमज़ोरियाँ;
• सभी घटकों की एपीआई.

संभवतः आगे के इतिहास के लिए बस इतना ही आवश्यक है।

किस प्रकार का कार्य किया गया और इसकी आवश्यकता क्यों पड़ी?

सुरक्षा ऑडिट का उद्देश्य उन कमजोरियों और कॉन्फ़िगरेशन त्रुटियों की पहचान करना है जो व्यक्तिगत डेटा के रिसाव, संवेदनशील जानकारी में संशोधन या सेवा उपलब्धता में व्यवधान का कारण बन सकती हैं।

काम के दौरान, जो औसतन 1-2 महीने तक चलता है, ऑडिटर संभावित हमलावरों के कार्यों को दोहराते हैं और चयनित सेवा के क्लाइंट और सर्वर भागों में कमजोरियों की तलाश करते हैं। एमसीएस क्लाउड प्लेटफ़ॉर्म के ऑडिट के संदर्भ में, निम्नलिखित लक्ष्यों की पहचान की गई:

1. सेवा में प्रमाणीकरण का विश्लेषण। इस घटक में कमजोरियाँ तुरंत अन्य लोगों के खातों में प्रवेश करने में मदद करेंगी।
2. विभिन्न खातों के बीच रोल मॉडल और पहुंच नियंत्रण का अध्ययन करना। एक हमलावर के लिए, किसी अन्य की वर्चुअल मशीन तक पहुंच प्राप्त करने की क्षमता एक वांछनीय लक्ष्य है।
3. ग्राहक पक्ष की कमजोरियाँ. एक्सएसएस/सीएसआरएफ/सीआरएलएफ/आदि। क्या दुर्भावनापूर्ण लिंक के माध्यम से अन्य उपयोगकर्ताओं पर हमला करना संभव है?
4. सर्वर साइड कमजोरियाँ: आरसीई और सभी प्रकार के इंजेक्शन (एसक्यूएल/एक्सएक्सई/एसएसआरएफ और इसी तरह)। सर्वर कमजोरियों को ढूंढना आम तौर पर अधिक कठिन होता है, लेकिन वे एक साथ कई उपयोगकर्ताओं के साथ समझौता कर लेते हैं।
5. नेटवर्क स्तर पर उपयोगकर्ता खंड अलगाव का विश्लेषण। एक हमलावर के लिए, अलगाव की कमी अन्य उपयोगकर्ताओं के खिलाफ हमले की सतह को काफी बढ़ा देती है।
6. व्यावसायिक तर्क विश्लेषण. क्या व्यवसायों को धोखा देना और मुफ्त में वर्चुअल मशीन बनाना संभव है?

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

कमजोरियाँ पाई गईं

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

ऐसी जगहों को ढूंढना महत्वपूर्ण है जो संदिग्ध लगती हैं या किसी तरह से दूसरों से बहुत अलग हैं। और इस तरह पहली खतरनाक भेद्यता का पता चला।

आईडीओआर

आईडीओआर (असुरक्षित प्रत्यक्ष वस्तु संदर्भ) कमजोरियां व्यावसायिक तर्क में सबसे आम कमजोरियों में से एक हैं, जो एक या दूसरे को उन वस्तुओं तक पहुंच प्राप्त करने की अनुमति देती हैं जिन तक पहुंच वास्तव में अनुमति नहीं है। IDOR कमजोरियाँ उपयोगकर्ता के बारे में गंभीरता की अलग-अलग डिग्री की जानकारी प्राप्त करने की संभावना पैदा करती हैं।

आईडीओआर विकल्पों में से एक इन ऑब्जेक्टों तक पहुंच पहचानकर्ताओं में हेरफेर करके सिस्टम ऑब्जेक्ट्स (उपयोगकर्ता, बैंक खाते, शॉपिंग कार्ट में आइटम) के साथ कार्रवाई करना है। इससे सबसे अप्रत्याशित परिणाम सामने आते हैं। उदाहरण के लिए, धनराशि भेजने वाले के खाते को बदलने की संभावना, जिसके माध्यम से आप उन्हें अन्य उपयोगकर्ताओं से चुरा सकते हैं।

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

सर्वर साइड अनुरोध जालसाजी (SSRF)

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

एप्लिकेशन की एक सामान्य कार्यक्षमता उपयोगकर्ता के लिए सर्वर पर एक लिंक भेजने की क्षमता है, जिस पर सर्वर क्लिक करता है (उदाहरण के लिए, किसी निर्दिष्ट स्रोत से एक छवि डाउनलोड करने के लिए)। यदि सुरक्षा उपकरण लिंक को स्वयं या सर्वर से उपयोगकर्ताओं को लौटाई गई प्रतिक्रियाओं को फ़िल्टर नहीं करते हैं, तो ऐसी कार्यक्षमता का उपयोग हमलावरों द्वारा आसानी से किया जा सकता है।

एसएसआरएफ की कमजोरियां किसी हमले के विकास को काफी हद तक आगे बढ़ा सकती हैं। एक हमलावर को मिल सकता है:

• आक्रमण किए गए स्थानीय नेटवर्क तक सीमित पहुंच, उदाहरण के लिए, केवल कुछ नेटवर्क खंडों के माध्यम से और एक निश्चित प्रोटोकॉल का उपयोग करके;
• स्थानीय नेटवर्क तक पूर्ण पहुंच, यदि एप्लिकेशन स्तर से परिवहन स्तर तक अपग्रेड करना संभव है और, परिणामस्वरूप, एप्लिकेशन स्तर पर पूर्ण लोड प्रबंधन;
• सर्वर पर स्थानीय फ़ाइलों को पढ़ने की पहुंच (यदि फ़ाइल: /// योजना समर्थित है);
• И многое другое

ओपनस्टैक में एक एसएसआरएफ भेद्यता लंबे समय से ज्ञात है, जो प्रकृति में "अंधा" है: जब आप सर्वर से संपर्क करते हैं, तो आपको उससे कोई प्रतिक्रिया नहीं मिलती है, लेकिन अनुरोध के परिणाम के आधार पर आपको विभिन्न प्रकार की त्रुटियां/देरी प्राप्त होती है . इसके आधार पर, आप आंतरिक नेटवर्क पर होस्ट पर पोर्ट स्कैन कर सकते हैं, जिसके सभी आगामी परिणामों को कम करके नहीं आंका जाना चाहिए। उदाहरण के लिए, किसी उत्पाद में बैक-ऑफ़िस एपीआई हो सकती है जिसे केवल कॉर्पोरेट नेटवर्क से ही एक्सेस किया जा सकता है। दस्तावेज़ीकरण (अंदरूनी सूत्रों के बारे में न भूलें) के साथ, एक हमलावर आंतरिक तरीकों तक पहुंचने के लिए एसएसआरएफ का उपयोग कर सकता है। उदाहरण के लिए, यदि आप किसी तरह उपयोगी यूआरएल की अनुमानित सूची प्राप्त करने में सक्षम थे, तो एसएसआरएफ का उपयोग करके आप उनके माध्यम से जा सकते हैं और अनुरोध निष्पादित कर सकते हैं - अपेक्षाकृत बोलते हुए, खाते से खाते में धन स्थानांतरित करें या सीमाएं बदलें।

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

में और यह HackerOne सेवा (h1) से सार्वजनिक रूप से उपलब्ध रिपोर्ट, इंस्टेंस मेटाडेटा को पढ़ने की क्षमता के साथ अब ब्लाइंड SSRF के शोषण से संपूर्ण Shopify बुनियादी ढांचे तक रूट पहुंच हो जाती है।

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

गोले लोड करने के बजाय XSS

सैकड़ों अध्ययन लिखे जाने के बावजूद, साल दर साल XSS (क्रॉस-साइट स्क्रिप्टिंग) हमला अभी भी सबसे अधिक है अक्सर सामना करना पड़ता है वेब भेद्यता (या आक्रमण?)।

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

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

यह पता चला कि डाउनलोड की गई फ़ाइलें एमसीएस सेवा के सभी उपयोगकर्ताओं के लिए उपलब्ध हैं, जिसका अर्थ है कि अन्य क्लाउड उपयोगकर्ताओं, अर्थात् प्रशासकों पर हमला करना संभव है।

फ़िशिंग लॉगिन फ़ॉर्म पर XSS हमले का एक उदाहरण

XSS आक्रमण शोषण के उदाहरण:

• यदि लोड की गई स्क्रिप्ट तुरंत संसाधन एपीआई तक पहुंच सकती है, तो एक सत्र चुराने का प्रयास क्यों करें (खासकर अब HTTP-केवल कुकीज़ हर जगह हैं, जेएस स्क्रिप्ट का उपयोग करके चोरी से सुरक्षित हैं)? इस मामले में, पेलोड सर्वर कॉन्फ़िगरेशन को बदलने के लिए एक्सएचआर अनुरोधों का उपयोग कर सकता है, उदाहरण के लिए, हमलावर की सार्वजनिक एसएसएच कुंजी जोड़ें और सर्वर तक एसएसएच पहुंच प्राप्त करें।
• यदि सीएसपी नीति (सामग्री सुरक्षा नीति) जावास्क्रिप्ट को इंजेक्ट करने से रोकती है, तो एक हमलावर इसके बिना काम कर सकता है। शुद्ध HTML का उपयोग करके, साइट के लिए एक नकली लॉगिन फ़ॉर्म बनाएं और इस उन्नत फ़िशिंग के माध्यम से व्यवस्थापक का पासवर्ड चुराएं: उपयोगकर्ता के लिए फ़िशिंग पृष्ठ एक ही URL पर समाप्त होता है, और उपयोगकर्ता के लिए इसका पता लगाना अधिक कठिन होता है।
• अंततः, हमलावर व्यवस्था कर सकता है ग्राहक DoS - कुकीज़ को 4 केबी से बड़ा सेट करें। उपयोगकर्ता को केवल एक बार लिंक खोलने की आवश्यकता होती है, और पूरी साइट तब तक पहुंच से बाहर हो जाती है जब तक कि उपयोगकर्ता विशेष रूप से ब्राउज़र को साफ़ करने के बारे में नहीं सोचता: अधिकांश मामलों में, वेब सर्वर ऐसे क्लाइंट को स्वीकार करने से इंकार कर देगा।

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

अर्थात्, परिदृश्य इस प्रकार निकला: एक हमलावर नाम में "लोड" के साथ एक फ़ायरवॉल नियम बनाता है, व्यवस्थापक थोड़ी देर बाद इसे नोटिस करता है और हटाने की प्रक्रिया शुरू करता है। और यहीं पर दुर्भावनापूर्ण JS काम करता है।

एमसीएस डेवलपर्स के लिए, डाउनलोड की गई एसवीजी छवियों में एक्सएसएस से सुरक्षा के लिए (यदि उन्हें छोड़ा नहीं जा सकता), डिजिटल सुरक्षा टीम ने सिफारिश की:

• उपयोगकर्ताओं द्वारा अपलोड की गई फ़ाइलों को एक अलग डोमेन पर रखें जिसका "कुकीज़" से कोई लेना-देना नहीं है। स्क्रिप्ट को एक अलग डोमेन के संदर्भ में निष्पादित किया जाएगा और इससे एमसीएस को कोई खतरा नहीं होगा।
• सर्वर की HTTP प्रतिक्रिया में, "सामग्री-स्वभाव: अनुलग्नक" शीर्षलेख भेजें। फिर फ़ाइलें ब्राउज़र द्वारा डाउनलोड की जाएंगी और निष्पादित नहीं की जाएंगी।

इसके अलावा, XSS शोषण के जोखिमों को कम करने के लिए डेवलपर्स के पास अब कई तरीके उपलब्ध हैं:

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

दो-कारक प्रमाणीकरण कमजोरियाँ

खाता सुरक्षा में सुधार के लिए, उपयोगकर्ताओं को हमेशा 2FA (दो-कारक प्रमाणीकरण) सक्षम करने की सलाह दी जाती है। वास्तव में, यदि उपयोगकर्ता की साख से समझौता किया गया है तो किसी हमलावर को किसी सेवा तक पहुंच प्राप्त करने से रोकने का यह एक प्रभावी तरीका है।

लेकिन क्या दूसरे प्रमाणीकरण कारक का उपयोग हमेशा खाता सुरक्षा की गारंटी देता है? 2FA के कार्यान्वयन में निम्नलिखित सुरक्षा मुद्दे हैं:

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

एमसीएस के मामले में, 2FA Google प्रमाणक के आधार पर कार्यान्वित किया जाता है जोड़ी. प्रोटोकॉल का पहले ही समय-परीक्षण किया जा चुका है, लेकिन एप्लिकेशन पक्ष पर कोड सत्यापन का कार्यान्वयन जांचने लायक है।

MCS 2FA का उपयोग कई स्थानों पर किया जाता है:

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

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

"बर्प: इंट्रूडर" टूल का उपयोग करके 2FA को अक्षम करने के लिए एक ओटीपी चुनने की प्रक्रिया

परिणाम

कुल मिलाकर, एमसीएस एक उत्पाद के रूप में सुरक्षित प्रतीत होता है। ऑडिट के दौरान, परीक्षण करने वाली टीम क्लाइंट वीएम और उनके डेटा तक पहुंच प्राप्त करने में असमर्थ थी, और पाई गई कमजोरियों को एमसीएस टीम द्वारा तुरंत ठीक कर दिया गया था।

लेकिन यहां यह ध्यान रखना जरूरी है कि सुरक्षा एक सतत कार्य है। सेवाएँ स्थिर नहीं हैं, वे लगातार विकसित हो रही हैं। और कमजोरियों के बिना किसी उत्पाद को पूरी तरह विकसित करना असंभव है। लेकिन आप उन्हें समय रहते ढूंढ सकते हैं और उनकी पुनरावृत्ति की संभावना को कम कर सकते हैं।

अब MCS में उल्लिखित सभी कमजोरियाँ पहले ही ठीक कर दी गई हैं। और नए लोगों की संख्या न्यूनतम रखने और उनके जीवनकाल को कम करने के लिए, प्लेटफ़ॉर्म टीम यह करना जारी रखती है:

• बाहरी कंपनियों द्वारा नियमित रूप से ऑडिट करना;
• समर्थन करें और भागीदारी विकसित करें Mail.ru ग्रुप बग बाउंटी प्रोग्राम में;
• सुरक्षा में लगें. 🙂

स्रोत: www.habr.com