टोकन पैरामीटर के साथ https URL: यह कितना सुरक्षित है?

Question

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

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

इसलिए हम URL में एक टोकन (जैसे अक्षरों और अंकों का 40 वर्णों का संयोजन, या MD5 हैश) पास करने और SSL का उपयोग करने का इरादा कर रहे हैं।

अंत में, उन्हें एक ईमेल प्राप्त होगा:

नमस्ते, https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn
पर अपने परिणाम वापस प्राप्त करें

आपने इस बारे में क्या सोचा? क्या यह काफी सुरक्षित है? आप टोकन पीढ़ी के लिए मुझे क्या सलाह देंगे? एक https अनुरोध में URL मापदंडों को पारित करने के बारे में क्या?

Comments

Securityweek.com/hackers-can-intercept-https-urls-proxy-attacks

— टॉम

Answer 1

एसएसएल पारगमन में क्वेरी मापदंडों की रक्षा करेगा; हालाँकि, ईमेल स्वयं सुरक्षित नहीं है, और ईमेल अपने गंतव्य पर पहुंचने से पहले किसी भी संख्या में सर्वर के साथ उछल सकता है।

इसके अलावा आपके वेब सर्वर के आधार पर पूरा URL इसकी लॉग फ़ाइलों में लॉग इन हो सकता है। इस बात पर निर्भर करता है कि डेटा कितना संवेदनशील है, आप नहीं चाहते कि आपके आईटी के लोग सभी टोकन तक पहुंच सकें।

इसके अतिरिक्त क्वेरी स्ट्रिंग वाला URL आपके उपयोगकर्ता के इतिहास में सहेजा जाएगा, जिससे एक ही मशीन के अन्य उपयोगकर्ता URL तक पहुँच सकते हैं।

अंत में और जो इसे बहुत असुरक्षित बनाता है, वह URL किसी भी संसाधन, यहां तक ​​कि तीसरे पक्ष के संसाधनों के लिए सभी अनुरोधों के रेफर शीर्षलेख में भेजा जाता है। इसलिए यदि आप उदाहरण के लिए Google Analytics का उपयोग कर रहे हैं, तो आप Google को URL टोकन और उन सभी को भेज देंगे।

मेरी राय में यह एक बुरा विचार है।

Comments

मैंने HTTP- रेफर समस्या के बारे में नहीं सोचा था, लेकिन url लिंक परिणाम पृष्ठ पर पुनर्निर्देशित कर देगा, यह एक उचित पृष्ठ (कोई Google विश्लेषिकी या अन्य तृतीय पक्ष स्क्रिप्ट नहीं) होगा।

— फ्लाकौ

एचटीटीपीएस से एचटीटीपी तक जाते समय अधिकांश ब्राउज़र रेफ़रर को नहीं हटाते हैं?

— केविन मार्क

यह उपयोगकर्ता सक्रियण (या पासवर्ड रीसेट) लिंक के समान है? फिर उस मामले को कैसे संभाला जाना चाहिए? बहुत सारी वेबसाइटें ईमेल पर रीसेट यूआरएल भेजती हैं, POST एक विकल्प नहीं है क्योंकि यह क्लिक करने योग्य होना चाहिए। धन्यवाद।

— गुलाबीपारा

तो समाधान क्या है?

— आरटी

क्या होगा यदि url में टोकन एपीआई अनुरोधों के लिए उपयोग किए जाने वाले टोकन के समान नहीं है और यह केवल एक घंटे तक रहता है, तो नुकसान क्या होगा?

— user1709076

Answer 2

मैं उसके लिए एक कुकी का उपयोग करूँगा। वर्कफ़्लो इस तरह होना चाहिए:

1. उपयोगकर्ता पहली बार आपकी साइट पर आता है।
2. साइट एक कुकी सेट करती है
3. उपयोगकर्ता डेटा दर्ज करता है। कुकी में संग्रहीत कुछ कुंजी का उपयोग करके डेटा को DB में संग्रहीत किया जाता है।
4. जब उपयोगकर्ता निकल जाता है, तो आप उन्हें https: लिंक के साथ एक ईमेल भेजते हैं
5. जब उपयोगकर्ता वापस आता है, तो साइट कुकी को हटा देती है और उपयोगकर्ता को पुराने डेटा के साथ प्रस्तुत कर सकती है।

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

