लिंक स्कैनर और वन-टाइम सीक्रेट

जो वन-टाइम लिंक सादे GET पर मिट जाता है, वह उसी पल खत्म हो जाता है जब Slack, Teams या कोई ईमेल गेटवे प्रीव्यू के लिए उसे फ़ेच करता है। इसका हल यह है कि GET पर सिर्फ़ मेटाडेटा लौटाया जाए और सीक्रेट तभी मिटे जब कोई साफ़ तौर पर POST से उसे खोले, और आखिरी सुरक्षा के तौर पर पासफ़्रेज़ किसी दूसरे माध्यम से भेजा जाए। यह पोस्ट बताती है कि कौन-से सिस्टम बिना पूछे लिंक फ़ेच करते हैं और इन सबसे बचने वाला डिज़ाइन कैसे बनाएं।

LinkPilot का वन-टाइम सीक्रेट लिंक जनरेटर इसी तरह बना है: प्रीव्यू के लिए किए गए फ़ेच को सिर्फ़ पेज का ढांचा मिलता है। सीक्रेट तभी फ़ेच होता है और खुलना तभी गिना जाता है, जब कोई ब्राउज़र पेज को चलाता है।

आम तौर पर गड़बड़ी कैसे होती है

ज़्यादातर चैट और ईमेल ऐप URL देखते ही उसका प्रीव्यू बनाने की कोशिश करते हैं। यह कुछ ऐसे होता है:

1. यूज़र सीक्रेट लिंक को Slack में पेस्ट करता है।
2. Slack का लिंक प्रीव्यू बॉट URL फ़ेच करता है (GET भेजता है; Slack ने यह व्यवहार link unfurling के तहत दर्ज किया है)।
3. सीक्रेट दिखाने वाला आपका हैंडलर इस रिक्वेस्ट को किसी इंसान का खोलना मान लेता है, सीक्रेट मिटा देता है और उसका कंटेंट लौटा देता है।
4. Slack को मिटाया जा चुका कंटेंट (या कोई सामान्य पेज) मिलता है और वह उसका प्रीव्यू दिखा देता है।
5. इंसान लिंक पर क्लिक करता है, उसे “पहले ही देखा जा चुका है” दिखता है, और वह भेजने वाले से नया लिंक मांगता है।

लिंक प्रीव्यू बॉट की कोई बुरी नीयत नहीं थी। आपके हैंडलर ने “किसी ने URL फ़ेच किया” और “प्राप्तकर्ता ने सीक्रेट पढ़ा” को एक ही बात मान लिया। ये दो अलग घटनाएं हैं, और डिज़ाइन की पूरी चुनौती इन्हें अलग रखना है।

तीसरे स्टेप में इससे भी बुरी स्थिति छिपी है: अगर बॉट के GET को असली कंटेंट मिल गया, तो सीक्रेट अब किसी तीसरी कंपनी के प्रीव्यू बनाने वाले सिस्टम में पड़ा है। सबसे अच्छी स्थिति में प्रीव्यू बनने के बाद उसे हटा दिया गया होगा, लेकिन इसकी पुष्टि करने का आपके पास कोई तरीका नहीं है, और ऐसा कोई ऑडिट इवेंट भी नहीं जो बताए कि ऐसा हुआ।

प्राप्तकर्ता के खोलने से पहले लिंक कौन फ़ेच करता है?

चैट ऐप के लिंक प्रीव्यू बॉट, ईमेल सिक्योरिटी गेटवे, एंडपॉइंट प्रोटेक्शन, कंपनी के प्रॉक्सी और प्रीव्यू वाले एक्सटेंशन, और आम तौर पर इनमें से एक से ज़्यादा। “Slack प्रीव्यू बनाता है” कहना समस्या को छोटा करके दिखाता है। किसी आधुनिक दफ़्तर में पेस्ट किया गया URL आम तौर पर किसी इंसान के क्लिक करने से पहले कई सिस्टम फ़ेच कर चुके होते हैं:

इस टेबल में बताया गया कंपनियों का व्यवहार बदलता रहता है। किसी गेटवे के बारे में खास दावों को “जुलाई 2026 में प्रकाशित जानकारी के मुताबिक, मौजूदा दस्तावेज़ों से मिलान करें” मानें। लेकिन एक बात नहीं बदलती: ये सभी सिस्टम सादा GET भेजते हैं, क्योंकि जिस URL पर आपका नियंत्रण नहीं है, उसे देखने का यही एक सुरक्षित और हर जगह चलने वाला तरीका है।

