इस श्रृंखला के पहले भाग में, इंजेक्शन अटैक्स कवर किए गए थे

OWASP टॉप 10 वेब एप्लिकेशन सुरक्षा जोखिमों के बारे में हमारी श्रृंखला के दूसरे लेख में, हम टूटी हुई प्रमाणीकरण और डेटा एक्सपोजर खतरों के ब्रह्मांड में गोता लगाएंगे।

अधिक विशेष रूप से, हम इस बारे में बात करेंगे कि हैकर के लिए आपके द्वारा बनाए गए कोड को धोखा देना और उपयोगकर्ताओं का डेटा प्राप्त करने के लिए हमले करना कितना आसान है:

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

हम उन संवेदनशील डेटा के बारे में भी विस्तार से जानेंगे जो पर्याप्त रूप से सुरक्षित नहीं हैं, जिससे निम्नलिखित जैसी कमजोरियों के लिए जगह बनती है:

• असुरक्षित संवेदनशील स्टोरेज: जब संवेदनशील डेटा कमजोर एल्गोरिदम, जैसे MD5, से एन्क्रिप्ट किया जाता है।
• संवेदनशील डेटा एक्सपोज करना: जब डेवलपर्स अनजाने में अनएन्क्रिप्टेड संवेदनशील डेटा को URLs या हिडन फील्ड्स में उजागर करते हैं, उदाहरण के लिए।

श्रृंखला के पहले लेख की तरह, हम इन खतरों में से प्रत्येक को व्यवहार में देखने के लिए RailsGoat का भी उपयोग करेंगे। यदि आप यहां नए हैं, तो ऐप को सेट अप और चलाने के लिए पिछले लेख देखें।

चलिए सीधे अंदर कूदते हैं!

प्रमाणीकरण खतरे

हम प्रमाणीकरण के बिना नहीं रह सकते। चाहे वह आपके बैक-एंड APIs पर हो या आपके फ्रंट-एंड फॉर्म्स के भीतर, यह एप्लिकेशन डेवलपमेंट में सबसे महत्वपूर्ण चरणों में से एक है क्योंकि यह आपकी सुरक्षा उपायों की सीमा को उजागर करता है।

न केवल प्रमाणीकरण के लिए बल्कि जो आगे आता है उसके लिए: सेशन मैनेजमेंट। आप अपने पासवर्ड और टोकन कहां स्टोर करने जा रहे हैं? क्या वे ठीक से एन्क्रिप्टेड हैं? क्या आप भरोसेमंद एल्गोरिदम का उपयोग कर रहे हैं? क्या आपका पासवर्ड पर्याप्त जटिल है?

नजर रखने के लिए कई सवाल हैं। आइए उन्हें थोड़ा तोड़ें और Rails एप्लिकेशन्स के भीतर प्रमाणीकरण और सेशन मैनेजमेंट से जुड़े कुछ आम हमलों को समझें।

यूज़र एन्यूमरेशन

यूज़र एन्यूमरेशन एक प्रसिद्ध तकनीक है जिसका उपयोग हमलावर यह जांचने के लिए करते हैं (ब्रूट फोर्स के उपयोग के माध्यम से) कि दिया गया डेटा आपके सिस्टम के भीतर मौजूद है या नहीं।

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

Facebook का लॉगिन पेज।

जब आप Log In बटन पर क्लिक करते हैं, तो Facebook एक एरर मैसेज लौटाएगा जिसमें कहा जाएगा कि आपका उपयोगकर्ता नाम (जो ईमेल या फोन नंबर हो सकता है) वैध नहीं है।

अमान्य उपयोगकर्ता नाम संदेश।

इसलिए, हमलावर जानता है कि एप्लिकेशन आपको बताता है कि कोई उपयोगकर्ता पंजीकृत है या नहीं। मुफ्त में।

यदि हमलावर के पास ईमेल की सूची है (चाहे वे रैंडमली जनरेट किए गए हों या कहीं खरीदे गए हों), तो एप्लिकेशन से यह पूछना भी संभव है कि पासवर्ड सही है या नहीं:

