डोमेन से पहले URL में @ (प्रतीक में) का उद्देश्य क्या है?
मैं हाल ही में नए फ़िशिंग हमले में आया हूं जो @URL को वैध बनाने के लिए प्रतीक का उपयोग कर रहा है । यह इस प्रकार चलता है:
मेरे पास एक खाता है totally-legit-site.comऔर हमलावर अपने आईपी पर एक फ़िशिंग साइट सेट करता है 192.168.50.20। फिर, वह मुझे साइट पर एक संदेश भेजता है, जिसमें लिंक दिखता है http://[email protected]/account। इसका उपयोग उपयोगकर्ता को यह सोचने के लिए किया जाता है कि यह कानूनी साइट का लिंक है।
हालाँकि, इस लिंक पर क्लिक करने 192.168.50.20/accountसे मेरे ब्राउज़र (Google Chrome) में पेज खुल जाता है। मैंने @यादृच्छिक डोमेन से पहले यादृच्छिक सामान जोड़ने की कोशिश की और मेरा ब्राउज़र हमेशा पृष्ठ को सही ढंग से हल करता है, उस सामान को @दूर फेंक देता है। इसलिए यदि मैं खोलने की कोशिश करता http://[email protected]हूं, तो मैं Google के होमपेज पर समाप्त होता हूं।
यह वास्तव में मुझे दिलचस्पी है। मैं @डोमेन से पहले URL के बारे में कोई जानकारी नहीं पा रहा था । इसे कैसे कहा जाता है? क्या यह इंटरनेट के शुरुआती चरणों से कुछ अप्रचलित सामान है? क्या ऐसे कुछ वेबसर्वर हैं जो URL के इस हिस्से को संसाधित कर सकते हैं (इस पैरामीटर के आधार पर विभिन्न साइटों को वापस करने के लिए मेरे nginx उदाहरण को संशोधित करने में सक्षम होने के नाते) अच्छा होगा?
जवाब
इस सिंटैक्स का उपयोग प्रोटोकॉल-स्तर प्रमाणीकरण विवरण (उपयोगकर्ता नाम, कभी-कभी पासवर्ड) निर्दिष्ट करने के लिए 'प्राधिकरण' से कनेक्ट करने के लिए किया जाता है। उदाहरण के लिए देखें RFC 3986 खंड 3.2.1 ।
HTTP के साथ उपयोग किए जाने पर, क्रेडेंशियल HTTP प्राधिकरण में भेजे जाते हैं : हेडर ; प्रारूप सर्वर द्वारा अनुरोधित प्रमाणीकरण तंत्र पर निर्भर करता है, लेकिन सबसे अधिक Basicप्रमाणीकरण का उपयोग बिना किसी अतिरिक्त प्रसंस्करण के किया जाता है। RFC 7617 या MDN देखें ।
कई webservers एक 'htpasswd' फ़ाइल, LDAP, SQL या अन्य डेटाबेस के खिलाफ क्रेडेंशियल्स को सत्यापित कर सकते हैं - उदाहरण के लिए Nginx को देखेंभी_बासिक या Apache httpd AuthType Basic ।
वैकल्पिक रूप से, सत्यापन स्वयं वेबऐप द्वारा किया जा सकता है क्योंकि यह मानक HTTP हेडर और स्टेटस कोड के माध्यम से किया जाता है। उदाहरण के लिए देखें PHP (लेकिन अपाचे में यह काम करने के लिए आपको CGIPassAuthएक अजीब रीराइट ट्रिक को सक्षम या उपयोग करने की आवश्यकता हो सकती है , अन्यथा यह एप्लिकेशन रनटाइम के लिए प्राधिकरण हेडर को अग्रेषित नहीं करेगा।)
अंतर्निहित HTTP प्रमाणीकरण आमतौर पर एपीआई और अन्य स्वचालित अनुरोधों के लिए उपयोग किया जाता है, क्योंकि इसमें उपयोगकर्ता के इंटरैक्शन की आवश्यकता नहीं होती है, इसके लिए कुकीज़ या अन्य राज्य को संग्रहीत करने की आवश्यकता नहीं होती है, और आपको "लॉगिन" POST अनुरोध को प्रारूपित करने के लिए जानने की आवश्यकता नहीं है (जो आप '<form> -based schem) की आवश्यकता है।
यह भी बिल्कुल वैसा ही प्रमाणीकरण तरीका है जैसा कि इन संकेतों द्वारा उपयोग किया जाता है:
एफ़टीपी और कई अन्य प्रोटोकॉल पर भी यही सिंटैक्स लागू होता है, जो URL का उपयोग करते हैं और प्रमाणीकरण का समर्थन करते हैं - सभी मामलों में, उस प्रोटोकॉल का अंतर्निहित तंत्र उपयोग किया जाता है।
यहाँ हमला काम करता है क्योंकि HTTP प्रमाणीकरण वैकल्पिक है और ज्यादातर मामलों में अतिरिक्त HTTP हेडर को केवल वेबसर्वर और वेबैप द्वारा अनदेखा किया जाता है। और इसके विपरीत, ब्राउज़र यह नहीं जानते कि अनुरोध भेजे जाने के बाद तक सर्वर प्रमाणीकरण के लिए पूछेगा या नहीं ।
हालांकि, हमले नया नहीं है सब पर है - यह कम से कम 2000 के दशक के बाद से कम से चारों ओर हो गया है। (वास्तव में, कुछ बिंदु पर ब्राउज़रों ने जाँच शुरू कर दी, पहली बार बिना किसी अनुरोध के यह देखने के लिए कि सर्वर 401 के साथ उत्तर देगा या नहीं। यदि सर्वर प्रमाणीकरण का अनुरोध नहीं करता है, तो क्रोम बनाने के लिए पता बार से उपयोगकर्ता नाम छिपाएगा। वास्तविक डोमेन अधिक स्पष्ट है, और फ़ायरफ़ॉक्स वास्तव में चेतावनी देगा कि "यह आपको छल करने का प्रयास हो सकता है।"