Answer 3

SSL पारगमन में डेटा की सामग्री को सुरक्षित करता है, लेकिन मुझे URL के बारे में निश्चित नहीं है।

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

यदि उपयोगकर्ता के ईमेल से छेड़छाड़ की जाती है और किसी हमलावर को पहले लिंक मिलता है, तो ठीक है, आप ठीक हो गए हैं। लेकिन उपयोगकर्ता को भी बड़ी समस्याएं हैं।

Comments

URL प्रसारित होने से पहले SSL कनेक्शन सुरक्षित हो जाता है।

— डेविड

Answer 4

ई-मेल स्वाभाविक रूप से असुरक्षित है। यदि कोई भी उस लिंक पर क्लिक कर सकता है और डेटा प्राप्त कर सकता है, तो आप वास्तव में उसकी रक्षा नहीं कर रहे हैं।

Comments

सटीक लेकिन कई साइटें इसके बारे में परेशान नहीं करती हैं और मेल द्वारा लॉगिन / पासवर्ड भेजती हैं। लेकिन यह उनकी नकल करने का कारण नहीं है ...

— फ्लैकौ

मैं उनकी नकल करने के लिए बिना किसी कारण के सहमत हूं, लेकिन वे आपको पहली बार लॉगिन करने के बाद पासवर्ड बदलने के लिए कहते हैं।

— जेसन Punyon

Answer 5

एसएसएल के माध्यम से पारित होने पर अच्छी तरह से टोकन सुरक्षित है। आपके पास जो समस्या होने वाली है वह यह है कि यह URL देखने में सक्षम लोगों (जिनके लिए इसका कोई इरादा नहीं है) के लिए उपयुक्त है।

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

Comments

आप सही हैं: URL उदाहरण के लिए ब्राउज़र इतिहास में बना रहेगा

— Flackou

Answer 6

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

संयोगवश, https अनुरोध में मापदंडों के साथ कोई समस्या नहीं है।

Comments

आप ब्रूट बल के हमलों के जोखिम के बारे में सही हैं। मैं यह नहीं देखता कि हम इस प्रकार के हमले से बॉट को कैसे रोक सकते हैं। प्रतिबंध "जोर" आईपी एक पर्याप्त सुरक्षा नहीं होगी। क्या आपके पास इस विषय पर विचार होंगे?

— फ्लैकॉ

दरअसल, जिस तरह की प्रमुख जगह के बारे में हम बात कर रहे हैं, अगर (यह_प_नंबर_हेस_श्रेष्ठ_न_नवलिद_तोकेन_तोदे ()) नींद (5); आपके load_simulation स्क्रिप्ट में पूरी तरह से पर्याप्त सुरक्षा होगी। (रेट लिमिटिंग अच्छे प्रमाणीकरण तंत्र की उन विशेषताओं में से एक है।)

— अराजकता

आपके उत्तर के लिए धन्यवाद। लेकिन मैंने सोचा कि एक ही बॉट आसानी से अलग-अलग आईपी ले सकता है जिसने आईपी दर की सीमा को पर्याप्त नहीं बनाया है। क्या मै गलत हु?

— फ्लैकोउ

उन्हें जो कुछ भी मिलता है, वह प्रति आईपी के लिए एक अवांछित प्रयास है। IP पता स्थान इतनी आसानी से उपलब्ध नहीं है कि सहायक हो।

— अराजकता

Answer 7

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

जानकारी तक पहुंचने के लिए सबसे अच्छा उपयोगकर्ता नाम और पासवर्ड प्रमाणीकरण होगा।

मुझे कुकी विचार कमोबेश पसंद है। आपको कुकी जानकारी को भी एन्क्रिप्ट करना चाहिए। आपको हमले की संभावना को सीमित करने के लिए नमक और कुंजी वाक्यांश के साथ $ _SERVER ['HTTP_USER_AGENT'] टोकन भी उत्पन्न करना चाहिए। सत्यापन उपयोग के लिए कुकी में क्लाइंट के बारे में अधिक निरर्थक जानकारी संग्रहीत करें।