अमान्य पासवर्ड संदेश।

एक बार जब हमलावर जान जाता है कि सिस्टम प्रत्येक सत्यापन के लिए अलग-अलग कैसे प्रतिक्रिया करता है, तो संभावित उपयोगकर्ताओं और सामान्य/कमजोर पासवर्ड की एक सूची बनाई जा सकती है। तब तक सिस्टम के खिलाफ बार-बार ब्रूट-फोर्स टेस्ट किए जा सकते हैं जब तक पहुंच प्राप्त न हो जाए।

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

यूज़र एन्यूमरेशन से बचने के लिए आप जो चीज कर सकते हैं वह है उपयोगकर्ता नाम और पासवर्ड को एक साथ मान्य करना और एक सामान्य संदेश लौटाना। आइए इस दृष्टिकोण को एक्शन में देखें!

खतरा एक्शन में

RailsGoat ऐप में, app/models फोल्डर में user.rb फाइल खोलें और authenticate मेथड का पता लगाएं। इसके भीतर, आप निम्न कोड स्निपेट पा सकते हैं:

raise "#{email} doesn't exist!" if !(user) if user.password == Digest::MD5.hexdigest(password) auth = user else raise "Incorrect Password!" end 

बिल्कुल! संदेश इस तरह से सेट किए जा रहे हैं जो हमलावरों को यह जानने की अनुमति देगा कि उपयोगकर्ता मौजूद नहीं है या पासवर्ड गलत है।

इसे टेस्ट करें। RailsGoat लॉगिन पेज पर जाएं और एक रैंडम ईमेल और पासवर्ड टाइप करें। आपको निम्न एरर मैसेज दिखाई दे सकता है:

उपयोगकर्ता मौजूद नहीं है।

अन्यथा, यदि उपयोगकर्ता मौजूद है (उदाहरण के लिए ken@metacorp.com) लेकिन पासवर्ड गलत है, तो निम्न संदेश प्रदर्शित होता है:

गलत पासवर्ड।

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

इस मुद्दे को कैसे हल करें

इसे सुरक्षित बनाने के लिए आप जो सबसे तेज़ कार्रवाई कर सकते हैं वह है अपना संदेश बदलना और हैकर का जीवन जटिल बनाना।

sessions_controller.rb (app/controllers फोल्डर) के भीतर, create मेथड का पता लगाएं और निम्न कोड स्निपेट बदलें

flash[:error] = e.message 

निम्नलिखित में:

flash[:error] = "Your credentials aren't valid." 

अब, हर बार जब उपयोगकर्ता गलत उपयोगकर्ता नाम या पासवर्ड टाइप करते हैं, तो उन्हें यही संदेश प्राप्त होगा:

अमान्य क्रेडेंशियल्स।

इसे करने का एक और तरीका users.rb मॉडल के भीतर दोनों संदेशों को बदलना है।

कमजोर पासवर्ड

हम इस पर पर्याप्त जोर नहीं दे सकते। अपने उपयोगकर्ताओं को मजबूत पासवर्ड इनपुट करने की आवश्यकता है और यह सुनिश्चित करने के लिए कुछ वैलिडेशन कोड बनाएं कि वे मजबूत पासवर्ड के मानदंडों को पूरा करते हैं।

यह यूज़र एन्यूमरेशन को रोकने के लिए सबसे महत्वपूर्ण चरणों में से एक है।

खतरा एक्शन में

RailsGoat में, user.rb फाइल खोलें और क्लास डेफिनिशन से ठीक पहले कोड की पहली लाइन का पता लगाएं:

validates :password, presence: true, confirmation: true, length: { within: 6..40 }, ... 

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

इस मुद्दे को कैसे हल करें

समाधान काफी सरल है; अपने पासवर्ड को कुछ मजबूत आवश्यकताओं के खिलाफ मान्य करें, जैसे:

