दो-कारक प्रमाणीकरण परीक्षण और संभव वर्कअराउंड

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

सरल शब्दों में, द्वि-कारक प्रमाणीकरण सुरक्षा बढ़ाने के लिए उत्पन्न कोड दर्ज करके कार्रवाई की पुष्टि है और आंदोलन के दौरान या इससे पहले कि सशर्त हैकर्स के पहियों में चिपक जाता है।

कोड पुष्टिकरण प्रणाली बहुत व्यापक है, इसका उपयोग हर जगह विभिन्न साइटों पर किया जाता है और इसे प्राथमिक और द्वितीयक दोनों लॉगिन के लिए जोड़ा जा सकता है। लेकिन आवेदन केवल इस तक सीमित नहीं है - डेवलपर्स पासवर्ड रिकवरी की कार्यक्षमता, पंजीकरण / सदस्यता की पुष्टि, वित्तीय लेनदेन की अतिरिक्त पुष्टि, पासवर्ड परिवर्तन, व्यक्तिगत डेटा के परिवर्तन की पुष्टि करते हैं। इसके अलावा, समय-समय पर लॉगआउट के बाद दीवार के रूप में 2FA का उपयोग किया जाता है, और पासवर्ड या पुष्टि के अन्य तरीके से नहीं।

इस लेख में, मैंने कमजोरियों, उनके शोषण, साथ ही कुछ प्रकार के हमलों के खिलाफ मौजूदा सुरक्षा को दरकिनार करने के संभावित विकल्पों के लिए 2FA का परीक्षण करने के तरीके एकत्र किए हैं। आइए 2FA पर लागू होने वाली भेद्यता जांचों की सूची देखें:

1. दर सीमा का अभाव

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

अक्सर आपको "नीरव" दर-सीमा से निपटना पड़ता है, यदि आप देखते हैं कि कोई त्रुटि नहीं है और HTTP बॉडी / कोड बाद के अनुरोधों में नहीं बदलता है, तो आपको बहुत जल्दी खुश होना चाहिए, और पहले आपको वैध कोड का उपयोग करके हमले के अंतिम परिणाम की जांच करने की आवश्यकता है।

2. दर सीमा मौजूद है, लेकिन इसे दरकिनार किया जा सकता है

इससे पहले मुझे मिलने वाले मामले:

1) एक निश्चित गति तक पहुँचने के बाद बिना किसी रुकावट के प्रवाह की गति को सीमित करना

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

2) उत्पन्न ओटीपी कोड नहीं बदलता है

यह Google प्रमाणक की तरह लगातार बदलते कोड पर लागू नहीं होता है, लेकिन केवल स्थिर लोग जो एसएमएस, ईमेल या मैसेंजर के माध्यम से व्यक्ति में आते हैं।

इस बाईपास का सार यह है कि एक ही ओटीपी कोड लगातार या कुछ समय के लिए भेजा जाता है, उदाहरण के लिए, 5 मिनट, जो इस समय के दौरान मान्य है। यह सुनिश्चित करने के लिए भी सार्थक है कि कोई मूक दर-सीमा नहीं होती है।

रिपोर्ट का उदाहरण: hackerone.com/reports/420163

मान लीजिए कि एप्लिकेशन 001 से 999 तक एक यादृच्छिक कोड उत्पन्न करता है और इसे फोन पर भेजता है, 10 मिनट के भीतर जब "फिर से भेजें" कार्यक्षमता सक्षम होती है, तो हमें समान कोड मिलता है। लेकिन दर-सीमा अनुरोध के लिए बाध्य है, जो प्रति अनुरोध टोकन के प्रयासों की संख्या को सीमित करता है। हम लगातार एक नए कोड का अनुरोध कर सकते हैं, एक नया अनुरोध टोकन जनरेट कर सकते हैं, इसे बाद के अनुरोध पर लागू कर सकते हैं (burp सूट में grep-match का उपयोग करके या अपनी स्वयं की स्क्रिप्ट का उपयोग करके) और 001 से 999 तक की संख्या की bruteforce प्रदर्शन करते हैं। इस प्रकार, लगातार एक नया अनुरोध टोकन का उपयोग कर हम सफलतापूर्वक सही कोड का चयन करेंगे, क्योंकि यह परिवर्तित नहीं होता है और एक निश्चित अवधि के लिए स्थिर होता है। इस हमले की सीमाएँ एक लंबी संख्या हैं या पुष्टिकरण कोड के रूप में संख्याओं के साथ अक्षरों को मिलाते हुए।

