HTTP बेसिक ऑथेंटिकेशन क्रेडेंशियल URL और एन्क्रिप्शन में पास हुआ


250

मेरे पास HTTPS और HTTP प्रमाणीकरण क्रेडेंशियल के बारे में एक प्रश्न है।

मान लीजिए कि मैं HTTP प्रमाणीकरण के साथ एक URL सुरक्षित करता हूं:

<Directory /var/www/webcallback>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/passwd/passwords
Require user gooduser
</Directory>

मैं तब URL को HTTPS के माध्यम से दूरस्थ सिस्टम से एक्सेस करता हूं, URL में क्रेडेंशियल पास करता हूं:

https://gooduser:secretpassword@www.example.com/webcallback?foo=bar

क्या उपयोगकर्ता नाम और पासवर्ड स्वचालित रूप से SSL एन्क्रिप्टेड होंगे? क्या GET और POST के लिए भी यही सच है? मुझे इस जानकारी के साथ एक विश्वसनीय स्रोत का पता लगाने में मुश्किल समय आ रहा है।



बहुत पुराना प्रश्न लेकिन फिर भी: इस दृष्टिकोण को ietf.org/rfc/rfc3986.txt द्वारा चित्रित किया गया है : "प्रारूप का उपयोग" उपयोगकर्ता: पासवर्ड "userinfo क्षेत्र में पदावनत है।"
मैडब्रेक्स

जवाबों:


237

क्या उपयोगकर्ता नाम और पासवर्ड स्वचालित रूप से SSL एन्क्रिप्टेड होंगे? GET और POST के लिए भी यही सच है

हाँ हाँ हाँ।

संपूर्ण संचार (DNS लुकअप के लिए सहेजें यदि होस्टनाम के लिए आईपी पहले से ही कैश नहीं है) एन्क्रिप्टेड है जब एसएसएल उपयोग में है।


25
+1। Url सहित GET और POST एन्क्रिप्टेड हैं। मैं केवल जोड़ूंगा - फायरबग और टैम्पर डेटा जैसे उपकरण केवल अन-एन्क्रिप्टेड परिणाम दिखाने में सक्षम हैं क्योंकि वे ब्राउज़र का एक हिस्सा हैं और इसलिए एन्क्रिप्ट किए जाने से पहले अनुरोध को रोकना संभव है। एक बार तार पर भेजे जाने के बाद, सब कुछ एन्क्रिप्ट किया गया है।
श्रीपति कृष्णन

21
स्पष्ट होने के लिए, सब कुछ लेकिन डोमेन एन्क्रिप्ट किया गया है। इस भर में किसी को भी stumbles और एक अधिक विस्तृत उत्तर चाहते हैं, को देखने के answers.google.com/answers/threadview/id/758002.html
rcourtna

7
पूर्णता के लिए, " इंटरनेट एक्सप्लोरर वेब साइट के पते (HTTP या HTTPS URL) में उपयोगकर्ता नाम और पासवर्ड का समर्थन नहीं करता है " केवल इंटरनेट एक्सप्लोरर संस्करण 3.0 से 6.0 की तरह दिखता है जो HTTP या HTTPS URL के लिए निम्नलिखित सिंटैक्स का समर्थन करता है: http (s): //username:password@server/resource.ext नोट: डिफ़ॉल्ट व्यवहार में यह परिवर्तन अन्य प्रोटोकॉल को प्रभावित नहीं करता है। उदाहरण के लिए, 832894 सुरक्षा अद्यतन को स्थापित करने के बाद भी आप FTP URL में उपयोगकर्ता जानकारी को शामिल कर सकते हैं।
ल्यूक

इस उत्तर में न तो कोई विश्वसनीय स्रोत है और न ही आगे स्पष्टीकरण।
जेन्स पेगासा

26

हां, इसे एन्क्रिप्ट किया जाएगा।

आप इसे समझेंगे यदि आप बस यह देखते हैं कि पर्दे के पीछे क्या होता है।

  1. ब्राउज़र या एप्लिकेशन पहले URL को तोड़ देगा और DNS क्वेरी का उपयोग करके होस्ट का आईपी प्राप्त करने का प्रयास करेगा। अर्थात: डोमेन के आईपी पते (www.example.com) को खोजने के लिए DNS अनुरोध किया जाएगा। कृपया ध्यान दें कि इस अनुरोध के माध्यम से कोई अन्य जानकारी नहीं भेजी जाएगी।
  2. ब्राउज़र या एप्लिकेशन DNS अनुरोध से प्राप्त आईपी पते के साथ एक एसएसएल कनेक्शन शुरू करेगा। प्रमाणपत्रों का आदान-प्रदान किया जाएगा और यह परिवहन स्तर पर होता है। इस स्तर पर कोई आवेदन स्तर की जानकारी हस्तांतरित नहीं की जाएगी। याद रखें कि मूल प्रमाणीकरण HTTP का हिस्सा है और HTTP एक एप्लिकेशन स्तर प्रोटोकॉल है। ट्रांसपोर्ट लेयर टास्क नहीं।
  3. एसएसएल कनेक्शन स्थापित करने के बाद, अब आवश्यक डेटा सर्वर को पारित किया जाएगा। यानी: पथ या URL, पैरामीटर और मूल प्रमाणीकरण उपयोगकर्ता नाम और पासवर्ड।

-5

जरूरी नहीं कि सच हो। यह तार पर एन्क्रिप्ट किया जाएगा लेकिन यह अभी भी लॉग सादे पाठ में भूमि है


17
वेब सर्वर अनुरोधों से उपयोगकर्ता नाम और पासवर्ड क्या लॉग करता है? यह एक असुरक्षित वेब सर्वर का एक नरक होगा।
एंड्रयू बार्बर

1
हाँ यह सच नहीं है। यह संभव है कि यह जानकारी लॉग करने के लिए अपाचे को निर्देश दे, लेकिन यह निश्चित रूप से डिफ़ॉल्ट रूप से ऐसा नहीं कर रहा है।
डगडब्लू

27
@ ब्रैंड शायद क्वेरी स्ट्रिंग में "URL" में सोच रहा था (उदाहरण के लिए; उपयोगकर्ता = bob & pw = 123hackmeplz)। यह सर्वर लॉग में समाप्त हो सकता है।
माइक ग्राफ

5
संबंधित: "जब आप उदाहरण के लिए कर्ल के साथ क्लाइंट पर उस URL को कॉल करते हैं, तो उपयोगकर्ता नाम और पासवर्ड प्रक्रिया सूची में स्पष्ट रूप से दिखाई देंगे और बैश इतिहास फ़ाइल में बदल सकते हैं।" - stackoverflow.com/a/4981309
हॉकी पार्कर

1
@ zb226 पूछने वाले ने विशेष रूप से URL में क्रेडेंशियल्स डालने का उल्लेख किया है।
लैम्बर्ट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.