• कम से कम 1 लोअरकेस और 1 अपरकेस अक्षर,
• कम से कम 1 अंक,
• कम से कम 10 वर्ण।

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

RailsGoat के भीतर इसे हल करने के लिए, बस length प्रॉपर्टी को निम्नलिखित से बदलें:

:format => {:with => /\A.*(?=.*[a-zA-Z])(?=.*[0-9])(?=.{10,}).*\z/}, 

फिर, साइन-अप पेज पर जाएं, फ़ील्ड भरें, और कमजोर पासवर्ड प्रदान करें। जब आप सबमिट करते हैं, तो यह प्रदर्शित एरर मैसेज होगा:

पासवर्ड अमान्य है।

अप्रतिबंधित कुकीज़

पिछले लेख में, हमने यह समझने के लिए कुछ समय समर्पित किया था कि XSS अटैक्स कैसे होते हैं। चूंकि वे हमलावरों को दुर्भावनापूर्ण स्क्रिप्ट चलाने की अनुमति देकर होते हैं, यदि हम आपके JavaScript कोड में document.cookie जैसे एट्रिब्यूट्स तक पहुंच को रोकते नहीं हैं तो सेशन कुकीज़ से महत्वपूर्ण जानकारी चुराई जा सकती है।

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

कुकीज़, बदले में, थोड़ी सुरक्षित हैं यदि आप उन्हें ऐसा बनाने के लिए सही कदम उठाते हैं, जैसे HttpOnly फ्लैग सेट करना।

संक्षेप में, सेशन जानकारी रखने वाली कुकी जिसे HttpOnly फ्लैग के साथ सेट किया गया है, JavaScript Document.cookie API से एक्सेस नहीं की जा सकती। इस तरह, केवल सर्वर इसे प्राप्त करेगा।

वैकल्पिक रूप से, हमारे पास Secure एट्रिब्यूट भी है, जो यह सुनिश्चित करेगा कि कुकी केवल सर्वर को भेजी जाए यदि (और केवल यदि) अनुरोध HTTPS के भीतर होता है (कभी भी HTTP के भीतर नहीं)। यह आपके अनुरोधों को सुरक्षित बना देगा यदि कोई उन्हें मैन-इन-द-मिडल के रूप में सूंघ रहा है।

खतरा एक्शन में

Rails आपके लिए एक कदम उठाता है और स्वचालित रूप से सभी कुकीज़ को HttpOnly फ्लैग के साथ सेट करता है। यह बहुत अच्छा है क्योंकि यह अनजान डेवलपर्स को अपने ऐप्स को हैक होने से बचने में मदद करता है।

इस उदाहरण को टेस्ट करने के लिए, हमें इस फीचर को अक्षम करना होगा, जिसे RailsGoat ने session_store.rb फाइल के भीतर स्पष्ट रूप से किया है, जो config/initializers फोल्डर में स्थित है। इसे देखें!

फिर, रजिस्ट्रेशन पेज पर एक बार फिर जाएं, फ़ील्ड्स को ठीक से भरें, और Name फील्ड में निम्न सामग्री इनपुट करें:

<script> alert(document.cookie); </script> 

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

RailsGoat सेशन कुकी को उजागर करने वाला अलर्ट मैसेज।

इस मुद्दे को कैसे हल करें

इस मामले में, यह काफी सीधा है, बस अपने Rails ऐप्स पर HttpOnly फ्लैग को अक्षम न करने का ध्यान रखें।

तो, httponly: false सेटिंग को हटा दें और सर्वर को पुनरारंभ करें। जब आप वही ऑपरेशन करने का प्रयास करते हैं, तो निम्न अलर्ट मैसेज प्रदर्शित होगा:

खाली अलर्ट मैसेज।

अन्य परिदृश्य

