Outlook SafeLinks, Proofpoint URLDefense, Google रीडायरेक्ट लिंक और अन्य रैप की गई URL को मूल गंतव्य तक वापस डिकोड करें ताकि आप देख सकें कि कोई लिंक वास्तव में कहाँ जाता है।
Outlook SafeLinks, Proofpoint URLDefense और अन्य पुनर्लिखित URL खोलें। कॉर्पोरेट मेल गेटवे ईमेल में हर लिंक को फिर से लिखते हैं ताकि क्लिक सबसे पहले उनके स्कैनर से होकर गुजरे। इसे खोलने से पहले वास्तविक गंतव्य पाने के लिए यहाँ पुनर्लिखित लिंक पेस्ट करें।
पूरा लिंक पेस्ट करें, क्वेरी स्ट्रिंग सहित। आपके ब्राउज़र से कुछ नहीं निकलता।
आपके लिंक क्यों फिर से लिखे जाते हैं, और उन्हें कैसे पढ़ें
लिंक रैपर क्या करता है
जब कोई संगठन Microsoft Defender for Office 365, Proofpoint, Mimecast या किसी समान गेटवे को चलाता है, तो इनबाउंड ईमेल के भीतर हर URL को मेलबॉक्स तक पहुँचने से पहले फिर से लिखा जाता है। example.com/report कुछ ऐसा बन जाता है eur01.safelinks.protection.outlook.com/?url=htt...।
मकसद क्लिक-के-समय की सुरक्षा है। एक लिंक संदेश के स्कैन होने पर हानिरहित हो सकता है और एक घंटे बाद हथियार बनाया जा सकता है, इसलिए गेटवे हर क्लिक को अपने स्कैनर से होकर गुजरने के लिए मजबूर करता है और उस क्षण गंतव्य की प्रतिष्ठा फिर से जाँचता है।
रैप करने की कीमत
रैपिंग पुस्तक की सबसे पुरानी सुरक्षा सलाह को तोड़ती है: किसी लिंक पर होवर करें और देखें कि वह कहाँ जाता है। स्टेटस बार अब गंतव्य के बजाय गेटवे का डोमेन दिखाता है। यह लिंक प्रीव्यू को भी तोड़ता है, डॉक्यूमेंटेशन में URL को अनुपयोगी बनाता है, टर्मिनल में कॉपी-पेस्ट को विफल करता है, और गेटवे ऑपरेटर को क्लिक टेलीमेट्री लीक करता है।
डिकोडिंग मूल URL को बहाल करती है ताकि आप स्वयं उसका निर्णय कर सकें।
प्रारूप
Outlook SafeLinks गंतव्य को url क्वेरी पैरामीटर में रखता है, एक बार प्रतिशत-एन्कोडेड। इसके बाद वाला सब (data, sdata, reserved) ट्रैकिंग मेटाडेटा है जिसे त्यागा जा सकता है।
Proofpoint URLDefense की तीन पीढ़ियाँ हैं। v1 और v2 एक u पैरामीटर का उपयोग करते हैं जिसमें एक कस्टम प्रतिस्थापन होती है: - का अर्थ % और _ का अर्थ /। v3 एक पथ-आधारित __example.com__;!!... रूप का उपयोग करता है। यह उपकरण प्रतिशत-डिकोडिंग से पहले प्रतिस्थापन को उल्टा करता है।
Google/url?q= (खोज परिणाम) या /url?url= (अन्य उत्पाद) का उपयोग करता है, और Facebook, LinkedIn और Twitter के अपने-अपने समकक्ष हैं।
सामान्य रैपर गंतव्य को url, u, target, redirect, dest या link नाम के पैरामीटर में रखते हैं। जब डिकोडर किसी ज्ञात वेंडर की पहचान नहीं कर पाता, तो यह इनमें से किसी भी के लिए स्कैन करता है।
डिकोड किए गए लिंक को सुरक्षित रूप से पढ़ना
URL वापस पाना काम का केवल आधा हिस्सा है। पूरे स्ट्रिंग को नहीं, बल्कि पंजीकरण योग्य डोमेन (registrable domain) को देखें—paypal.com.secure-login.ru का स्वामित्व secure-login.ru के पास है। लुक-अलाइक अक्षरों, अप्रत्याशित टॉप-लेवल डोमेन, या किसी वैध होस्ट के अजीब पथ जैसे /wp-content/uploads/ से सावधान रहें। और याद रखें: एक डिकोड किया गया लिंक जो ठीक लगे, इसका प्रमाण नहीं है कि उसके पीछे की फाइल सुरक्षित है।
अक्सर पूछे जाने वाले प्रश्न
क्या यहाँ संदिग्ध लिंक डिकोड करना सुरक्षित है?
हाँ। डिकोडिंग आपके ब्राउज़र के भीतर शुद्ध स्ट्रिंग मैनिपुलेशन है—लिंक पर कोई अनुरोध नहीं किया जाता और सर्वर पर कुछ नहीं भेजा जाता। आप URL को पढ़ रहे हैं, उसे नहीं खोल रहे।
डिकोड किया गया लिंक अजीब पैरामीटर क्यों अभी भी रखता है?
utm_source, gclid या fbclid जैसे मार्केटिंग पैरामीटर मूल URL के हिस्से हैं और अनरैप होने पर बचे रहते हैं। यदि आप एक साफ लिंक चाहते हैं तो उन्हें मैन्युअल रूप से हटाना सुरक्षित है।
यह 'रैप नहीं किया गया' कहता है लेकिन लिंक ईमेल से आया था।
हर गेटवे हर लिंक को रैप नहीं करता। आंतरिक प्रेषक, अनुमति-सूची डोमेन और प्लेन-टेक्स्ट संदेश अक्सर अछूते छोड़ दिए जाते हैं, इसलिए अनरैप करने के लिए बस कुछ नहीं होता।
क्या मैं SafeLinks बंद कर सकता हूँ?
केवल एक टेनेंट एडमिनिस्ट्रेटर ही Defender for Office 365 नीतियों के माध्यम से ऐसा कर सकता है, और इसे अक्षम करने से सभी के लिए क्लिक-के-समय सुरक्षा समाप्त हो जाती है। व्यक्तिगत लिंक को डिकोड करना अधिक सुरक्षित आदत है।
नेस्टेड रैपर का क्या?
संगठनों के बीच फॉरवर्ड किए गए लिंक दो बार रैप किए जा सकते हैं। परिणाम को फिर से डिकोड करें और दूसरी परत भी उतर जाती है।