इस स्थिति को प्रोत्साहित नहीं किया जाना चाहिए, आपको हमारी सूची के कम से कम हिस्से को क्रमबद्ध करने की कोशिश करनी चाहिए, क्योंकि संभावना है कि उत्पन्न कोड सूची के इस हिस्से में होगा, क्योंकि यह यादृच्छिक रूप से उत्पन्न होता है। कोशिश करते समय, आपको यादृच्छिक पर भरोसा करने की आवश्यकता होती है, लेकिन फिर भी सही संयोजन में आने का एक मौका होता है, जो एक भेद्यता साबित होता है जिसे निश्चित रूप से तय करने की आवश्यकता होती है।

3) कोड को अपडेट करते समय दर-सीमा-एक रीसेट करें।

कोड सत्यापन अनुरोध में, दर सीमा मौजूद है, लेकिन कोड को फिर से भेजने के कार्य को सक्रिय करने के बाद, यह रीसेट हो जाता है और आपको जानवर-बल कोड जारी रखने की अनुमति देता है।
रिपोर्ट के उदाहरण:

https://hackerone.com/reports/149598 , - सिद्धांत;
hackerone.com/reports/205000 , पिछली रिपोर्ट के आधार पर हाथों-हाथ शोषण।

4) आईपी पते को बदलकर दर सीमा को कम करना

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

आईपी ​​बदलने के तरीके:

• Burp Suite github.com/RhinoSecurityLabs/IPRotate_Burp_Extension के लिए IP रोटेटर ऐड-ऑन का उपयोग करके हमले में प्रॉक्सी का उपयोग किया जा सकता है। मेरी राय में, यह सबसे अच्छा विकल्प है, क्योंकि यह हमें ~ असीमित ब्रूट बल प्रयासों और आईपी पते देता है जो आपको 42x त्रुटियों और रुकावटों के बिना एक ब्रूट-बल हमले करने की अनुमति देता है।
• एक अच्छा विकल्प एक प्रॉक्सी अनुरोध मॉड्यूल के साथ एक अजगर स्क्रिप्ट हो सकता है, लेकिन पहले आपको कहीं बड़ी संख्या में वैध प्रॉक्सी प्राप्त करने की आवश्यकता है।

चूंकि IP रोटेट टूल AWS IP पतों का उपयोग करके अनुरोध भेजता है, अगर CloudFlare फ़ायरवॉल के पीछे वेब अनुप्रयोग है, तो सभी अनुरोध अवरुद्ध हो जाएंगे।



इस मामले में, आपको मूल वेब सर्वर के आईपी को अतिरिक्त रूप से खोजने या एडब्ल्यूएस आईपी पते की चिंता न करने वाली कोई विधि खोजने की आवश्यकता है।

5) साइट में एक्स-फॉरवर्ड-फॉर का समर्थन शामिल है

IP को बदलने के लिए अंतर्निहित X-Forwarded-For हेडर का उपयोग किया जा सकता है। यदि इस हेडर के लिए एप्लिकेशन में बिल्ट-इन प्रोसेसिंग है, तो अतिरिक्त प्रॉक्सी के उपयोग के बिना प्रतिबंध को दरकिनार करने के लिए आईपी को बदलने के लिए एक्स-फॉरवर्डेड-फॉर: वांछित_आईपी भेजें। हर बार एक अनुरोध एक्स-फ़ॉर्वर्ड-फॉर से भेजा जाता है, वेब सर्वर यह सोचेगा कि हमारा आईपी पता हेडर के माध्यम से प्रेषित मूल्य से मेल खाता है।
इस विषय पर सामग्री:
hackerone.com/reports/225897
medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf34157