कल्पना करें कि आप किसी वेब एप्लिकेशन को उन कंप्यूटर्स से एक्सेस कर रहे हैं जो सुरक्षित नहीं हैं, जैसे सार्वजनिक लाइब्रेरी कंप्यूटर्स या LAN हाउस। यदि एप्लिकेशन निर्दिष्ट अवधि की निष्क्रियता के बाद आपको ठीक से लॉग आउट करने के लिए कॉन्फ़िगर नहीं किया गया है, तो आपका सेशन वहीं रहेगा।

बस ब्राउज़र टैब बंद करना एप्लिकेशन से लॉग आउट करने के लिए पर्याप्त नहीं है।

डेवलपर्स के कोड में एक और आम मुद्दा है जब आप फ्रंट एंड में किसी भी प्रकार की IDs को उजागर करते हैं। ऐसे परिदृश्यों के बारे में सोचना इतना कठिन नहीं है जहां यूज़र की ID को हिडन इनपुट या यहां तक कि URL में रखने से आपका जीवन आसान हो जाएगा जब उपयोगकर्ता सर्वर से कुछ और अनुरोध करता है।

हालांकि, यह चोरी के हमले का आधा रास्ता है।

संवेदनशील डेटा एक्सपोजर

यह विषय शायद उनमें से एक है जिसे संवेदनशील जानकारी की सुरक्षा सुनिश्चित करने के लिए पर्याप्त प्रयास समर्पित करने के मामले में सबसे कम आंका जाता है।

चाहे आपका डेटा लगातार ट्रांजिट में हो या रेस्ट में, सामान्य डेटा को संवेदनशील डेटा से अलग करना अत्यंत महत्वपूर्ण है। संवेदनशील डेटा में क्रेडिट कार्ड नंबर और कोड, पासवर्ड, व्यक्तिगत पहचान संख्या, या ऐसा कुछ भी शामिल है जो अनुपालन या गोपनीयता कानूनों (जैसे EU का GDPR और PCI) से संबंधित है।

इसके अलावा, आपके एप्लिकेशन के चल रहे विशिष्ट व्यावसायिक क्षेत्र के आधार पर, यह निर्धारित करने के लिए स्थानीय कानून से परामर्श करना महत्वपूर्ण है कि क्या अन्य अनुपालन नियम भी लागू होते हैं।

यहां इस भेद्यता के कुछ स्पष्ट उदाहरण दिए गए हैं:

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

आइए कुछ सबसे सामान्य परिदृश्यों का विश्लेषण करें।

असुरक्षित संवेदनशील स्टोरेज

यदि आप कुछ समय से वेब एप्लिकेशन्स के साथ काम कर रहे हैं, तो संभावना है कि आपने MD5 मैसेज-डाइजेस्ट एल्गोरिदम के बारे में सुना होगा (या शायद उपयोग किया होगा)। हालांकि यह अभी भी पासवर्ड हैशिंग के लिए व्यापक रूप से उपयोग किया जाता है, यह अत्यंत कमजोर साबित हुआ है।

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

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

खतरा एक्शन में

जैसा कि हमने देखा, RailsGoat उद्देश्यपूर्ण रूप से उपयोगकर्ता के पासवर्ड को MD5 हैश के रूप में स्टोर करता है। आप इसे user.rb मॉडल के भीतर देख सकते हैं:

def hash_password if self.password.present? self.password = Digest::MD5.hexdigest(password) end end 

हर बार जब उपयोगकर्ता लॉग इन करता है, तो ऐप प्रदान किए गए पासवर्ड को हैश करता है और जांचता है कि परिणाम समान हैं या नहीं। अन्यथा, पासवर्ड मेल नहीं खाते, इसलिए एरर फेंका जाता है।

इस मुद्दे को कैसे हल करें

इस मुद्दे से निपटने के कई तरीके हैं, लेकिन शायद सबसे प्रसिद्ध साल्टेड हैश के माध्यम से है, जैसे BCrypt द्वारा प्रदान किए गए।

