SSL कनेक्शन के बिना वेबसाइट तक पहुंच कैसे रोकें?

Question

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

हालांकि, मैंने देखा है कि मैं अभी भी गैर-सुरक्षित रूप से वेबसाइट तक पहुंच सकता हूं, अर्थात। के httpबजाय का उपयोग करके https।

मैं गैर-सुरक्षित तरीके से वेबसाइट का उपयोग करने वाले लोगों को कैसे रोक सकता हूं?

अगर मैं वेबसाइट पर एक निर्देशिका है, जैसे। samples/क्या मैं इस निर्देशिका में गैर-सुरक्षित कनेक्शन को रोक सकता हूं?

Answer 1

दुर्भाग्य से, इस समस्या का एकमात्र सामान्य समाधान यह है कि आप अपने उपयोगकर्ताओं को https://केवल यह सुनिश्चित करें और सुनिश्चित करें कि वे केवल उसी का उपयोग करने की उम्मीद करते हैं। यह अंततः उपयोगकर्ता की ज़िम्मेदारी है कि वे एसएसएल / टीएलएस का उपयोग कर रहे हैं, जैसा कि वे उम्मीद करते हैं।

अन्य समाधान मानव-में-मध्य हमलों के लिए असुरक्षित हैं, भले ही वेबसाइट केवल एसएसएल / टीएलएस कनेक्शन स्वीकार करती है। हमलावर ट्रैफ़िक को इंटरसेप्ट कर सकते हैं http://example.com(जैसा कि उपयोगकर्ता द्वारा अनुरोध किया गया है, भले ही example.comवह पोर्ट पर भी नहीं सुन रहा हो) और इसे अपने स्वयं के कनेक्शन से https://example.comबदलकर, इसे उपयोगकर्ता के पास वापस भेज दें।

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

विभिन्न तकनीकें हैं जिनका उपयोग आप उपयोगकर्ता को HTTPS साइट पर मार्गदर्शन करने के लिए कर सकते हैं, और उनका उपयोग करना बुरा नहीं है (हालाँकि यह सक्रिय MITM हमलावरों के खिलाफ उनकी रक्षा नहीं करेगा)।

सबसे पहले, यदि आपके पास ऐसा कुछ भी नहीं है जिसे वेबसर्वर पर सादे HTTP में परोसा जाना चाहिए, तो पोर्ट 80 को बंद कर दें (जैसे Listen 80Apache Httpd के कॉन्फ़िगरेशन में निकालें )। उपयोगकर्ताओं को https://हर समय उपयोग करना होगा , जो असुविधाजनक हो सकता है।

दूसरे, एक विशेष मार्ग (या तो के लिए अपने अपाचे httpd विन्यास खंड में Locationया Directory), का उपयोग SSLRequireSSLनिर्देश : यह (भले ही आप वास्तव में एक विकल्प के बंदरगाह पर यह कॉन्फ़िगर कर दिया है) SSL / TLS के उपयोग की आवश्यकता होगी। अन्य वेब सर्वरों में संभवतः समान निर्देश होते हैं।

तीसरा, आप mod_rewriteअपने कोड का उपयोग करके या उसके भीतर एक पुनर्निर्देशन का उपयोग कर सकते हैं (यदि यह एक अनुप्रयोग है)। ऐसा कुछ करना चाहिए, एक विशिष्ट स्थान के लिए ( विशेष चर देखेंHTTPS ; आप 302 का भी उपयोग कर सकते हैं, लेकिन 301 बेहतर है यदि यह अधिक स्थायी हो):

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(samples/.*)$ https://example.com/$1 [R=301,L]

इससे भी महत्वपूर्ण बात, सुनिश्चित करें कि उस सुरक्षित अनुभाग के सभी लिंक का उपयोग करें https://। आपके लिए काम करने के लिए कभी भी स्वचालित पुनर्निर्देशन पर भरोसा न करें। इस कारण से, मैं विकास चरण के दौरान इसका उपयोग नहीं करने की सलाह दूंगा ।

हालांकि, मैंने देखा है कि मैं अभी भी गैर-सुरक्षित रूप से वेबसाइट तक पहुंच सकता हूं, अर्थात। के httpबजाय का उपयोग करके https।

दोनों के लिए समान विन्यास उपयोग कर रहे हैं यह भी लग रहा है httpऔर https। यदि आप Apache Httpd का उपयोग कर रहे हैं, तो मैं दो अलग-अलग VirtualHosts में कॉन्फ़िगरेशन को विभाजित करने का सुझाव दूंगा : पोर्ट 80 के लिए एक और पोर्ट 443 के लिए एक। उनके पास बिल्कुल समान कॉन्फ़िगरेशन होने की आवश्यकता नहीं है: बस वह मत डालें जो केवल HTTPS के लिए है HTTP वर्चुअल होस्ट में बिल्कुल।