प्रीव्यू को वन-टाइम लिंक मिटाने से कैसे रोकें?

GET पर मेटाडेटा दें और सीक्रेट सिर्फ़ साफ़ POST पर मिटाएं। HTTP के नियमों में यह पहले से मौजूद है: RFC 9110, सेक्शन 9.2.1 GET को सुरक्षित और आइडेम्पोटेंट बताता है, यानी ऐसी रिक्वेस्ट जिसे कोई भी बेझिझक भेज सकता है, क्योंकि उससे कुछ बदलना नहीं चाहिए। POST कार्रवाई वाला तरीका है। इसलिए सीक्रेट दिखाने को एक दिखने वाले बटन के पीछे POST कार्रवाई की तरह रखें:

GET  /s/abc123   →  HTML page: "Click to reveal this secret"
POST /s/abc123   →  burns the secret, returns the payload

अब Slack के GET को एक सामान्य मेटाडेटा पेज मिलता है। सीक्रेट तभी मिटता है जब इंसान बटन पर क्लिक करता है। जो भी स्कैनर HTTP के नियम मानता है, वह कंटेंट को कभी छूता ही नहीं। लगभग सभी स्कैनर ये नियम मानते हैं, क्योंकि किसी भी URL पर असर डालने वाले POST भेजने से आधा वेब टूट जाएगा।

एक लिंक का पूरा सफ़र

एक लिंक को शुरू से आखिर तक देखें। आप पढ़ने के बाद मिटाएं और पासफ़्रेज़ के साथ एक सीक्रेट बनाते हैं, फिर URL को Slack DM और एक ईमेल में पेस्ट करते हैं।

1. Slack का लिंक प्रीव्यू बॉट GET /s/abc123 भेजता है। जवाब: एक छोटा मेटाडेटा पेज, जिसमें स्टेटस “active” (सक्रिय) है और पासफ़्रेज़ ज़रूरी है। कोई खुलना दर्ज नहीं होता। सीक्रेट बचा रहता है।
2. प्राप्तकर्ता का ईमेल गेटवे ईमेल में URL बदल देता है और साख की जांच के लिए ईमेल पहुंचते समय उसे फ़ेच करता है। वही GET, वही मेटाडेटा। सीक्रेट अब भी बचा है।
3. प्राप्तकर्ता ईमेल वाले लिंक पर क्लिक करता है। गेटवे का क्लिक के समय वाला स्कैनर उसे एक बार और फ़ेच करता है (GET), फिर ब्राउज़र को आगे भेज देता है।
4. ब्राउज़र सीक्रेट दिखाने वाला पेज लोड करता है, यह भी एक GET है। पेज पर “दिखाएं” बटन और पासफ़्रेज़ का फ़ील्ड दिखता है। अब भी कोई खुलना दर्ज नहीं हुआ।
5. प्राप्तकर्ता पासफ़्रेज़ डालकर “दिखाएं” पर क्लिक करता है। ब्राउज़र POST /s/abc123 भेजता है। खुलना दर्ज होता है, कंटेंट लौटाया जाता है और सीक्रेट मिट जाता है।
6. इसके बाद जो भी URL फ़ेच करे, उसे कंटेंट नहीं, साफ़ जवाब मिलता है कि सीक्रेट “पहले ही देखा जा चुका है और मिटा दिया गया है”।

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

सुरक्षा की कई परतें

GET / POST का बंटवारा

यह बंटवारा नियम मानने वाले हर लिंक प्रीव्यू बॉट और स्कैनर को संभाल लेता है, और अपने आप होने वाला ज़्यादातर ट्रैफ़िक इन्हीं का होता है। यही नींव है। नीचे की बाकी परतें इसके ऊपर अतिरिक्त सुरक्षा हैं।

पासफ़्रेज़ की जांच

