सवाल Http पर भेजे गए पासवर्ड के लिए हमले वैक्टर क्या हैं?


मैं किसी ऐसे वेबसाइट के लिए एसएसएल के लिए भुगतान करने के लिए ग्राहक को मनाने की कोशिश कर रहा हूं जिसके लिए लॉगिन की आवश्यकता है। मैं यह सुनिश्चित करना चाहता हूं कि मैं उन प्रमुख परिदृश्यों को सही ढंग से समझूं जिनमें कोई भेजा जा रहा पासवर्ड देख सकता है।

मेरी समझ यह है कि रास्ते में से किसी भी हॉप में एक का उपयोग कर सकते हैं पैकेट विश्लेषक क्या भेजा जा रहा है यह देखने के लिए। ऐसा लगता है कि किसी भी हैकर (या उनके मैलवेयर / बॉटनेट) एक ही सबनेट पर हो सकते हैं क्योंकि पैकेट किसी भी हॉप को अपने गंतव्य पर पहुंचने के लिए ले जाता है। क्या वह सही है?

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

क्या पैकेट विश्लेषक के साथ सुन रहे किसी के बाहर के बारे में चिंतित होने के लिए अन्य वैक्टर हैं?

मैं नेटवर्किंग और सुरक्षा नोब हूं, इसलिए अगर मैं इनमें से किसी भी गलत शब्दावली का उपयोग कर रहा हूं तो कृपया मुझे सीधे सेट करने के लिए स्वतंत्र महसूस करें।


10
2018-05-31 23:55


मूल


यदि साइट में बैंकिंग या वित्तीय विवरण, व्यक्तिगत जानकारी है, तो एसएसएल लॉगिन चरण के लिए एक पूर्व-आवश्यकता है। अगर इसे आसानी से हैक किया जा सकता है, तो यह होगा। - Mitch Wheat
मुझे इसे बंद करने का कोई कारण नहीं दिखता है। यह प्रोग्रामिंग से संबंधित है।
साझा साइट पर इस साइट पर आने वाले किसी भी व्यक्ति को उनके क्रेडिट लेते हैं, भले ही एपी एन्क्रिप्शन का उपयोग करता हो (क्योंकि हर किसी के पास भी कुंजी है)। यदि लोग अन्य साइटों पर अपने क्रेडिट का पुनः उपयोग करते हैं, तो यह एक समस्या है। - Aaron


जवाब:


इस बात का ध्यान रखना कि दूसरों ने यहां उल्लेख नहीं किया है कि कुछ ब्राउज़र आपके फॉर्म डेटा को कैश करते हैं। एसएसएल साइटों पर डिफ़ॉल्ट व्यवहार आम तौर पर तब तक कैश नहीं करना है जब तक कि आपने "मेरा पासवर्ड सहेजें" चुना न हो। आम तौर पर पासवर्ड फ़ील्ड किसी भी तरह से कैश नहीं करते हैं, लेकिन मैंने कुछ विषमताएं देखी हैं (आमतौर पर क्रेडिट कार्ड जानकारी, जो मुझे पता है वास्तव में प्रश्न का विषय नहीं है)।

दूसरी बात यह है कि एसएसएल एन्क्रिप्शन टीसीपी हैंडशेक से शुरू होता है। एक बार एसएसएल के तहत आप SSL पर एसएसएल पर एसटीएल पर HTTP को अलग नहीं कर सकते हैं (पोर्ट नंबर के माध्यम से किए गए अनुमानों के अलावा)।

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

अगर आप खत्म करते हैं तो सब कुछ सब कुछ बीच वाला व्यक्ति स्पेक्ट्रम से हमले कई संभावित हमलों पर कटौती करते हैं, यह कहना नहीं है कि आपकी साइट 'सुरक्षित' है। नीति को ज़ोनिंग भी करें चाहिए XSS हमलों से आपकी सुरक्षा में मदद करें क्योंकि यदि आपका उपयोगकर्ता आपकी साइट से पुनः निर्देशित है तो आप ज़ोन-चेंज कर रहे होंगे।


3
2018-06-01 00:22



"बंदरगाह संख्या के माध्यम से धारणाएं"? पोर्ट आमतौर पर एसएसएल (या तो HTTP या एफ़टीपी) के लिए 443 नहीं होगा? - brickner


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


4
2018-06-01 02:45



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


ऐसे प्रॉक्सी सर्वर हैं जो डेटा स्टोर कर सकते हैं।

लेकिन उपयोगकर्ताओं को पासवर्ड सुरक्षित रखने का भी दायित्व है। कई उपयोगकर्ता पासवर्ड के सीमित सेट का उपयोग करते हैं, इसलिए एक असुरक्षित साइट उदाहरण के लिए उनके होमबैंक पासवर्ड से समझौता कर सकती है।


2
2018-06-01 00:05



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


आपका विश्लेषण उचित है, आईएमएचओ।

ध्यान देने योग्य बात, मुझे लगता है कि यह है कि आपके रास्ते में कैश हो सकते हैं। तो हो सकता है कि अनुरोध कहीं लॉग हो जाए (विशेष रूप से यदि लॉगिन GET से अधिक है, जो भयानक होगा)।

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

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

लेकिन यथार्थवादी बनें। लगभग निश्चित रूप से यह हमला वेक्टर जिस तरह से उनके सिस्टम या उपयोगकर्ताओं से समझौता नहीं किया जाएगा।

HTH।


1
2018-06-01 00:04





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

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

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

हां, इस संबंध में अन्य चीजें चिंतित हैं, पैकेट स्नीफिंग से भी ज्यादा, जैसे कि XSS। वे कई हैं, और अच्छी तरह से प्रलेखित


1
2018-06-01 06:23



धन्यवाद डैनियल। मुझे लगता है कि मनमाने ढंग से नियम नहीं होना चाहिए, बल्कि यह समझना महत्वपूर्ण है कि हमारे सिद्धांतों में क्या वृद्धि हुई है। इसलिए मैं यह सुनिश्चित करना चाहता था कि मैं इस अधिकार को स्पष्ट कर सकूं। मैं एसएसएल पाने के लिए ग्राहक को मनाने में सक्षम था, शुक्र है! - KevinM


पूरे मार्ग में पैकेट के बाद, यदि इसके ऊपर HTTP पर स्नीफ किया जा सकता है और डेटा देखा जा सकता है ... भले ही आप प्रॉक्सी में HTTP का उपयोग करें जैसे टीओआर ... कटाई-हमले आदि का उपयोग कर। कोई डेटा-पैकेट को रिसाव करने के लिए प्रॉक्सी को ट्रिक कर सकता है ... इसलिए यदि संवेदनशील (पासवर्ड, व्यक्तिगत विवरण, निजी छवियां इत्यादि) के पास कुछ भी है ... तो यह केवल HTTPS पर स्थानांतरित करने के लिए उपयुक्त है।

वह भी, यहां तक ​​कि एचटीटीपीएस भी गलत कार्यान्वयन के साथ कमजोर है और उनके पर कई एसएसएल अटैक लागू हैं ... फिर भी उनको सावधानीपूर्वक कार्यान्वयन से बचा जा सकता है।

लेकिन, सादा पाठ के लिए HTTP का उपयोग करना पासवर्ड को दूर करने के लिए नौसिखिया एन / डब्ल्यू बच्चों को भी आमंत्रित करना है।


0
2018-06-01 06:51