3. दूसरे खाते के सत्र से अनुरोध के भाग को प्रतिस्थापित करके बाईपास 2fa

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

उदाहरण के लिए, ओटीपी कोड भेजते समय, फॉर्म आईडी, उपयोगकर्ता आईडी या कुकी जो कोड भेजने के साथ जुड़ी होती है, की जाँच की जाती है। यदि हम उस खाते के मापदंडों से डेटा लागू करते हैं, जिस पर आप कोड सत्यापन (खाता 1) को पूरी तरह से अलग खाते (खाता 2) के सत्र में बायपास करना चाहते हैं, तो हम कोड प्राप्त करेंगे और इसे दूसरे खाते में दर्ज करेंगे, फिर हम पहले खाते पर सुरक्षा को बायपास कर सकते हैं। पृष्ठ को पुनः लोड करने के बाद 2FA गायब हो जाना चाहिए।

4. "memorization कार्यक्षमता" का उपयोग कर बाईपास 2FA

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

1) यदि कुकी का उपयोग करके 2FA जुड़ा हुआ है, तो कुकी का मूल्य अस्पष्ट होना चाहिए

यही है, अगर एक कुकी में संख्याओं का एक सेट होता है जो प्रत्येक खाते के लिए बढ़ता है, तो कुकी मूल्य पर एक क्रूर-बल हमला लागू करना और 2FA को बायपास करना काफी संभव है। डेवलपर्स को HttpOnly विशेषता के साथ कुकी (प्रमुख सत्र कुकी और CSRF टोकन के साथ) प्रदान करनी चाहिए ताकि इसे XSS का उपयोग करके चोरी न किया जा सके और 2FA को बायपास किया जा सके।

2) यदि 2FA आईपी पते से जुड़ा है, तो आप इसे बदलने का प्रयास कर सकते हैं

इस विधि की पहचान करने के लिए, 2FA संग्रहण फ़ंक्शन का उपयोग करके अपने खाते में लॉग इन करें, फिर वर्तमान ब्राउज़र के किसी अन्य ब्राउज़र या गुप्त मोड पर जाएँ और फिर से लॉग इन करने का प्रयास करें। यदि 2FA का अनुरोध नहीं किया गया है, तो 2FA आईपी पते से जुड़ा हुआ है।
आईपी ​​पते को बदलने के लिए, आप लॉगिन और पासवर्ड दर्ज करने के चरण में एक्स-फॉरवर्ड-फॉर हेडर का उपयोग कर सकते हैं, अगर वेब इसका समर्थन करता है।

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

अपने आप को बचाने के लिए सबसे सुरक्षित तरीका 2FA को याद नहीं करना है जो कि प्रयोज्य के अवरोध के लिए है।

5. 2FA इनपुट पेज पर अनुचित अभिगम नियंत्रण बग

कभी-कभी 2FA दर्ज करने के लिए एक संवाद पृष्ठ को पैरामीटर के साथ एक URL के रूप में प्रस्तुत किया जाता है। कुकीज़ वाले URL में ऐसे पृष्ठ तक पहुँच जो उन पेजों से मेल नहीं खाती जो पेज को उत्पन्न करने के लिए या बिना कुकीज़ के सुरक्षित नहीं हैं। लेकिन अगर डेवलपर्स ने जोखिमों को स्वीकार करने का फैसला किया है, तो आपको कई महत्वपूर्ण बिंदुओं से गुजरना होगा:

1. क्या लिंक 2FA इनपुट के लिए समाप्त हो जाता है?
2. क्या खोज इंजन में लिंक अनुक्रमित है।

यदि लिंक में एक लंबा जीवन है और / या खोज इंजनों में 2FA इनपुट के लिए काम करने वाले लिंक हैं / लिंक को अनुक्रमित किया जा सकता है (robots.txt / मेटा टैग में कोई नियम नहीं हैं), तो 2FA इनपुट पृष्ठ पर 2FA बायपास तंत्र का उपयोग करने की संभावना है, जिसमें लॉगिन और पासवर्ड को पूरी तरह से बायपास करें, और किसी अन्य के खाते तक पहुंच प्राप्त करें।