कुंजी वाक्यांश को आसान उपयोग के लिए कुकी में संग्रहीत किया जा सकता है लेकिन ध्यान रखें कि कुकी चोरी भी हो सकती है = (।

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

या, कुंजी का उपयोग उस मामले में किया जा सकता है जब व्यक्ति एक अलग मशीन का उपयोग करता है जो $ _SERVER ['HTTP_USER_AGENT'] मापदंडों में भिन्न होता है या बस कुकी को याद करता है। तो कुकी को स्थानांतरित या सेट किया जा सकता है।

यह भी सुनिश्चित करें कि डेटाबेस में संवेदनशील डेटा एन्क्रिप्ट किया गया है। आपको कभी नहीं जानते ;)

Answer 8

आप इस बात से अवगत हैं कि यदि किसी भी हैकर को आपके डेटाबेस तक पहुँचने के लिए बहुत सारी जानकारी प्राप्त हो सकती है?

उसके बाद मैं कहूंगा कि यह विचार के रूप में बुरा नहीं है। मैं MD5 या SHA1 का उपयोग नहीं करूंगा क्योंकि वे हैशिंग के लिए बहुत सुरक्षित नहीं हैं। वे "डिक्रिप्टेड" हो सकते हैं (मुझे पता है कि यह एन्क्रिप्शन नहीं है) काफी आसानी से।

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

ध्यान दें कि HTTPS आपकी साइट से अंतिम उपयोगकर्ता के लिए भेजे गए डेटा को सुरक्षित और क्रिप्ट करेगा। और कुछ नहीं, इसे एक सुरक्षित सुरंग के रूप में लें। ज्यादा कुछ नहीं कम।

Comments

शब्द के किसी भी अर्थ में एक नमकीन SHA1 हैश को वास्तव में कैसे डिक्रिप्ट किया जाता है?

— एली

"आप इस बात से अवगत हैं कि यदि किसी हैकर को आपके डेटाबेस तक पहुँच प्राप्त हो जाए तो बहुत सारी व्यक्तिगत जानकारी स्वतंत्र रूप से दी जा सकती है?" हाँ, लेकिन यह सभी वेबसाइटों के लिए एक समस्या नहीं है ??

— फ्लैकोउ

@Flackou हां, लेकिन अगर आप पेपैल के डीबी तक पहुंच प्राप्त करते हैं, तो आपको स्पष्ट रूप से सहेजे गए क्रेडिट कार्ड का पता नहीं चलेगा, सब कुछ एन्क्रिप्ट किया गया है। @ एली: theregister.co.uk/2005/02/17/sha1_hashing_broken

— एरिक

Answer 9

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

एक बेहतर समाधान उपयोगकर्ता को टोकन भेजने के लिए हो सकता है, फिर उन्हें कुछ विवरण, जैसे कि उनका नाम, पोस्ट कोड, एसएसएन या इनमें से एक संयोजन दर्ज करने के लिए कहें।

Comments

एसएसएन? क्या आप गंभीर हैं? वैसे भी, मेरा सुझाव है कि आप गणित कर सकते हैं कि कितने 40 वर्ण यादृच्छिक तार हैं। यह सिर्फ "अत्यधिक संभावना नहीं" से अधिक है

— एली

आप सही हैं, हमें संभवतः ईमेल में एक और पैरामीटर जोड़ना चाहिए, जैसे ईमेल (भले ही a..z + A..Z + 0..9 = 62 अक्षर, और 62 ^ 40 एक बहुत बड़ी संख्या हो)।

— फ्लैकॉ

दोस्तों, 62 ^ 40 ब्रह्मांड में परमाणुओं की संख्या से काफी अधिक है। यह वस्तुतः अभेद्य है।

— एली

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

— एली

रिचर्ड, ऐसा लगता है कि आप यह इंगित कर रहे हैं कि आमतौर पर जन्मदिन का विरोधाभास क्या कहा जाता है ... यह केवल संभावित संयोजनों की संख्या नहीं है जो मायने रखती है, लेकिन उनमें से कितने का उपयोग किया जाता है। खैर, इस मामले में, आपको मौका महत्वपूर्ण होने से पहले 62 ^ 40 संयोजनों में से लगभग 2 ^ 119 का उपयोग करने की आवश्यकता है।

— इरिकसन