यह जांच उन मामलों को संभालती है जिन्हें बंटवारा नहीं संभाल सकता: JavaScript चलाने और पेज के साथ इंटरैक्ट करने वाले सैंडबॉक्स, साथ ही इंसानों के गलती से किए क्लिक और फ़ॉरवर्ड किए गए ईमेल। डेटोनेशन सैंडबॉक्स “दिखाएं” बटन पर क्लिक कर सकता है, लेकिन किसी दूसरे माध्यम से भेजा गया पासफ़्रेज़ नहीं डाल सकता। लिंक ईमेल से भेजें और पासफ़्रेज़ Slack DM या SMS से।

बॉट के यूज़र एजेंट से फ़िल्टर करना

जाने-पहचाने लिंक प्रीव्यू बॉट (Slackbot, LinkedInBot, Twitterbot) को सीक्रेट दिखाने वाले किसी भी लॉजिक तक पहुंचने से पहले ही रोक दें। अतिरिक्त सावधानी के तौर पर यह करना ठीक है, लेकिन सिर्फ़ इसी पर कभी भरोसा न करें: सिक्योरिटी स्कैनर अक्सर असली ब्राउज़र वाले यूज़र एजेंट भेजते हैं, ठीक इसलिए ताकि नुकसानदेह पेज जांच से खुद को छिपा न सकें।

कम एक्सपायरी

नुकसान का समय सीमित रखें। जो लिंक पंद्रह मिनट तक ही चला, वह स्कैनर, लॉग फ़ाइलों और चैट हिस्ट्री में ऐसे URL के रूप में बचता है जो अब कहीं नहीं ले जाता।

Cache-Control: no-store

इसे सीक्रेट दिखाने वाले हर जवाब में लगाएं, ताकि एक जायज़ बार पढ़े जाने के बाद बीच का कोई भी सिस्टम (कंपनी का प्रॉक्सी, CDN, ब्राउज़र कैश) कंटेंट की कॉपी न रखे।

खास तौर पर ईमेल सिक्योरिटी गेटवे

कंपनियों के गेटवे के लिए अलग सेक्शन ज़रूरी है, क्योंकि वे दो बार फ़ेच करते हैं। इस तरह के प्रोडक्ट (Microsoft Defender Safe Links इसका उदाहरण है, जिसका व्यवहार दस्तावेज़ों में दर्ज है) आने वाली मेल के हर URL को अपने स्कैनिंग डोमेन से होकर जाने वाले URL में बदल देते हैं। URL आम तौर पर एक बार मेल पहुंचते समय साख की जांच के लिए फ़ेच होता है, और फिर क्लिक के समय, इंसान को असली जगह पर भेजने से पहले।

अगर इनमें से कोई भी फ़ेच सीक्रेट मिटा देता, तो प्राप्तकर्ता को हमेशा बेकार लिंक दिखता। यूज़र को यह गड़बड़ी बेतरतीब लगती है, लेकिन यह पूरी तरह तय तरीके से होती है। GET/POST का बंटवारा दोनों फ़ेच बिना किसी अतिरिक्त मेहनत के झेल लेता है, क्योंकि दोनों सादे GET हैं। क्लिक के समय का रीडायरेक्ट फिर इंसान को सीक्रेट दिखाने वाले पेज पर पहुंचाता है, जहां POST होता है।

वे स्थितियां जो अब भी परेशान करती हैं

• JavaScript चलाने वाले सैंडबॉक्स। कुछ डेटोनेशन एनवायरनमेंट पेज को रेंडर करते हैं और उसके साथ इंटरैक्ट करते हैं। बिना पासफ़्रेज़ के बटन के पीछे रखे POST पर, सिद्धांत रूप में, कोई आक्रामक सैंडबॉक्स क्लिक कर सकता है। पासफ़्रेज़ की जांच आखिरी सुरक्षा है।
• लिंक और पासफ़्रेज़ एक ही माध्यम से। अगर दोनों एक ही ईमेल में जाते हैं, तो ऊपर की हर सुरक्षा बस इस उम्मीद पर टिक जाती है कि उस ईमेल को कोई नहीं पढ़ेगा। माध्यम हमेशा अलग रखें।
• फ़ॉरवर्ड करना। किसी नए चैट या मेल सिस्टम में हर फ़ॉरवर्ड से प्रीव्यू का नया दौर शुरू होता है। बंटवारे के साथ इससे नुकसान नहीं होता, लेकिन हर नया पड़ाव URL रखने वाले लॉग का एक और सेट है, और यह कम एक्सपायरी के पक्ष में एक और तर्क है।
• एक साथ खोलना। अगर दो लोग एक ही समय पर “दिखाएं” पर क्लिक करें, तो सीक्रेट एक ही ऑपरेशन में मिटना चाहिए, जिसे बीच से तोड़ा नहीं जा सकता: ठीक एक रिक्वेस्ट सफल हो और दूसरी को “पहले ही देखा जा चुका है” मिले। जो इम्प्लीमेंटेशन पढ़ने और मिटाने को एक अटूट कदम में नहीं करता, वह कंटेंट दो बार दे सकता है।

