मैं एक सुरक्षित वेब आधारित एपीआई बना रहा हूं जो HTTPS का उपयोग करता है; हालांकि, अगर मैं उपयोगकर्ताओं को इसे कॉन्फ़िगर करने की अनुमति देता हूं (क्वेरी भेजना शामिल है) क्वेरी स्ट्रिंग का उपयोग करके यह भी सुरक्षित होगा या क्या मुझे इसे POST के माध्यम से करने के लिए मजबूर होना चाहिए?एक HTTPS क्वेरी स्ट्रिंग सुरक्षित है?
हाँ, यह है।
इसलिए, भले ही क्वेरी स्ट्रिंग यह सुरक्षित है में इतिहास कैश क्वेरी स्ट्रिंग से अधिक संवेदनशील डेटा स्थानांतरित करने की सिफारिश नहीं की है।
[1] हालांकि मुझे यह ध्यान रखना होगा कि आरएफसी का कहना है कि ब्राउजर को HTTPS से HTTP में रेफरर नहीं भेजना चाहिए। लेकिन इसका मतलब यह नहीं है कि एक खराब तृतीय पक्ष ब्राउज़र टूलबार या किसी HTTPS साइट से बाहरी छवि/फ़्लैश इसे रिसाव नहीं करेगा।
हां। एक HTTPS सत्र का पूरा पाठ एसएसएल द्वारा सुरक्षित है। इसमें क्वेरी और हेडर शामिल हैं। उस संबंध में, एक पोस्ट और एक जीईटी बिल्कुल वही होगा।
आपकी विधि की सुरक्षा के अनुसार, उचित निरीक्षण किए बिना कहने का कोई वास्तविक तरीका नहीं है।
ब्राउज़र और सर्वर – JoeBloggs
हां, इस समय से आप एक HTTPS कनेक्शन स्थापित करना सुरक्षित है। POST के रूप में क्वेरी स्ट्रिंग (GET) SSL पर भेजी जाती है।
"नेटवर्क पैकेट को स्नीफ करें" बिंदु से एक जीईटी अनुरोध सुरक्षित है, क्योंकि ब्राउजर पहले सुरक्षित कनेक्शन स्थापित करेगा और फिर जीईटी पैरामीटर वाले अनुरोध को भेज देगा। लेकिन यूआरएल को उपयोगकर्ता ब्राउज़र इतिहास/स्वतः पूर्ण में संग्रहीत किया जाएगा, जो स्टोर करने के लिए एक अच्छी जगह नहीं है उदा। पासवर्ड डेटा। बेशक यह केवल तब लागू होता है जब आप व्यापक "वेबसाइट सेवा" परिभाषा लेते हैं जो ब्राउज़र से सेवा तक पहुंच सकता है, अगर आप इसे केवल अपने कस्टम एप्लिकेशन से एक्सेस करते हैं तो यह कोई समस्या नहीं होनी चाहिए।
इसलिए पासवर्ड संवाद के लिए कम से कम पोस्ट का उपयोग करना पसंद किया जाना चाहिए। साथ ही लिंक गेटेक में पोस्ट किए गए एक जीईटी यूआरएल को आपके सर्वर लॉग में लिखा जाने की अधिक संभावना है।
एसएसएल पहले मेजबान से जुड़ता है, इसलिए मेजबान का नाम और पोर्ट नंबर स्पष्ट टेक्स्ट के रूप में स्थानांतरित किया जाता है। जब होस्ट प्रतिसाद देता है और चुनौती सफल होती है, तो क्लाइंट HTTP अनुरोध को वास्तविक यूआरएल (यानी तीसरे स्लैश के बाद कुछ भी) के साथ एन्क्रिप्ट करेगा और इसे सर्वर पर भेज देगा।
इस सुरक्षा को तोड़ने के कई तरीके हैं।
"मध्य में आदमी" के रूप में कार्य करने के लिए प्रॉक्सी को कॉन्फ़िगर करना संभव है। असल में, ब्राउज़र प्रॉक्सी को वास्तविक सर्वर से कनेक्ट करने का अनुरोध भेजता है। यदि प्रॉक्सी इस तरह से कॉन्फ़िगर किया गया है, तो यह SSL के माध्यम से वास्तविक सर्वर से कनेक्ट होगा लेकिन ब्राउज़र अभी भी प्रॉक्सी से बात करेगा। तो यदि कोई हमलावर प्रॉक्सी तक पहुंच प्राप्त कर सकता है, तो वह स्पष्ट डेटा में इसके माध्यम से बहने वाले सभी डेटा देख सकता है।
आपके अनुरोध ब्राउज़र इतिहास में भी दिखाई देंगे। उपयोगकर्ता साइट को बुकमार्क करने के लिए लुभाने वाले हो सकते हैं। कुछ उपयोगकर्ताओं के पास बुकमार्क सिंक टूल्स स्थापित हैं, इसलिए पासवर्ड deli.ci.us या किसी अन्य स्थान पर समाप्त हो सकता है।
आखिरकार, किसी ने आपके कंप्यूटर को हैक किया हो और कीबोर्ड लॉगर या स्क्रीन स्क्रैपर स्थापित किया हो (और बहुत सारे ट्रोजन हॉर्स प्रकार वायरस करते हैं)। चूंकि पासवर्ड सीधे स्क्रीन पर दिखाई देता है (चूंकि पासवर्ड डायलॉग में "*" के विपरीत), यह एक और सुरक्षा छेद है।
निष्कर्ष: जब सुरक्षा की बात आती है, तो हमेशा पीटा पथ पर भरोसा करें। वहां बहुत कुछ है जिसे आप नहीं जानते हैं, इस बारे में नहीं सोचेंगे और आपकी गर्दन तोड़ देगा।
के बीच संचार की तुलना में सुरक्षा के लिए और भी कुछ है "ब्राउज़र अभी भी प्रॉक्सी से बात करेगा" बिल्कुल सही नहीं है, इसे ब्राउज़र को एक मान्य प्रमाणपत्र के साथ पेश करने की आवश्यकता होगी कि प्रॉक्सी केवल उत्पन्न हो सकता है एक सीए पर नियंत्रण ब्राउज़र ट्रस्ट। – Pieter
मैं बयान से सहमत नहीं है के बारे में [...] HTTP संदर्भदाता रिसाव (लक्ष्य पेज में एक बाहरी छवि पासवर्ड लीक हो सकता है) Slough's response में।
HTTP 1.1 RFC explicitly states:
ग्राहक एक (गैर-सुरक्षित) HTTP अनुरोध में एक Referer हेडर फ़ील्ड शामिल नहीं होना चाहिए अगर जिक्र पेज सुरक्षित प्रोटोकॉल के साथ स्थानांतरित किया गया था।
वैसे भी, सर्वर लॉग और ब्राउज़र इतिहास क्वेरी स्ट्रिंग में संवेदनशील डेटा न रखने के पर्याप्त कारणों से अधिक हैं।
का उपयोग करने के लिए किया जाता है, तो उस शब्द को फिर से 'चाहिए'। क्या आप अपने पासवर्ड के साथ हर ब्राउज़र के हर संस्करण पर भरोसा करेंगे? – JoeBloggs
यह जीईटी बनाम पोस्ट से कैसे संबंधित है? यदि आप HTTPS पर POST का उपयोग कर रहे हैं तो "हर ब्राउज़र का हर संस्करण" सुरक्षित होगा? – Arnout
इसके अलावा, HTTPS वेब पेज HTTPS * पर बाहरी छवि * को पुनः प्राप्त कर सकता है - इस मामले में, ब्राउज़र में रेफरर हेडर शामिल होना चाहिए, और इस प्रकार अपना पासवर्ड बेनकाब करें ... – AviD
हां, जब तक कोई भी मॉनिटर पर आपके कंधे पर नहीं देख रहा है।
और आपका ब्राउज़र इतिहास को सहेज नहीं रहा है :) –
आप कुछ नमक के साथ एमडी 5 हैश परम के रूप में पासवर्ड भेज सकते हैं। ऑथ के लिए सर्वर पक्ष पर इसकी तुलना करें।
MD5 पासवर्ड के लिए उपयुक्त हैश फ़ंक्शन नहीं है। – slawek
लेकिन यह एक अच्छा विचार की तरह लगता है। –
चाहे धोया गया हो या क्लीयरक्स्ट में, जीईटी पैरामीटर के भीतर पासवर्ड भेजने का बुरा अभ्यास है। स्पष्टीकरण के लिए शीर्ष मतदान वाले उत्तर का संदर्भ लें। आआंद ... एमडी 5 अब कहीं भी इस्तेमाल नहीं किया जाना चाहिए ... – Thomas
हाँ, आपकी क्वेरी स्ट्रिंग एन्क्रिप्ट की जाएगी।
कारण के पीछे है कि क्वेरी स्ट्रिंग, HTTP प्रोटोकॉल है जो एक आवेदन परत प्रोटोकॉल है का हिस्सा हैं, जबकि सुरक्षा (SSL/TLS) हिस्सा परिवहन परत से आता है। SSL कनेक्शन पहले स्थापित किया गया है और फिर क्वेरी पैरामीटर (जो http प्रोटोकॉल से संबंधित है) सर्वर पर भेजा गया है।
SSL कनेक्शन स्थापित करते समय, आपका ग्राहक निम्न चरणों को क्रम में कॉल करेगा। मान लें कि आप नाम नामक साइट पर लॉगिन करने का प्रयास कर रहे हैं और क्वेरी पैराम्स का उपयोग करके अपने प्रमाण पत्र भेजना चाहते हैं। आपका पूरा URL निम्न जैसा दिख सकता है।
(e.g http://example.com/login?username=alice&password=12345)
DNS अनुरोध का उपयोग कर एक IP पता (124.21.12.31) में अपना डोमेन नाम (example.com) का समाधान हो जाएगा। उस जानकारी से पूछताछ करते समय, केवल डोमेन विशिष्ट जानकारी का उपयोग किया जाता है। यानी: केवल example.com का उपयोग किया जाएगा।IP पता 124.21.12.31 साथ सर्वर से कनेक्ट करने की कोशिश करेंगे और बंदरगाह 443 (SSL सेवा बंदरगाह नहीं डिफ़ॉल्ट http बंदरगाह 80) से कनेक्ट करने का प्रयास करेंगे।example.com पर सर्वर आपके क्लाइंट को प्रमाणपत्र भेज देगा।इसलिए, आप संवेदनशील डेटा का पर्दाफाश नहीं करेंगे। हालांकि, इस विधि का उपयोग कर एक https सत्र में अपने प्रमाण पत्र भेजना सबसे अच्छा तरीका नहीं है। आपको एक अलग दृष्टिकोण के लिए जाना चाहिए।
लेकिन उत्तर @dr द्वारा जवाब देखें। बुराई, खदान स्ट्रिंग लॉग फ़ाइलों और कैश में समाप्त हो सकती है, इसलिए यह सर्वर पर सुरक्षित नहीं हो सकता है। – zaph
हाय ज़ाफ, HTTPS सुरक्षा के संदर्भ में, उद्देश्य डेटा को आसानी से डेटा भेजने के लिए सर्वर में सुरक्षित रूप से डेटा भेजने के लिए है। हालांकि यह संभव है, और सवाल का जवाब देते हैं, सर्वर को बाद में क्या करना है इसे नियंत्रित करना वास्तव में मुश्किल है। यही कारण है कि मैंने यह भी उल्लेख किया है कि यह सही तरीका नहीं है। उसमें जोड़ना, आपको क्लाइंट से अपना पासवर्ड कभी नहीं भेजना चाहिए। आपको हमेशा डिवाइस पर हैश करना चाहिए और सर्वर पर हैश मान भेजना चाहिए। –
खदान स्ट्रिंग में गोपनीय जानकारी भेजने वाले सुरक्षा दृष्टिकोण से सुरक्षित नहीं है, इसे पोस्ट में भेजना सबसे अच्छा है।इसके अलावा पासवर्ड आमतौर पर सर्वर पर धोया जाता है, क्लाइंट द्वारा नहीं। कथन "आपको क्लाइंट से अपना पासवर्ड कभी नहीं भेजना चाहिए" उत्तर के साथ संघर्ष में है: '(उदा। Http://example.com/login?username=alice&password=12345) '। – zaph
* https से https * रेफरर्स के बारे में क्या? अगर मुझे https का उपयोग कर किसी तृतीय पक्ष साइट से कोई छवि मिल रही है? क्या ब्राउजर पूरे प्रश्न स्ट्रिंग को मेरे पिछले अनुरोध से तृतीय पक्ष सर्वर पर भेज देगा? – Jus12
@ जुस 12 हां यह होगा, यह समझ में नहीं आता है लेकिन इस तरह यह डिजाइन किया गया है। –
फिर क्यों OAuth2 विनिर्देश क्वेरी पैरामीटर (यूआरएल में) में संवेदनशील डेटा भेजने की सिफारिश नहीं है? भले ही यह हमेशा टीएलएस (एचटीटीपीएस) का उपयोग करने की सिफारिश करता है। Http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3 सीसी @ वोल्का – gihanchanuka