2010-11-29 21 views
32

कई सुरक्षा विशेषज्ञों अतीत में कहा है कि प्रवेश पृष्ठ ssl https पर होना चाहिए होना चाहिए। तो क्या होगा यदि मेरा लॉगिन एक ब्लॉक है जो सभी पृष्ठों पर प्रदर्शित होता है। क्या इसका मतलब है कि मेरी पूरी वेबसाइट को https होना चाहिए?लॉगिन एक https पृष्ठ

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

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

+7

मुझे 75-पॉइंट बक्षीस दिखाई नहीं देता है। – Reinderien

+0

प्रश्न 6 मिनट पुराना है, अभी तक एक उपहार नहीं जोड़ा जा सकता है (और यह एक पेशकश करने के लिए समयपूर्व है)। – Quentin

+1

हम सभी को जवाब पता है, लेकिन आपकी बाउंटी घोषणा हमें जवाब देने से रोकती है :) – Michael

उत्तर

30

मैंने पढ़ा यह http पर प्रपत्र डाल लेकिन https पर पोस्ट करने के लिए संभव है, लेकिन मैं किसी को कह रही है कि यह मध्यम हमले में एक आदमी के साथ इस्तेमाल किया जा सकता पढ़ें। क्या कोई इसकी पुष्टि कर सकता है?

हां। प्रपत्र HTTP पर परोसा जाता है, इसलिए बीच में एक आदमी उसमें परिवर्तन इंजेक्षन सकता है (उदाहरण के लिए, तो यह पहले फ़ॉर्म प्रविष्टियों को अपने स्वयं के सर्वर से साख भेजता है)।

एक व्यावहारिक जवाब कैसे सुरक्षित रूप से इस

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

यदि सुरक्षा इससे कोई फर्क नहीं पड़ता है, तो प्रत्येक पृष्ठ पर लॉगिन फॉर्म न डालें। बस इसके बजाय लॉगिन पेज का एक लिंक है।

+0

यहां एक और जवाब पहले एक और जवाब था, लेकिन मुझे लगता है कि मालिक ने नीचे वोट के कारण इसे हटा दिया। वह कह रहा था कि फेसबुक मुख्य पृष्ठ के लिए http का उपयोग करता है लेकिन https में फॉर्म पोस्ट करता है जैसे कि मैं सवाल में पूछ रहा था। मैंने अपना कोड चेक किया और वास्तव में वे 'https: // login.facebook.com/login.php' करते हैं तो क्या कोई ऐसी चीज है जिसे हम याद कर रहे हैं, या वे यहां गलत कॉल कर रहे हैं? मैं बस सोच रहा हूं क्योंकि फेसबुक बड़े कुत्ते हैं, अगर उन्हें वास्तव में असुरक्षित है तो उन्हें यह सामान पता होना चाहिए? कोई टिप्पणी? – sami

+11

फेसबुक गलत कॉल कर रहा है (जो उनके लिए सुरक्षा या गोपनीयता से संबंधित कुछ भी असामान्य नहीं है)। फायरशेप (उत्तर में जुड़ा हुआ) एसएसएल अनुभाग के बाद उनकी सुरक्षा में एक दोष दिखाता है, लेकिन प्री-एसएसएल अनुभाग भी कमजोर है। – Quentin

+0

फेसबुक खातों को नियमित रूप से समझौता किया जा रहा है, लेकिन वे इसके बारे में कुछ भी नहीं करते हैं। सभी यातायात के लिए HTTPS का उपयोग करने से शायद उनके बुनियादी ढांचे को अपंग कर दिया जाएगा। – cspolton

3

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

+0

का उपयोग OpenID वास्तव में एक सुरुचिपूर्ण समाधान है, की व्याख्या के लिए इस – milovanderlinden

7

सरल जवाब "हाँ" अपने प्रवेश पृष्ठ और वेबसाइटों के बाकी SSL पर पेश की जानी चाहिए

और यहाँ कारण है कि एसएसएल कार्यान्वयन पूछे जाने वाले प्रश्न से:

+0

+1 साझा करने के लिए धन्यवाद क्यों सब कुछ एसएसएल – sleske

+2

सब कुछ होने के लिए एसएसएल कह सबको linux का उपयोग करना चाहिए की तरह है, और webbrowser के रूप में फ़ायरफ़ॉक्स, और रूस में निर्मित कारों की जरूरत है कह रही है की जरूरत है। .. वेब अनुप्रयोगों और साइटों को बनाने के समझौते के बारे में है, और मैं अपने ऐप को सुरक्षित करने और उपयोगकर्ताओं को क्रेडेंशियल एक्सेस करने का सबसे अच्छा तरीका पसंद करूंगा। लेकिन मुझे अभी भी इसका जवाब नहीं मिल रहा है। – milovanderlinden

+0

मैंने यह उत्तर एक प्लस भी दिया। लिंक बहुत समझाते हैं, केवल एक चीज जो मुझे पसंद नहीं है वह है कि अधिकांश जवाब "नहीं आपको नहीं चाहिए" या "नहीं, आप नहीं कर सकते" मुझे कुछ और समाधान और कम अवरोधक पसंद आएंगे। – milovanderlinden

0

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

नहीं। <form> का लक्ष्य ब्राउज़र द्वारा उपयोग किए जाने वाले एक ताजा कॉल है।

यूआरएल http://example.com/ का दौरा किया गया है और पृष्ठ की सामग्री ब्राउज़र द्वारा रेंडर किया गया है, असुरक्षित कनेक्शन बंद कर दिया है (हाँ। यह खुला रखा जा सकता है [Keep-Alive]। लेकिन उस URL के अनुरोध है ख़त्म होना)।