अपना टूल खुद जांचें

सीक्रेट शेयर करने वाली किसी भी सेवा पर असली लॉगिन की जानकारी के लिए भरोसा करने से पहले यह दो मिनट की जांच करें:

1. “पढ़ने के बाद मिटाएं” विकल्प चालू करके एक बेकार सा टेस्ट सीक्रेट बनाएं।
2. उसे टर्मिनल से फ़ेच करें, लिंक प्रीव्यू बॉट ठीक यही करता है: curl -s -o /dev/null -w "%{http_code}" "<url>"
3. लिंक को ब्राउज़र में खोलें। अगर “पहले ही देखा जा चुका है” दिखे, तो टूल GET पर ही सीक्रेट मिटा देता है और उसका लिंक चैट या ईमेल में पेस्ट करना सुरक्षित नहीं है।
4. अगर सीक्रेट बचा रहा, तो उसे ब्राउज़र में ठीक से खोलें और फिर से curl चलाएं। अब आपको कंटेंट नहीं, साफ़ जवाब मिलना चाहिए कि सीक्रेट अब मौजूद नहीं है या मिटा दिया गया है।

LinkPilot इसे कैसे लागू करता है

LinkPilot के Secret Links ठीक यही डिज़ाइन इस्तेमाल करते हैं। सीक्रेट दिखाने वाले एंडपॉइंट पर GET सिर्फ़ मेटाडेटा लौटाता है (स्टेटस, और यह कि पासफ़्रेज़ ज़रूरी है या नहीं)। खुलना सिर्फ़ साफ़ तौर पर भेजे गए POST पर दर्ज होता है। पासफ़्रेज़ यूज़र के ब्राउज़र में ही SHA-256 से हैश होते हैं, और हर सीक्रेट के लिए हर IP से एक मिनट में पांच कोशिशों की सीमा है। सीक्रेट दिखाने वाले हर जवाब में Cache-Control: no-store होता है, मिट चुके या एक्सपायर हो चुके सीक्रेट HTTP 410 लौटाते हैं और स्टोर किए गए कंटेंट के ऊपर दूसरा डेटा लिख दिया जाता है, और ऑडिट टाइमलाइन हर इवेंट को ऐसे हैश किए गए IP के साथ दर्ज करती है जिसका सॉल्ट हर दिन बदलता है। कच्चा IP कभी स्टोर नहीं होता। पूरी जानकारी सिक्योरिटी आर्किटेक्चर पेज पर है।

इस डिज़ाइन की सीमाएं

ईमानदारी से बताएं तो: ऊपर की कोई भी बात जायज़ तरीके से खुलने के बाद सीक्रेट की रक्षा नहीं करती। प्राप्तकर्ता कंटेंट को कॉपी कर सकता है, उसका स्क्रीनशॉट ले सकता है या उसे आगे भेज सकता है। अगर पासफ़्रेज़ लिंक के साथ ही भेजा गया, तो यह मदद नहीं करता। और यह उस व्यक्ति को नहीं रोक सकता जिसे गलती से लिंक भेज दिया गया और जिसने सही प्राप्तकर्ता से पहले उसे खोल लिया। इसी के लिए ऑडिट ट्रेल है: आपको अनपेक्षित खुलना दिखता है और आप लॉगिन की जानकारी बदल देते हैं।

इन्हें भी पढ़ें

• वन-टाइम सीक्रेट लिंक कैसे काम करते हैं
• URL से संवेदनशील जानकारी क्यों लीक होती है
• LinkPilot का सिक्योरिटी आर्किटेक्चर

संदर्भ

• IETF, RFC 9110: HTTP Semantics, section 9.2.1 Safe Methods।
• Slack API, Unfurling links in messages।
• Microsoft Learn, Safe Links in Microsoft Defender for Office 365।