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

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

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

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

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

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

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

चलो ठीक अंदर कूदें!

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

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

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

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

उपयोगकर्ता गणना

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

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

फेसबुक का लॉगिन पेज।

जब आप लॉग इन . पर क्लिक करते हैं बटन, Facebook यह बताते हुए एक त्रुटि संदेश लौटाएगा कि आपका उपयोगकर्ता नाम (जो ईमेल या फ़ोन नंबर हो सकता है) मान्य नहीं है।

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

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

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

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

एक बार जब एक हमलावर जानता है कि सिस्टम प्रत्येक सत्यापन के लिए अलग से कैसे प्रतिक्रिया करता है, तो possible users की एक सूची बनाई जा सकती है। और सामान्य/कमजोर पासवर्ड। एक्सेस प्राप्त होने तक सिस्टम के विरुद्ध ब्रूट-फोर्स परीक्षण बार-बार आयोजित किए जा सकते हैं।

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

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

द थ्रेट इन एक्शन

RailsGoat ऐप में, 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 के भीतर इसे हल करने के लिए, बस लंबाई संपत्ति को निम्नलिखित के साथ प्रतिस्थापित करें:

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

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

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

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

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

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

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

संक्षेप में, एक कुकी जिसमें सत्र की जानकारी होती है और जो HttpOnly . के साथ सेट होती है ध्वज को JavaScript Document.cookie . से एक्सेस नहीं किया जा सकता है एपीआई। इस तरह, केवल सर्वर ही इसे प्राप्त करेगा।

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

द थ्रेट इन एक्शन

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

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

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

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

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

रेलसगोट सत्र कुकी को उजागर करने वाला अलर्ट संदेश।

इस समस्या का समाधान कैसे करें

इस मामले में, यह बहुत सीधा है, बस सुनिश्चित करें कि HttpOnly . को अक्षम न करें अपने रेल ऐप्स पर फ़्लैग करें।

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

खाली अलर्ट संदेश।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

द थ्रेट इन एक्शन

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

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

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

इस समस्या का समाधान कैसे करें

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

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

gem install bcrypt

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

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 इसे सुरक्षित रूप से हैश करने का ध्यान रखेगा। ऐसा ही तब होगा जब उपयोगकर्ता के इनपुट के साथ तुलना करने के लिए पासवर्ड पुनर्प्राप्त किया जाएगा।

बहुत ज्यादा एक्सपोज करना

चाहे आप आरईएसटी एपीआई या ग्राफक्यूएल एंडपॉइंट के साथ काम कर रहे हों, उदाहरण के लिए, क्लाइंट को काम करने के लिए केवल वही लौटाना सुनिश्चित करें।

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

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

द थ्रेट इन एक्शन

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

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

def show
  respond_with @user.as_json
end

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

न केवल user मॉडल लेकिन संवेदनशील जानकारी रखने वाले अन्य मॉडलों को भी उन विशेषताओं का चयन करने के तरीके की आवश्यकता होती है जो एपीआई को दिखाई देंगी।

इस समस्या का समाधान कैसे करें

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

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

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

रैपिंग अप

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

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

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