साइट के लॉगिन लक्ष्य https://example.com/ एसएसएल-सत्र के लिए एक अलग सर्वर पोर्ट (आमतौर पर 443) और पूर्व पेज से कोई डेटा (सिवाय शायद "संदर्भ") प्रयोग किया जाता है का उपयोग कर सर्वर और ग्राहक के बीच बातचीत की जाएगी/प्रेषित के बाद सुरक्षित कनेक्शन स्थापित किया गया है।

मैंने पढ़ा है कि फॉर्म को http पर रखना संभव है लेकिन इसे https पर पोस्ट करें, लेकिन मैंने किसी को यह कहते हुए पढ़ा कि इसका उपयोग मध्य हमले में एक आदमी के साथ किया जा सकता है। क्या कोई इसकी पुष्टि कर सकता है?

हां। प्रपत्र HTTP पर परोसा जाता है, इसलिए बीच में एक आदमी उसमें परिवर्तन इंजेक्षन सकता है (उदाहरण के लिए, तो यह पहले फ़ॉर्म प्रविष्टियों को अपने स्वयं के सर्वर से साख भेजता है)।

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

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

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

+0

एक मैन-इन-द-बीच हमले में, साइट पर समझौता नहीं किया गया है। क्लाइंट और सर्वर के बीच कनेक्शन है। एसएसएल समझौता किए जाने वाले कोड के खिलाफ सुरक्षा करता है क्योंकि यह प्रमाणीकरण के साथ-साथ एन्क्रिप्शन प्रदान करता है। एसएसएल चोरी की जा रही कुकीज़ के खिलाफ सुरक्षा करता है क्योंकि यह एन्क्रिप्शन प्रदान करता है। – Quentin

+0

सहमत हुए। फिर भी DNS स्पूफ़िंग किसी साइट से समझौता कर सकती है और एसएसएल पर भी काम करती है। –

+1

स्पूफ़र को उस होस्टनाम के लिए SSL प्रमाणपत्र कैसे मिलेगा, जिसे पुनर्निर्देशित किया गया है जिसे ब्राउज़र द्वारा भरोसा किया गया प्राधिकरण द्वारा हस्ताक्षरित किया गया है? – Quentin

0

भले ही आपने लॉगिन ब्लॉक को आईफ्रेम में डालने का प्रयास किया जो https का उपयोग करता है, एक आदमी-बीच-मध्य हमले आसानी से कि iframe src का बदल सकता है, तो आप या तो loginbox एक लॉगिन लिंक (https के साथ लॉगिन पेज) या आप उन सभी वेबपृष्ठों लॉगिन बक्से है कि के लिए SSL के साथ अपनी वेबसाइट को चलाने के लिए अधिक संसाधनों की आवश्यकता होगी ...

+0

अगर हम एमआईटीएम को अपने चयन के आईफ्रेम में src विशेषता को बदलने की अनुमति देते हैं - वह लॉगिन लिंक पर href क्यों नहीं बदल सकता है? –

+0

आपको कुछ साइटें आपको चेतावनी दे सकती हैं कि "सुनिश्चित करें कि यूआरएल https से शुरू होता है", इसलिए कम से कम उपयोगकर्ता (जो निर्देशों का पालन करते हैं) अभी भी अपने पते पट्टी में https url देख सकते हैं, जबकि वे iframe को नहीं जानते हैं एसएसएल के तहत था या नहीं! । और जिन लोगों ने ध्यान नहीं दिया, उनके लिए यह गलती है ... –

4

ठीक है, अगर आप लॉग इन के लिए एसएसएल का उपयोग नहीं करते हैं, तो उपयोगकर्ता का पासवर्ड किसी भी व्यक्ति को प्रकट किया जा सकता है जिसका क्लाइंट-सर्वर संचार (मूल रूप से डेटा स्ट्रीम पढ़ना) सुनना है। (जो अच्छा नहीं है ^^)

के रूप में कहा goreSplatter ऊपर, आप आसानी से सुरक्षित समाप्ति बिंदु को प्रपत्र लक्ष्य निर्धारित कर सकते हैं द्वारा (अर्थात https://site.com/login) और एक सुरक्षित कनेक्शन उपयोगकर्ता की साख भेजने और प्रतिक्रिया प्राप्त करने के लिए इस्तेमाल किया जाएगा।

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

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

+1

इस दृष्टिकोण के साथ समस्या यह है कि एक सत्र को अपहरण करना "पूरे खाते को चोरी करना" जैसा ही है ... – sleske

1

क्या आपके पास यूआई अवधारणा को फिर से डिजाइन करने का विकल्प है?विचार: प्रत्येक पृष्ठ पर सूचनात्मक लॉगिन UI है लेकिन वास्तविक लॉगिन नियंत्रण नहीं है। आपका नया जानकारी नियंत्रण सूची जाएगा:

  1. Logged In As <user_name> या Not Logged In
  2. Login या Logout लिंक राज्य पर निर्भर करता

लिंक तो एक लॉगिन पॉप अप पेज जिनकी सामग्री पूरी तरह से सुरक्षित हैं दिखाएगी।

यह दृष्टिकोण आपको आपके पास पहले से ही (प्रत्येक पृष्ठ पर कुछ लॉगिन कार्यक्षमता) के करीब ले जाएगा, लेकिन इस तरह से मार्गित/स्तरित किया गया है कि आपका प्रमाणीकरण एसएसएल पर पूरी तरह से सुरक्षित है।

1

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

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

उपरोक्त अच्छे उत्तर, साथ ही सबकुछ और इस मामले के बारे में अपनी खुद की विचारधारा प्राप्त करें!

गुड लक।

संबंधित मुद्दे