हालांकि Rails Bcrypt से निपटने के लिए डिफ़ॉल्ट क्षमताओं के साथ आता है, एक प्रसिद्ध लाइब्रेरी इस उद्देश्य के लिए व्यापक रूप से उपयोग की गई है: bcrypt-ruby:

gem install bcrypt 

जब आप इसके साथ अपने मॉडल को मैप करते हैं, तो पासवर्ड कैसे सेट किया जाता है और डेटाबेस से कैसे प्राप्त किया जाता है, यह परिभाषित किया जाता है। लाइब्रेरी बाकी सब कुछ स्वचालित रूप से अनुकूलित करती है:

require 'bcrypt' class User < ActiveRecord include BCrypt def password @password ||= Password.new(password_hash) end def password=(new_password) @password = Password.create(new_password) self.password_hash = @password end end 

हालांकि, फ्लो के लिए टेबल पर एक अतिरिक्त स्ट्रिंग कॉलम (password_hash) की आवश्यकता होती है ताकि BCrypt एल्गोरिदम के लिए पासवर्ड हैश स्टोर किया जा सके।

इस तरह, आप मॉडल ऑब्जेक्ट पर सीधे पासवर्ड मान सेट कर सकते हैं, और BCrypt इसे सुरक्षित रूप से हैश करने का ध्यान रखेगा। वही होगा जब पासवर्ड को उपयोगकर्ता के इनपुट के साथ तुलना करने के लिए पुनः प्राप्त किया जाता है।

बहुत अधिक उजागर करना

चाहे आप REST APIs या GraphQL एंडपॉइंट के साथ काम कर रहे हों, उदाहरण के लिए, केवल वही लौटाना सुनिश्चित करें जो क्लाइंट को काम करने के लिए आवश्यक है।

यदि आपका JavaScript क्लाइंट API से जानकारी का अनुरोध करता है और इसका केवल एक हिस्सा उपयोग करता है, तो यह हमलावर को आपके एंडपॉइंट को पकड़ने और पूरी प्रतिक्रिया प्राप्त करने के लिए इसे एक बार फिर से कॉल करने या प्रॉक्सी टूल के साथ इसे सूंघने से नहीं रोकता है।

हमेशा अपने APIs की समीक्षा करें ताकि यह प्रमाणित हो सके कि संवेदनशील जानकारी वापस की जा रही है या नहीं, यह केवल उचित एन्क्रिप्शन और सही स्थानों के साथ ही करेगा।

खतरा एक्शन में

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

api/v1 फोल्डर में users_controller.rb फाइल खोलें। वहां, आप निम्न मेथड पाएंगे:

def show respond_with @user.as_json end 

जितना सरल यह है, जब वेब क्लाइंट द्वारा एक्सेस किया जाता है, तो यह एंडपॉइंट उपयोगकर्ता के सभी फ़ील्ड्स को प्रतिक्रिया के भीतर पॉप्युलेट करके लौटाएगा, जिसमें पासवर्ड भी शामिल है।

न केवल user मॉडल बल्कि अन्य मॉडल्स जो संवेदनशील जानकारी रखते हैं, उन्हें API के लिए दृश्य एट्रिब्यूट्स का चयन करने का एक तरीका चाहिए।

इस मुद्दे को कैसे हल करें

सौभाग्य से, Rails इससे निपटने का एक बहुत आसान तरीका प्रदान करता है। आइए बस as_json मेथड को निम्नलिखित के साथ ओवरराइड करें:

def as_json super(only: [:id, :email]) end 

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

समापन

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

इसके अलावा, आधिकारिक Ruby on Rails सुरक्षा दस्तावेज़ीकरण को पढ़ने के महत्व को पर्याप्त रूप से बल नहीं दिया जा सकता। वहां, आप सेशन हाईजैकिंग, स्टोरेज तंत्र, और अपने डेटा को सर्वोत्तम तरीके से एन्क्रिप्ट करने की रणनीतियों के बारे में अधिक जानकारी पा सकते हैं।

अगले पड़ाव पर मिलते हैं!