---

ऊपर बताई गई समस्याओं को कम करने का एक तरीका HTTP स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी का उपयोग करना है , जो इसे समर्थन करने वाले ब्राउज़रों के लिए है (यह पूरे मेजबान पर लागू होता है जहां तक ​​मुझे पता है)। यदि https://पुनर्निर्देशन के बिना उपयोग नहीं किया जाता है, तो बहुत पहले कनेक्शन को अभी भी उजागर किया जा सकता है, लेकिन किसी भी तरह की अपेक्षा वाली साइटों की पूर्व-लोड की गई सूची https:// (और एचएसटीएस के लिए सक्षम) होना संभव है।

Comments

अच्छी जानकारी, यह कैसे जीमेल करता है? - चीजों को देखने से वे https को मजबूर करते हैं।

— toomanyairmiles

वे एक पुनर्निर्देशन का उपयोग करते हैं। यह ठीक काम करता है, बशर्ते कि उपयोगकर्ता के रूप में आपको इसकी उम्मीद है https://mail.google.com। यदि, एक उपयोगकर्ता के रूप में, आप इसे साथ काम करते देखते हैं http://mail.google.com, तो संभवतः एक MITM है जो अनुरोधों को वास्तविक रूप से सम्‍मिलित करता है https://mail.google.com। दुर्भाग्य से, जीमेल इस बारे में बहुत कुछ नहीं कर सकता है कि यदि उपयोगकर्ता स्वयं जाँच नहीं करते हैं। वास्तविक जीवन में समान सिद्धांत: यदि ऐलिस बॉब से बात करना चाहता है, लेकिन आईडी की पुष्टि करने के बजाय चक (जो बॉब होने का दावा करता है) से बात करता है, बॉब इस बातचीत के बारे में नहीं जान पाएंगे और ऐसा करने में सक्षम नहीं होंगे इसके बारे में कुछ भी। यह ऐलिस की जिम्मेदारी है।

— ब्रूनो

मैंने इसके चारों ओर कुछ PHP स्क्रिप्ट्स देखी हैं, अगर यह HTTPS से जुड़ा होगा और SSL को HTTPS एड्रेस का उपयोग न करने पर रीडायरेक्ट करेगा। यह निश्चित रूप से, कोई आसान काम नहीं है जब तक आप अपनी साइट का निर्माण नहीं कर रहे हैं।

— अनाम पेंगुइन

@AnnonomusPerson, यह बिलकुल एक ही सिद्धांत है और यही HTTP से HTTPS पर फिर से लिखना है। चाहे आप इसे प्रोग्रामेटिक रूप से करें या कॉन्फ़िगरेशन से कोई फर्क नहीं पड़ता, यह अभी भी सादे HTTP में एक प्रारंभिक अनुरोध के साथ पुनर्निर्देशन है, जो एक ही समस्या प्रस्तुत करता है।

— ब्रूनो

Answer 2

आपको केवल http ट्रैफ़िक को https पर रीडायरेक्ट करना है - इस लेख को देखें 'रीडायरेक्ट http टू https अपाचे सिक्योर कनेक्शन - HTTPS कनेक्टिंग फोर्स' ।

एक उप-निर्देशिका के लिए इसे निर्देशिका में एक htaccess फ़ाइल में रखें।

RewriteEngine on
RewriteCondition %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://www.maindomain.com/directory/$1 [R=301,L] 

Comments

क्या आप इसे केवल कुछ उप-निर्देशिकाओं के लिए कर सकते हैं?

— सीजे

@ क्रेगज क्षमा करें, उप-निर्देशिका भाग को याद किया, उत्तर अपडेट किया गया।

— toomanyairmiles

हालांकि यह जोखिमों को थोड़ा कम करता है, यह सक्रिय MITM हमलावरों के खिलाफ काम नहीं करता है।

— ब्रूनो

Answer 3

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

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

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

संबंधित मानक: सुरक्षित कुकीज़ (यदि आपके कुकीज़ HSTS हेडर से अधिक समय तक रहते हैं), HttpOnly कुकीज़ (जब आप अपने कुकीज़ सुरक्षित कर रहे हैं), एचपीकेपी (आधुनिक ब्राउज़रों और अधिक संसाधन वाले हमलावरों के लिए)।