क्या आप निजी सुरक्षित लिंक को बस सार्वजनिक रूप से एक्सेस नहीं कर सकते, है न?
“निजी” लिंक का सुरक्षा मॉडल
- कई टिप्पणीकारों का तर्क है कि ऐसे लिंक जिनमें अनुमान न लगने वाले टोकन हों लेकिन कोई access control न हो, वे सिर्फ़ “security by obscurity” हैं। वे स्वाभाविक रूप से private नहीं होते; उन्हें केवल brute-force करना मुश्किल होता है।
- अन्य लोग ज़ोर देते हैं कि obscurity, “security with obscurity” में एक परत के रूप में स्वीकार्य हो सकती है, लेकिन यह अकेली सुरक्षा नहीं होनी चाहिए।
URLs में secrets क्यों लीक होते हैं
- URLs browser history, server access logs, reverse proxies, CDNs, firewall/IDS logs, और link scanners में log हो जाते हैं। Password fields और POST bodies अक्सर नहीं होते।
- Messaging और email platforms, security gateways, और URL-scanning सेवाएँ previews या malware checks के लिए links को अपने-आप fetch करती हैं, जिससे अनजाने में “magic links” और यहाँ तक कि downloaded files भी expose हो जाती हैं।
- E2EE-रहित channels का मतलब है कि platform सभी links देखता है; users अक्सर यह समझ नहीं पाते।
Links बनाम passwords की तुलना
- सैद्धांतिक रूप से एक लंबा random URL token password से कहीं अधिक entropy रख सकता है और व्यावहारिक रूप से brute-force करना असंभव जैसा हो सकता है।
- व्यवहार में, tools और users passwords को sensitive मानते हैं; URLs को नियमित रूप से store, share, और index किया जाता है।
- Links “something you have” हैं और आसानी से copy किए जा सकते हैं; passwords “something you know” हैं, कम से कम सिद्धांततः।
URLs में tokens के वैध उपयोग
- Password resets, email verification, S3 presigned URLs, और इसी तरह के flows के लिए short-lived, single-use tokens व्यापक रूप से स्वीकार किए जाते हैं।
- कुछ media access patterns (CDN-hosted images, cookies के बिना WebSockets, binary caches) अक्सर आवश्यकता या सुविधा के कारण URL tokens पर निर्भर करते हैं।
Mitigations और बेहतर patterns
- सुझाए गए mitigations: बहुत छोटा expiry, single use, per-user tokens, revocation, rate limiting, और लंबे समय तक चलने वाले “infinite use” magic links से बचना।
- Auth के लिए headers/cookies या POST bodies को प्राथमिकता दें; query strings या paths में persistent secrets से बचें।
- Secrets के लिए URL fragments का उपयोग उन्हें wire से दूर रखता है, लेकिन यह केवल client-side logic के साथ काम करता है और फिर भी JS exfiltration तथा browser history leakage का जोखिम रहता है।
- कुछ लोग URLs को “private” tag करने के लिए schemes या headers सुझाते हैं, लेकिन अन्य लोग नोट करते हैं कि attackers और कुछ scanners ऐसे tags को बस अनदेखा कर देंगे।
Scanning tools, UX, और responsibility
- इस पर बहस कि ज़िम्मेदार कौन है: सार्वजनिक रूप से scanned URLs को index करने वाली सेवाएँ, links को auto-submit करने वाले email/messaging platforms, या वे developers जो auth को URLs में encode करते हैं।
- कई लोग खराब UX की ओर ध्यान दिलाते हैं: ऐसे scan tools जो clear warning दिए बिना by default public results दिखाते हैं, या “public scan” और “report” जैसे अस्पष्ट labels।