10 सबसे आम वेब सुरक्षा कमज़ोरियाँ
ओलिवर जोन्स
OWASP या ओपन वेब सिक्योरिटी प्रोजेक्ट एक गैर-लाभकारी धर्मार्थ संगठन है जो सॉफ्टवेयर और वेब अनुप्रयोगों की सुरक्षा में सुधार लाने पर केंद्रित है।
यह संगठन विभिन्न सुरक्षा संगठनों से प्राप्त आंकड़ों के आधार पर शीर्ष वेब सुरक्षा कमजोरियों की सूची प्रकाशित करता है।
वेब सुरक्षा कमजोरियों को शोषण क्षमता, पता लगाने की क्षमता और सॉफ्टवेयर पर प्रभाव के आधार पर प्राथमिकता दी जाती है।
- शोषण क्षमता –सुरक्षा भेद्यता का फायदा उठाने के लिए क्या आवश्यक है? सबसे अधिक शोषण क्षमता तब होती है जब हमले के लिए केवल वेब ब्राउज़र की आवश्यकता होती है और सबसे कम उन्नत प्रोग्रामिंग और टूल की आवश्यकता होती है।
- पता लगाने योग्यता – खतरे का पता लगाना कितना आसान है? सबसे ज़्यादा जानकारी यूआरएल, फ़ॉर्म या त्रुटि संदेश पर प्रदर्शित जानकारी से मिलती है और सबसे कम सोर्स कोड से मिलती है।
- प्रभाव या क्षति –यदि सुरक्षा भेद्यता उजागर हो जाए या उस पर आक्रमण हो जाए तो कितना नुकसान होगा? सबसे अधिक नुकसान होगा पूरा सिस्टम क्रैश हो जाना और सबसे कम नुकसान होगा बिल्कुल भी नहीं।
OWASP टॉप 10 का मुख्य उद्देश्य डेवलपर्स, डिजाइनरों, प्रबंधकों, आर्किटेक्ट्स और संगठनों को सबसे महत्वपूर्ण सुरक्षा कमजोरियों के बारे में शिक्षित करना है।
OWASP टॉप 10 के अनुसार शीर्ष 10 सुरक्षा कमजोरियाँ हैं:
SQL इंजेक्शन
विवरण
इंजेक्शन एक सुरक्षा भेद्यता है जो हमलावर को बैकएंड को बदलने की अनुमति देता है एसक्यूएल उपयोगकर्ता द्वारा दिए गए डेटा में हेरफेर करके बयानों को गलत साबित किया जा सकता है।
इंजेक्शन तब होता है जब उपयोगकर्ता इनपुट को कमांड या क्वेरी के भाग के रूप में इंटरप्रेटर के पास भेजा जाता है और इंटरप्रेटर को अनपेक्षित कमांड निष्पादित करने के लिए प्रेरित करता है तथा अनधिकृत डेटा तक पहुंच प्रदान करता है।
SQL कमांड, जब वेब अनुप्रयोग द्वारा निष्पादित किया जाता है, तो बैक-एंड डाटाबेस को भी प्रदर्शित कर सकता है।
निहितार्थ
- एक हमलावर संवेदनशील क्षेत्रों में दुर्भावनापूर्ण सामग्री डाल सकता है।
- उपयोगकर्ता नाम, पासवर्ड आदि जैसे संवेदनशील डेटा को डेटाबेस से पढ़ा जा सकता है।
- डेटाबेस डेटा को संशोधित किया जा सकता है (सम्मिलित करें/अद्यतन करें/हटाएं)।
- प्रशासन Operaडेटाबेस पर क्रियान्वित किया जा सकता है
असुरक्षित वस्तुएं
- इनपुट फ़ील्ड
- डेटाबेस के साथ इंटरैक्ट करने वाले यूआरएल.
उदाहरण:
- एसक्यूएल इंजेक्षन लॉगिन पेज पर
बिना वैध क्रेडेंशियल के किसी एप्लिकेशन में लॉग इन करना।
वैध उपयोगकर्ता नाम उपलब्ध है, तथा पासवर्ड उपलब्ध नहीं है।
परीक्षण यूआरएल: http://demo.testfire.net/default.aspx
उपयोगकर्ता नाम: sjones
पासवर्ड: 1=1′ या pass123
SQL क्वेरी बनाई गई और नीचे दिए अनुसार इंटरप्रेटर को भेजी गई
SELECT * FROM Users जहां User_Name = sjones और पासवर्ड = 1=1′ या pass123;
अनुशंसाएँ
- इनपुट फ़ील्ड को श्वेत सूची में डालना
- हमलावर के लिए उपयोगी विस्तृत त्रुटि संदेश प्रदर्शित करने से बचें।
क्रॉस साइट स्क्रिप्टिंग
विवरण
क्रॉस साइट स्क्रिप्टिंग को संक्षेप में XSS के नाम से भी जाना जाता है।
XSS की कमज़ोरियाँ किसी पेज में एम्बेड की गई स्क्रिप्ट को निशाना बनाती हैं, जो सर्वर साइड के बजाय क्लाइंट साइड यानी उपयोगकर्ता ब्राउज़र पर निष्पादित होती हैं। ये खामियाँ तब हो सकती हैं जब एप्लिकेशन अविश्वसनीय डेटा लेता है और उसे उचित सत्यापन के बिना वेब ब्राउज़र पर भेजता है।
हमलावर इस मामले में पीड़ित ब्राउज़रों पर उपयोगकर्ताओं पर दुर्भावनापूर्ण स्क्रिप्ट निष्पादित करने के लिए XSS का उपयोग कर सकते हैं। चूंकि ब्राउज़र यह नहीं जान सकता कि स्क्रिप्ट विश्वसनीय है या नहीं, स्क्रिप्ट निष्पादित हो जाएगी, और हमलावर सत्र कुकीज़ को हाईजैक कर सकता है, वेबसाइटों को खराब कर सकता है, या उपयोगकर्ता को अवांछित और दुर्भावनापूर्ण वेबसाइटों पर पुनर्निर्देशित कर सकता है।
XSS एक ऐसा हमला है जो हमलावर को पीड़ित के ब्राउज़र पर स्क्रिप्ट निष्पादित करने की अनुमति देता है।
निहितार्थ:
- इस सुरक्षा भेद्यता का उपयोग करके, हमलावर एप्लिकेशन में स्क्रिप्ट डाल सकता है, सत्र कुकीज़ चुरा सकता है, वेबसाइटों को ख़राब कर सकता है, और पीड़ित की मशीनों पर मैलवेयर चला सकता है।
असुरक्षित वस्तुएं
- इनपुट फ़ील्ड
- URLs
उदाहरण
1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>
उपरोक्त स्क्रिप्ट को जब ब्राउज़र पर चलाया जाएगा तो यदि साइट XSS के प्रति संवेदनशील होगी तो एक संदेश बॉक्स प्रदर्शित होगा।
यदि हमलावर सत्र कुकी प्रदर्शित या संग्रहीत करना चाहता है तो अधिक गंभीर हमला हो सकता है।
2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com चौड़ाई = 500 ऊंचाई 500>
उपरोक्त स्क्रिप्ट चलाने पर, ब्राउज़र एक अदृश्य फ्रेम लोड करेगा जो इंगित करेगा http://google.com.
ब्राउज़र पर दुर्भावनापूर्ण स्क्रिप्ट चलाकर हमले को गंभीर बनाया जा सकता है।
अनुशंसाएँ
- श्वेत सूची इनपुट फ़ील्ड
- इनपुट आउटपुट एनकोडिंग
टूटा हुआ प्रमाणीकरण और सत्र प्रबंधन
विवरण
वेबसाइटें आमतौर पर प्रत्येक वैध सत्र के लिए एक सत्र कुकी और सत्र आईडी बनाती हैं, और इन कुकीज़ में उपयोगकर्ता नाम, पासवर्ड आदि जैसे संवेदनशील डेटा होते हैं। जब सत्र लॉगआउट या ब्राउज़र अचानक बंद होने से समाप्त हो जाता है, तो इन कुकीज़ को अमान्य कर दिया जाना चाहिए, अर्थात प्रत्येक सत्र के लिए एक नई कुकी होनी चाहिए।
यदि कुकीज़ अमान्य नहीं की जाती हैं, तो संवेदनशील डेटा सिस्टम में मौजूद रहेगा। उदाहरण के लिए, सार्वजनिक कंप्यूटर (साइबर कैफे) का उपयोग करने वाला कोई उपयोगकर्ता, असुरक्षित साइट की कुकीज़ सिस्टम पर बैठ जाती हैं और हमलावर के सामने आ जाती हैं। हमलावर कुछ समय बाद उसी सार्वजनिक कंप्यूटर का उपयोग करता है, संवेदनशील डेटा से समझौता हो जाता है।
इसी तरह, सार्वजनिक कंप्यूटर का उपयोग करने वाला उपयोगकर्ता लॉग ऑफ करने के बजाय, ब्राउज़र को अचानक बंद कर देता है। एक हमलावर उसी सिस्टम का उपयोग करता है, जब वह उसी असुरक्षित साइट को ब्राउज़ करता है, तो पीड़ित का पिछला सत्र खुल जाएगा। हमलावर प्रोफ़ाइल जानकारी, क्रेडिट कार्ड की जानकारी आदि चुराने से लेकर जो चाहे कर सकता है।
प्रमाणीकरण और सत्र प्रबंधन की मजबूती का पता लगाने के लिए एक जांच की जानी चाहिए। पासवर्ड से समझौता किए बिना कुंजी, सत्र टोकन, कुकीज़ को ठीक से लागू किया जाना चाहिए।
असुरक्षित वस्तुएं
- यूआरएल पर प्रदर्शित सत्र आईडी से सत्र निर्धारण हमला हो सकता है।
- लॉगआउट और लॉगिन से पहले और बाद में सत्र आईडी समान होती है।
- सत्र टाइमआउट सही ढंग से क्रियान्वित नहीं किया गया है।
- एप्लिकेशन प्रत्येक नए सत्र के लिए समान सत्र आईडी निर्दिष्ट कर रहा है।
- एप्लिकेशन के प्रमाणीकृत भागों को SSL का उपयोग करके सुरक्षित किया जाता है और पासवर्ड को हैश या एन्क्रिप्टेड प्रारूप में संग्रहीत किया जाता है।
- सत्र का पुनः उपयोग कम विशेषाधिकार वाले उपयोगकर्ता द्वारा किया जा सकता है।
निहितार्थ
- इस कमजोरी का उपयोग करके, हमलावर किसी सत्र को हाईजैक कर सकता है, सिस्टम तक अनधिकृत पहुंच प्राप्त कर सकता है, जिससे अनधिकृत जानकारी का प्रकटीकरण और संशोधन संभव हो जाता है।
- चोरी की गई कुकीज़ या XSS का उपयोग करके सत्रों को हाईजैक किया जा सकता है।
उदाहरण
- एयरलाइन आरक्षण अनुप्रयोग URL पुनर्लेखन का समर्थन करता है, URL में सत्र आईडी डालता है:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (मालदीव के लिए टिकटों की बिक्री)साइट का एक प्रमाणित उपयोगकर्ता अपने दोस्तों को बिक्री के बारे में बताना चाहता है और एक ईमेल भेजता है। दोस्तों को सत्र आईडी प्राप्त होती है और इसका उपयोग अनधिकृत संशोधन करने या सहेजे गए क्रेडिट कार्ड विवरण का दुरुपयोग करने के लिए किया जा सकता है।
- एक एप्लिकेशन XSS के प्रति संवेदनशील होता है, जिसके द्वारा एक हमलावर सत्र आईडी तक पहुंच सकता है और सत्र को हाईजैक करने के लिए इसका उपयोग किया जा सकता है।
- एप्लीकेशन टाइमआउट ठीक से सेट नहीं किए गए हैं। उपयोगकर्ता सार्वजनिक कंप्यूटर का उपयोग करता है और लॉग ऑफ करने के बजाय ब्राउज़र बंद कर देता है और चला जाता है। हमलावर कुछ समय बाद उसी ब्राउज़र का उपयोग करता है, और सत्र प्रमाणित हो जाता है।
अनुशंसाएँ
- सभी प्रमाणीकरण और सत्र प्रबंधन आवश्यकताओं को OWASP अनुप्रयोग सुरक्षा सत्यापन मानक के अनुसार परिभाषित किया जाना चाहिए।
- URL या लॉग में कभी भी कोई क्रेडेंशियल उजागर न करें।
- XSS दोषों से बचने के लिए भी मजबूत प्रयास किए जाने चाहिए, जिनका उपयोग सत्र आईडी चुराने के लिए किया जा सकता है।
असुरक्षित प्रत्यक्ष वस्तु संदर्भ
विवरण
यह तब होता है जब कोई डेवलपर किसी आंतरिक कार्यान्वयन ऑब्जेक्ट, जैसे कि फ़ाइल, निर्देशिका, या डेटाबेस कुंजी को URL या FORM पैरामीटर के रूप में प्रदर्शित करता है। हमलावर इस जानकारी का उपयोग अन्य ऑब्जेक्ट तक पहुँचने के लिए कर सकता है और अनधिकृत डेटा तक पहुँचने के लिए भविष्य में हमला कर सकता है।
निहितार्थ
- इस भेद्यता का उपयोग करके, हमलावर अनधिकृत आंतरिक वस्तुओं तक पहुंच प्राप्त कर सकता है, डेटा को संशोधित कर सकता है या एप्लिकेशन से समझौता कर सकता है।
असुरक्षित वस्तुएं
- यूआरएल में.
उदाहरण:
निम्नलिखित URL में “userid” बदलने से हमलावर अन्य उपयोगकर्ता की जानकारी देख सकता है।
http://www.vulnerablesite.com/userid=123 संशोधित http://www.vulnerablesite.com/userid=124
एक हमलावर उपयोगकर्ता आईडी मान बदलकर दूसरों की जानकारी देख सकता है।
अनुशंसाएँ:
- प्रवेश नियंत्रण जांच लागू करें.
- URL में ऑब्जेक्ट संदर्भों को उजागर करने से बचें.
- सभी संदर्भ ऑब्जेक्ट्स के लिए प्राधिकरण सत्यापित करें.
क्रॉस साइट अनुरोध जालसाजी
विवरण
क्रॉस साइट अनुरोध जालसाजी क्रॉस साइट से आया एक जाली अनुरोध है।
सीएसआरएफ हमला एक ऐसा हमला है जो तब होता है जब कोई दुर्भावनापूर्ण वेबसाइट, ईमेल या प्रोग्राम उपयोगकर्ता के ब्राउज़र को किसी विश्वसनीय साइट पर अवांछित कार्रवाई करने के लिए प्रेरित करता है, जिसके लिए उपयोगकर्ता वर्तमान में प्रमाणित है।
CSRF हमला, लॉग-ऑन पीड़ित के ब्राउज़र को एक जाली HTTP अनुरोध भेजने के लिए मजबूर करता है, जिसमें पीड़ित की सत्र कुकी और अन्य स्वचालित रूप से शामिल प्रमाणीकरण जानकारी शामिल होती है, और यह अनुरोध एक असुरक्षित वेब अनुप्रयोग को भेजा जाता है।
जब उपयोगकर्ता मूल वेबसाइट पर लॉग इन करके URL पर क्लिक करेगा तो हमलावर द्वारा पीड़ित को एक लिंक भेजा जाएगा, जिससे वेबसाइट से डेटा चोरी हो जाएगा।
निहितार्थ
- इस भेद्यता का उपयोग करके हमलावर उपयोगकर्ता की प्रोफ़ाइल जानकारी बदल सकता है, स्थिति बदल सकता है, व्यवस्थापक की ओर से नया उपयोगकर्ता बना सकता है, आदि।
असुरक्षित वस्तुएं
- उपयोगकर्ता प्रोफ़ाइल पृष्ठ
- उपयोगकर्ता खाता प्रपत्र
- व्यावसायिक लेनदेन पृष्ठ
उदाहरण
पीड़ित वैध क्रेडेंशियल्स का उपयोग करके बैंक की वेबसाइट पर लॉग इन है। उसे एक हमलावर से मेल प्राप्त होता है जिसमें लिखा होता है, "कृपया इस कारण के लिए $1 दान करने के लिए यहाँ क्लिक करें।"
जब पीड़ित उस पर क्लिक करेगा, तो एक विशेष खाते में $1 दान करने के लिए एक वैध अनुरोध बनाया जाएगा।
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
हमलावर इस अनुरोध को पकड़ लेता है और नीचे दिया गया अनुरोध बनाता है तथा उसमें "मैं कारण का समर्थन करता हूं" लिखा हुआ बटन डाल देता है।
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
चूंकि सत्र प्रमाणित है और अनुरोध बैंक की वेबसाइट के माध्यम से आ रहा है, इसलिए सर्वर हमलावर को 1000 डॉलर हस्तांतरित कर देगा।
सिफारिश
- संवेदनशील कार्य करते समय उपयोगकर्ता की उपस्थिति अनिवार्य करें.
- CA जैसे तंत्र को लागू करेंPTCHA, पुनः प्रमाणीकरण, और विशिष्ट अनुरोध टोकन।
सुरक्षा गलत कॉन्फ़िगरेशन
विवरण
सुरक्षा कॉन्फ़िगरेशन को एप्लिकेशन, फ्रेमवर्क, एप्लिकेशन सर्वर, वेब सर्वर, डेटाबेस सर्वर और प्लेटफ़ॉर्म के लिए परिभाषित और तैनात किया जाना चाहिए। यदि इन्हें ठीक से कॉन्फ़िगर किया गया है, तो हमलावर को संवेदनशील डेटा या कार्यक्षमता तक अनधिकृत पहुँच मिल सकती है।
कभी-कभी ऐसी खामियों के कारण पूरा सिस्टम ही प्रभावित हो जाता है। सॉफ़्टवेयर को अपडेट रखना भी अच्छी सुरक्षा है।
निहितार्थ
- इस भेद्यता का उपयोग करके, हमलावर अंतर्निहित प्रौद्योगिकी और अनुप्रयोग सर्वर संस्करण की जानकारी, डेटाबेस की जानकारी प्राप्त कर सकता है और कुछ और हमले करने के लिए अनुप्रयोग के बारे में जानकारी प्राप्त कर सकता है।
कमजोर वस्तुएं
- यूआरएल
- फॉर्म फील्ड्स
- इनपुट फ़ील्ड
उदाहरण
- एप्लिकेशन सर्वर एडमिन कंसोल स्वचालित रूप से इंस्टॉल हो जाता है और हटाया नहीं जाता है। डिफ़ॉल्ट खाते नहीं बदले जाते हैं। हमलावर डिफ़ॉल्ट पासवर्ड से लॉग इन कर सकता है और अनधिकृत पहुँच प्राप्त कर सकता है।
- आपके सर्वर पर डायरेक्टरी लिस्टिंग अक्षम नहीं है। हमलावर किसी भी फ़ाइल को खोजने के लिए डायरेक्टरी को आसानी से सूचीबद्ध कर सकता है।
अनुशंसाएँ
- एक मजबूत अनुप्रयोग वास्तुकला जो घटकों के बीच अच्छा पृथक्करण और सुरक्षा प्रदान करती है।
- डिफ़ॉल्ट उपयोगकर्ता नाम और पासवर्ड बदलें.
- निर्देशिका सूचीकरण अक्षम करें और पहुंच नियंत्रण जांच लागू करें।
असुरक्षित क्रिप्टोग्राफ़िक संग्रहण
विवरण
असुरक्षित क्रिप्टोग्राफिक भंडारण एक सामान्य कमजोरी है जो तब उत्पन्न होती है जब संवेदनशील डेटा को सुरक्षित रूप से संग्रहीत नहीं किया जाता है।
उपयोगकर्ता की क्रेडेंशियल, प्रोफ़ाइल जानकारी, स्वास्थ्य विवरण, क्रेडिट कार्ड की जानकारी आदि वेबसाइट पर संवेदनशील डेटा जानकारी के अंतर्गत आती हैं।
यह डेटा एप्लिकेशन डेटाबेस पर संग्रहीत किया जाएगा। जब यह डेटा एन्क्रिप्शन या हैशिंग* का उपयोग न करके अनुचित तरीके से संग्रहीत किया जाता है, तो यह हमलावरों के लिए असुरक्षित होगा।
(*हैशिंग स्ट्रिंग अक्षरों को निश्चित लंबाई की छोटी स्ट्रिंग या कुंजी में बदलना है। स्ट्रिंग को डिक्रिप्ट करने के लिए, कुंजी बनाने के लिए उपयोग किया जाने वाला एल्गोरिदम उपलब्ध होना चाहिए)
निहितार्थ
- इस कमजोरी का उपयोग करके, हमलावर कमजोर रूप से संरक्षित डेटा को चुरा सकता है, उसे संशोधित कर सकता है, जिससे पहचान की चोरी, क्रेडिट कार्ड धोखाधड़ी या अन्य अपराध हो सकते हैं।
कमजोर वस्तुएं
- अनुप्रयोग डेटाबेस.
उदाहरण
बैंकिंग एप्लीकेशन में से एक में, पासवर्ड डेटाबेस सभी के पासवर्ड को स्टोर करने के लिए अनसाल्टेड हैश * का उपयोग करता है। SQL इंजेक्शन दोष हमलावर को पासवर्ड फ़ाइल को पुनः प्राप्त करने की अनुमति देता है। सभी अनसाल्टेड हैश को कुछ ही समय में ब्रूट फोर्स किया जा सकता है, जबकि सॉल्टेड पासवर्ड को प्राप्त करने में हज़ारों साल लग सकते हैं।
(*अनसाल्टेड हैश - साल्ट मूल डेटा में जोड़ा गया एक यादृच्छिक डेटा है। हैशिंग से पहले पासवर्ड में साल्ट जोड़ा जाता है)
अनुशंसाएँ
- उचित मजबूत मानक एल्गोरिदम सुनिश्चित करें। खुद के क्रिप्टोग्राफ़िक एल्गोरिदम न बनाएं। केवल स्वीकृत सार्वजनिक एल्गोरिदम जैसे AES, RSA पब्लिक की क्रिप्टोग्राफी और SHA-256 आदि का उपयोग करें।
- सुनिश्चित करें कि ऑफसाइट बैकअप एन्क्रिप्टेड हों, लेकिन कुंजियों का प्रबंधन और बैकअप अलग से किया जाए।
URL एक्सेस को प्रतिबंधित करने में विफलता
विवरण
वेब अनुप्रयोग संरक्षित लिंक और बटन प्रस्तुत करने से पहले URL एक्सेस अधिकारों की जांच करते हैं। अनुप्रयोगों को हर बार इन पृष्ठों तक पहुँचने पर समान एक्सेस नियंत्रण जाँच करने की आवश्यकता होती है।
अधिकांश अनुप्रयोगों में, विशेषाधिकार प्राप्त पृष्ठ, स्थान और संसाधन विशेषाधिकार प्राप्त उपयोगकर्ताओं को प्रस्तुत नहीं किए जाते हैं।
एक बुद्धिमान अनुमान के अनुसार, एक हमलावर विशेषाधिकार पृष्ठों तक पहुँच सकता है। एक हमलावर संवेदनशील पृष्ठों तक पहुँच सकता है, फ़ंक्शन को लागू कर सकता है और गोपनीय जानकारी देख सकता है।
निहितार्थ
- इस भेद्यता का उपयोग करके हमलावर, एप्लिकेशन में लॉग इन किए बिना, अनधिकृत URL तक पहुँच प्राप्त कर सकता है और भेद्यता का फायदा उठा सकता है। हमलावर संवेदनशील पृष्ठों तक पहुँच सकता है, फ़ंक्शन को लागू कर सकता है और गोपनीय जानकारी देख सकता है।
असुरक्षित वस्तुएं:
- URLs
उदाहरण
- हमलावर ने देखा कि URL में भूमिका “/user/getaccounts” के रूप में दर्शाई गई है। उसने इसे “/admin/getaccounts” के रूप में संशोधित किया।
- एक हमलावर URL में भूमिका जोड़ सकता है.
http://www.vulnerablsite.com के रूप में संशोधित किया जा सकता है http://www.vulnerablesite.com/admin
अनुशंसाएँ
- सशक्त अभिगम नियंत्रण जांच लागू करें।
- प्रमाणीकरण और प्राधिकरण नीतियां भूमिका-आधारित होनी चाहिए।
- अवांछित URL तक पहुंच प्रतिबंधित करें.
अपर्याप्त ट्रांसपोर्ट लेयर सुरक्षा
विवरण
उपयोगकर्ता (क्लाइंट) और सर्वर (एप्लिकेशन) के बीच सूचना विनिमय से संबंधित है। एप्लिकेशन अक्सर नेटवर्क पर प्रमाणीकरण विवरण, क्रेडिट कार्ड की जानकारी और सत्र टोकन जैसी संवेदनशील जानकारी संचारित करते हैं।
कमजोर एल्गोरिदम का उपयोग करने या समाप्त हो चुके या अमान्य प्रमाणपत्रों का उपयोग करने या SSL का उपयोग न करने से संचार अविश्वसनीय उपयोगकर्ताओं के सामने आ सकता है, जिससे वेब एप्लिकेशन से समझौता हो सकता है या संवेदनशील जानकारी चोरी हो सकती है।
निहितार्थ
- इस वेब सुरक्षा भेद्यता का उपयोग करके, हमलावर वैध उपयोगकर्ता की क्रेडेंशियल्स को चुरा सकता है और एप्लिकेशन तक पहुंच प्राप्त कर सकता है।
- क्रेडिट कार्ड की जानकारी चुरा सकते हैं.
कमजोर वस्तुएं
- नेटवर्क पर भेजा गया डेटा.
अनुशंसाएँ
- सुरक्षित HTTP सक्षम करें और केवल HTTPS पर क्रेडेंशियल स्थानांतरण लागू करें।
- सुनिश्चित करें कि आपका प्रमाणपत्र वैध है और समाप्त नहीं हुआ है।
उदाहरण:
1. SSL का उपयोग न करने वाले किसी एप्लिकेशन में, हमलावर केवल नेटवर्क ट्रैफ़िक की निगरानी करेगा और एक प्रमाणित पीड़ित सत्र कुकी का निरीक्षण करेगा। हमलावर उस कुकी को चुरा सकता है और मैन-इन-द-मिडिल हमला कर सकता है।
अमान्य रीडायरेक्ट और फ़ॉरवर्ड
विवरण
वेब अनुप्रयोग किसी इच्छित उद्देश्य के लिए उपयोगकर्ताओं को अन्य पृष्ठों पर पुनर्निर्देशित करने और अग्रेषित करने के लिए कुछ विधियों का उपयोग करता है।
यदि अन्य पृष्ठों पर रीडायरेक्ट करते समय उचित सत्यापन नहीं किया जाता है, तो हमलावर इसका उपयोग कर सकते हैं और पीड़ितों को फ़िशिंग या मैलवेयर साइटों पर रीडायरेक्ट कर सकते हैं, या अनधिकृत पृष्ठों तक पहुंचने के लिए फॉरवर्ड का उपयोग कर सकते हैं।
निहितार्थ
- हमलावर उपयोगकर्ता को एक ऐसा URL भेज सकता है जिसमें वास्तविक URL के साथ-साथ कोडित दुर्भावनापूर्ण URL भी शामिल हो। हमलावर द्वारा भेजे गए URL के वास्तविक भाग को देखकर उपयोगकर्ता उसे ब्राउज़ कर सकता है और उसका शिकार बन सकता है।
उदाहरण
1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
संशोधित
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
अनुशंसाएँ
- एप्लिकेशन में रीडायरेक्ट और फ़ॉरवर्ड का उपयोग करने से बचें। यदि उपयोग किया जाता है, तो गंतव्य की गणना में उपयोगकर्ता मापदंडों का उपयोग न करें।
- यदि गंतव्य पैरामीटर से बचा नहीं जा सकता है, तो सुनिश्चित करें कि दिया गया मान मान्य है, तथा उपयोगकर्ता के लिए अधिकृत है।