6. पेज 2FA पर व्यक्तिगत डेटा की अपर्याप्त सेंसरशिप

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

क्रेडेंशियल स्टफिंग का उपयोग करके भेद्यता का शोषण करने का एक उदाहरण। मान लीजिए कि साइट ए के लिए लॉगिन और पासवर्ड के साथ सार्वजनिक डोमेन में एक डेटाबेस है। हमलावर बी डेटाबेस पर इस डेटाबेस से डेटा का उपयोग कर सकते हैं:

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

7. कुछ परिस्थितियों में 2FA की अनदेखी करना

आपके खाते में स्वत: लॉगिन करने वाले कुछ कार्यों को करते समय, 2FA का अनुरोध नहीं किया जा सकता है।

1) पासवर्ड ठीक करते समय 2FA पर ध्यान न दें

पासवर्ड पुनर्प्राप्ति प्रक्रिया को पूरा करने के बाद कई सेवाएं स्वचालित रूप से आपके खाते में प्रवेश करती हैं। चूंकि खाते तक पहुंच तुरंत प्रदान की जाती है, जब आप अपने 2FA खाते में प्रवेश करते हैं, तो इसे अनदेखा और पूरी तरह से अनदेखा किया जा सकता है।

हाल ही में भेजी गई एक समान हैकरोन रिपोर्ट का प्रभाव:

यदि कोई हमलावर पीड़ित के ईमेल तक पहुँच प्राप्त करता है (वह फ़िशिंग, ब्रूट-फोर्स हमलों, क्रेडेंशियल्स स्टफिंग, आदि का उपयोग करके खाता हैक कर सकता है), तो वह 2FA को बायपास कर सकता है, हालांकि इस मामले में 2FA खाते की सुरक्षा करना चाहिए। फिलहाल, 2FA के लिए Google प्रमाणक कोड या बैकअप कोड का सत्यापन है, लेकिन ईमेल से कोड नहीं है, इसलिए यह बायपास समझ में आता है।

2) एक सामाजिक नेटवर्क के माध्यम से प्रवेश करते समय 2FA की उपेक्षा करना

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

रिपोर्ट में से एक का प्रभाव:

1. अन्य कमजोरियों का एक गुच्छा, जैसे कि पहले भेजा गया OAuth गलत धारणा # 577468, पूरी तरह से खाते पर कब्जा करने के लिए, 2FA को तोड़ना।
2. यदि कोई हमलावर उपयोगकर्ता के ईमेल को हैक कर लेता है, तो वह सोशल नेटवर्क खाते तक पहुंच प्राप्त करने और अतिरिक्त सत्यापन के बिना खाते में लॉग इन करने का प्रयास कर सकता है।
3. यदि कोई हमलावर एक बार पीड़ित के खाते में हैक कर लेता है, तो वह खाते के साथ एक सामाजिक नेटवर्क को जोड़ सकता है और भविष्य में खाते में लॉग इन कर सकता है, पूरी तरह से 2FA को अनदेखा कर सकता है और लॉगिन / पासवर्ड दर्ज कर सकता है।

3) आवेदन के एक पुराने संस्करण में 2FA की उपेक्षा करना

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

इसके अलावा, आप एक ही समय में अन्य कमजोरियों की जांच कर सकते हैं, - एक मचान सर्वर पर एक नया उपयोगकर्ता पंजीकृत करना जिसका ईमेल उत्पादन संस्करण डेटाबेस में मौजूद है, जो हमें उत्पादन से व्यक्तिगत डेटा दे सकता है; महत्वपूर्ण कार्यक्षमता में दर सीमा का अभाव, उदाहरण के लिए, पासवर्ड रिकवरी। नवीनतम भेद्यता का एक उदाहरण $ 15,000 का एक फेसबुक बग है, जिसने बीटा.फेसबुक डॉट कॉम www.freecodecamp.org/news/responsible-disclosure-how-could-have-hacked-all-all पर bruteforce पासवर्ड रिकवरी कोड का उपयोग करके किसी खाते को हैक करने की अनुमति दी है फेसबुक-अकाउंट्स- f47c0252ae4d

4) क्रॉस-प्लेटफॉर्म के मामले में 2FA की अनदेखी करना

मोबाइल या डेस्कटॉप संस्करण में 2FA कार्यान्वयन एप्लिकेशन के वेब संस्करण से भिन्न हो सकता है। 2FA वेब संस्करण की तुलना में कमजोर हो सकता है या पूरी तरह से अनुपस्थित हो सकता है।

7. 2FA को अक्षम करते समय, वर्तमान कोड का अनुरोध नहीं किया जाता है।

यदि, 2FA को अक्षम करते समय, अतिरिक्त पुष्टि का अनुरोध नहीं किया जाता है, जैसे कि Google प्रमाणक एप्लिकेशन से वर्तमान कोड, ईमेल / फोन से कोड, तो इस मामले में कुछ जोखिम हैं। स्वच्छ अनुरोध के साथ, सीएसआरएफ हमले का एक मौका है। यदि CSRF सुरक्षा का एक बाईपास वेक्टर पाया जाता है (यदि कोई है), तो 2FA को निष्क्रिय किया जा सकता है। एक क्लिकजैकिंग भेद्यता का भी उपयोग किया जा सकता है - एक असुरक्षित उपयोगकर्ता से कुछ क्लिकों के बाद, 2FA काट दिया जाएगा। पिछले कोड के सत्यापन में अतिरिक्त 2FA सुरक्षा दी जाएगी, जो संभावित CSRF / XSS / क्लिकजैकिंग हमलों, साथ ही साथ CORS मिसकॉन्फ़िगरेशन को भी जोड़ देगा।

मैं आपको hackerone.com का एक उदाहरण दूंगा, - जब आप एक रूप में 2FA बंद करते हैं, तो आपको एक ही समय में दो चर दर्ज करने की आवश्यकता होती है, - Google प्रमाणक एप्लिकेशन और पासवर्ड वाला वर्तमान कोड। यह सबसे अच्छा और अनुशंसित संरक्षण है।

8. पहले बनाए गए सत्र 2FA की सक्रियता के बाद मान्य रहते हैं

जब 2FA सक्षम किया जाता है, तो यह वांछनीय है कि समान खाता अंत पर समानांतर सत्र और 2FA इनपुट संवाद प्रदर्शित किया जाता है, एक पासवर्ड परिवर्तन के साथ। यदि खाते से छेड़छाड़ की गई और पीड़ित की पहली प्रतिक्रिया 2FA शामिल है, तो हमलावर का सत्र अक्षम हो जाएगा और अगले लॉगिन और पासवर्ड को 2FA की आवश्यकता होगी। सभी के सभी, यह सबसे अच्छा अभ्यास है। मैं अक्सर नोटिस करता हूं कि क्रिप्टोक्यूरेंसी एक्सचेंज समान सुरक्षा कैसे जोड़ते हैं। HackerOne रिपोर्ट उदाहरण, -
https://hackerone.com/reports/534450।

9. आपके खाते में दर सीमा का अभाव

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

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

10. एपीआई संस्करण

यदि आपको वेब एप्लिकेशन के अनुरोध में कुछ ऐसा / v * / दिखाई देता है, जहां * एक नंबर है, तो यह संभावना है कि आप API के पुराने संस्करण में स्विच कर सकते हैं। API . , API production/staging .
, /endpoint/api/v4/login , . 2FA , /endpoint/api/v4/2fa_check, . API 2FA, , , . /endpoint/api/v3/login /endpoint/v3/login_successful?code=RANDOM, 2fa_check , API, 2FA .

, — /endpoint/api/v4/2fa_check rate-limit, /endpoint/api/v3/2fa_check - .

11. Improper Access Control

2FA . ( ). CORS /XSS , «» , 2FA, .

, 2 , , , 2FA web , — . , 2FA ( Salesforce, Valve) 2FA. 2FA , 2FA bypass-.

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