Unicode hostname prompts गलत destination को approve कैसे कर सकते हैं

Agent के HTTP request के लिए approval card security boundary है, महज सूचना नहीं। अगर card एक destination बताए और HTTP stack credentials किसी दूसरे destination पर भेजे, तो user ने informed decision नहीं लिया। Gateway ने उनकी ओर से decision किया, बस typeface थोड़ा बेहतर था।

Unicode इस mismatch को बनाना आसान कर देता है, क्योंकि hostname के कई forms होते हैं जो देखने में जुड़े लगते हैं, लेकिन अलग काम करते हैं। User को Unicode दिखाई दे सकता है। DNS को ASCII-compatible labels मिलते हैं। URL parser separators, percent escapes, case, IPv4 notation या खाली अंतिम label को normalize कर सकता है। Redirect handler अगले location को किसी दूसरे code path से parse कर सकता है। अगर एक layer एक representation को approve करे और दूसरी layer दूसरे representation से connect करे, तो credentials गलत authority को भेजे जा सकते हैं।

समाधान "non-ASCII domains पर रोक लगा दो" नहीं है। इससे वैध internationalized names को नुकसान होगा और misleading subdomains, userinfo, numeric IP forms और redirect hops जैसे ASCII tricks फिर भी बच जाएंगे। समाधान यह है कि एक parsed authority record को अकेला ऐसा object बनाया जाए जो approval UI तक destination पहुंचाने और credential injection authorize करने, दोनों कामों में इस्तेमाल हो। इसके बाद production तक पहुंचने से पहले कठिन inputs को test करें।

Approval card को उसी request का विवरण देना चाहिए जो चलेगा

Approval prompt उसी canonical request object से आना चाहिए जिसे HTTP client execute करेगा। इसके अलावा कोई भी तरीका दो sources of truth बनाता है: लोगों के लिए display string और code के लिए transport string। यही विभाजन hostname confusion को credential disclosure में बदलता है।

Request को इस क्रम में बनाएं:

1. Raw URL को untrusted input मानें और gateway के लिए चुने गए URL implementation से उसे एक बार parse करें।
2. Unsupported schemes, malformed authorities, embedded credentials और ऐसे inputs अस्वीकार करें जिनका canonical form आपके hostname rules पर खरा नहीं उतरता।
3. एक structured authority record बनाएं जिसमें scheme, canonical host, effective port और input में trailing root dot था या नहीं, इसकी flag हो।
4. Approval card उसी record से render करें और credentials चुनने तथा inject करने वाले code को भी यही record दें।
5. Redirect, retry target, proxy target या alternate address authority record बदलता है तो fresh authorization मांगें।

Raw URL evidence है, authority नहीं। इसे activity record में रखें, क्योंकि इससे पता चलता है कि agent ने क्या करने की कोशिश की। Credential matching, approval caching या destination display के लिए अकेले raw URL का उपयोग न करें।

HTTP में authority केवल bare hostname नहीं होती। https://api.example.test:8443/ और https://api.example.test/ अलग services और certificate policies तक पहुंच सकते हैं। Parser के बाद default port को display से हटाया जा सकता है, लेकिन non-default port card पर होना चाहिए। Scheme भी दिखाएं। Host text समान होने पर भी http पर bearer token भेजना https की तुलना में अलग जोखिम पैदा करता है।

RFC 3986 host portion को IP literal, IPv4 address या registered name के रूप में परिभाषित करता है। यह उपयोगी syntax है, लेकिन approval system को यह नहीं बताता कि कोई व्यक्ति किसे सुरक्षित रूप से पहचान सकता है। Parsing को prerequisite मानें और parsed result के आधार पर security-specific display बनाएं।

Punycode identifier है, friendly name नहीं

Punycode इसलिए है ताकि DNS internationalized labels को ASCII की मदद से ले जा सके। A-label ASCII xn prefix से शुरू होता है और उसके बाद दो hyphens आते हैं, जबकि U-label उसका संबंधित Unicode form है। Conversion तभी reversible होता है जब label लागू IDNA rules के अनुसार valid हो। यह अंतर महत्वपूर्ण है, क्योंकि केवल A-label जैसा दिखने वाला string Unicode के रूप में दिखाने के लिए अपने-आप valid या सुरक्षित नहीं होता।

RFC 5891 के अनुसार IDNA-aware lookup application को apparent A-label को decode किए गए Unicode output को U-label मानने से पहले validate करना चाहिए। खास तौर पर, जब application native-language display के लिए A-label decode करे, तो उसे verify करना चाहिए कि वापस convert करने पर मूल label ही मिलता है। यह round trip केवल सैद्धांतिक बात नहीं है। इसके बिना UI malformed ASCII को convincing Unicode text में बदल सकता है और reviewer को ऐसी कहानी दिखा सकता है जो transport ने वास्तव में बताई ही नहीं।

जब input internationalized हो, approval card पर दोनों forms दिखाएं:

Destination
https://xn--example-ascii-label.test
Unicode rendering: example-unicode-label.test
Port: 443
Credential: deploy token

Canonical ASCII hostname को fixed-width या किसी अन्य अत्यंत स्पष्ट treatment में अपनी अलग line पर रखें। उसे disclosure control के पीछे न छिपाएं। Unicode rendering से human reviewer किसी legitimate service को पहचान सकता है, लेकिन ASCII form वह स्थायी identifier है जिसे allowlists, audit entries, cache keys और वास्तविक DNS lookup path से match होना चाहिए।

हर label को केवल इसलिए decode न करें कि वह A-label marker से शुरू होता है। Decode करें, validate करें, फिर re-encode करके तुलना करें। Validation असफल हो तो literal ASCII label दिखाएं और स्पष्ट warning दें कि hostname IDNA validation में असफल रहा। सुरक्षित action credential injection रोकना है, यह अनुमान लगाना नहीं कि agent का आशय क्या था।

यहां एक लोकप्रिय recommendation विफल होती है: "Always display Unicode because punycode looks suspicious." इससे friendly UI तो बनता है, लेकिन वह एकमात्र representation हटा दी जाती है जो fonts और scripts के बीच stable रहती है। Legitimate internationalized service के लिए केवल ASCII दिखाना भी खराब practice है। दोनों forms दिखाएं, ASCII को authoritative रखें और सुनिश्चित करें कि दोनों एक ही validated parser result से आए हों।

Mixed scripts पर warning दें, झूठा verdict नहीं

Latin और Cyrillic characters को मिलाने वाला hostname ASCII hostname जैसा लगभग बिल्कुल दिख सकता है। उदाहरण के लिए, किसी label में Cyrillic small letter हो सकता है जो कई fonts में Latin a, c, e, o, p या x जैसा दिखता है। Approval card को जल्दी-जल्दी देखने वाला reviewer इस substitution को चूक सकता है, खासकर जब name का महत्वपूर्ण हिस्सा छोटा हो।

Unicode Technical Standard #39 इसे mixed-script confusable कहता है, जब strings देखने में एक-दूसरे जैसी हों और result single-script confusable न हो। यह whole-script confusables का भी वर्णन करता है, जहां label एक script का उपयोग करता है लेकिन दूसरी script के label जैसा लगता है। Standard अपनी सीमा स्पष्ट बताता है: confusability fonts, contextual shaping और human familiarity पर निर्भर करती है। Detector risk पहचान सकता है, लेकिन यह साबित नहीं कर सकता कि कोई name deceptive है।

इसीलिए gateway को mixed-script check को automatic blocklist में नहीं बदलना चाहिए। Japanese, Korean, Chinese, Greek या multilingual organization का legitimate domain किसी सरल rule में असफल हो सकता है। इसके बजाय इस signal से approval posture बदलें:

• Mixed-script result वाले हर label को explicit per-call approval की आवश्यकता वाला mark करें।
• Reviewer host को expand करे तो detail view में scripts और code points render करें।
• Hostname के UTS #39 skeleton की तुलना protected internal names और स्पष्ट रूप से configured high-value destinations से करें।
• अगर destination protected name से confusable हो, तो वह पहले दिखाई न दिया हो तब भी automatic credential reuse अस्वीकार करें।
• Activity log में detector version और outcome दर्ज करें, ताकि बाद की review में decision दोहराया जा सके।

Skeleton comparison artifact है, replacement hostname नहीं। UTS #39 स्पष्ट रूप से कहता है कि skeleton results को identifiers के रूप में display, storage या transmission के लिए इस्तेमाल नहीं करना चाहिए। Canonical ASCII host store करें। Skeleton का उपयोग केवल एक सीमित सवाल पूछने के लिए करें: "क्या यह candidate ऐसे name जैसा दिखता है जिसे हमने extra protection देने का निर्णय लिया है?"

Protected-name set छोटी और जानबूझकर चुनी हुई होनी चाहिए। अपने deployment endpoints, package registries, source control hosts, identity providers और payment या production APIs शामिल करें। हर ऐसे public domain की विशाल list न बनाएं जो महत्वपूर्ण हो सकता है। इससे warnings इतनी बढ़ जाएंगी कि कोई उन्हें नहीं पढ़ेगा और महत्वपूर्ण warning भी सामान्य लगेगी।

Invisible code points review को rendering problem बना देते हैं

Invisible characters स्पष्ट non-ASCII characters से भी खराब हैं, क्योंकि reviewer उन्हें भरोसेमंद ढंग से देख नहीं सकता। Character और software के अनुसार वे joining behavior, text direction, line breaks या glyph selection को प्रभावित कर सकते हैं। कुछ IDNA द्वारा अस्वीकार हो सकते हैं। दूसरे libraries द्वारा map किए जा सकते हैं या अलग तरह से handle हो सकते हैं। Approval flow reviewer द्वारा ink की अनुपस्थिति पहचानने पर निर्भर नहीं होना चाहिए।

Teams अक्सर दो अलग सवालों को मिला देती हैं:

1. क्या यह code point IDNA hostname label में valid है?
2. क्या यह code point approval display को misleading, log को ambiguous या comparison code को inconsistent बना सकता है?

पहले सवाल का उत्तर दूसरे को तय नहीं करता। IDNA में कुछ code points के लिए contextual rules हैं और lookup validation कई invalid inputs को अस्वीकार करती है। लेकिन HTTP gateway raw URLs, UI rendering, JSON logs, copied text और संभवतः non-DNS host forms से भी निपटता है। Security review को पूरे route के लिए rules चाहिए, केवल DNS validity के लिए नहीं। RFC 5891 कहता है कि IDNA domain names के लिए है, arbitrary free text के लिए नहीं। इसे hostname processing तक सीमित रखें और यह न मानें कि यह complete URL को sanitize करता है।

Approval screen के लिए credential injection से पहले hostname अस्वीकार करें, यदि उसके parsed Unicode rendering में default-ignorable code point, bidirectional control या चुने गए IDNA implementation द्वारा invalid बताई गई character हो। यह "lookup आजमाकर देखते हैं" से जानबूझकर अधिक सख्त है। Anonymous public browser lookup करने की कोशिश कर सकता है। Credential gateway को ambiguous string की जांच करते समय token नहीं भेजना चाहिए।

Rejected input को log करते समय दो forms रखें: safely escaped code-point sequence और original byte sequence या UTF-8 text, ऐसे field में जो silent normalization से न गुजरे। एक अच्छा activity entry ऐसा हो सकता है:

raw_host_escaped: "api\\u200d.example.test"
parsed_host_ascii: null
rejection: "default-ignorable code point in hostname display"
credential_attached: false

Raw hostname को ऐसे sentence में न रखें जिसे operator सरसरी तौर पर पढ़ेगा। Incident response के दौरान logs अक्सर अगला approval UI बन जाते हैं। अगर terminal में invisible character फिर invisible हो जाए, तो आपने trap को केवल दूसरी जगह पहुंचाया है।

Trailing dot data है, भले DNS उसे root माने

Dot पर समाप्त होने वाला hostname cosmetic punctuation नहीं है। DNS presentation form में अंतिम dot root label को दर्शाता है और name को absolute mark करता है। RFC 1034 समझाता है कि हर complete domain name root label पर समाप्त होता है और printed form इसलिए dot पर समाप्त होती है।

इसका अर्थ यह नहीं कि हर HTTP component api.example.test और api.example.test. को समान मानता है। एक parser अपने hostname property में dot रख सकता है। दूसरा connection से पहले उसे normalize कर सकता है। Certificate verifier, cookie implementation, proxy, allowlist या redirect cache तीसरा behavior अपना सकता है। एकमात्र सुरक्षित rule यह है कि तय करें कि आपका gateway इन्हें equivalent मानता है या नहीं और request संभालने वाले हर component में उस निर्णय को test करें।

Credential gateway के लिए input fact को preserve करने और documented comparison rule के बाद authority normalize करने की सलाह है। दोनों store करें:

input_host: "api.example.test."
canonical_dns_name: "api.example.test"
had_root_dot: true

फिर destination record से match करने के लिए canonical_dns_name उपयोग करें, लेकिन input में dot मौजूद हो तो approval card पर अंतिम dot दिखाएं। Reviewer को दिखना चाहिए कि agent ने थोड़ा असामान्य form दिया था। सामान्य dot को authority को चुपचाप व्यापक नहीं बनाना चाहिए। अगर api.example.test के लिए credential approve किया गया है, तो api.example.test. उसी approval का पुन: उपयोग तभी कर सकता है जब parser, resolver, TLS name verifier और gateway comparison rule सभी उसी destination पर सहमत हों।

Parsing से पहले generic string code से trailing dot न हटाएं। Generic trimming अक्सर "host को clean up करो" में बदल जाती है और फिर whitespace, punctuation या Unicode separators भी हटने लगते हैं, जबकि उन्हें rejection कराना चाहिए था। पहले parse करें। केवल उन attributes को normalize करें जिनके लिए लिखित semantic rule हो।

Parser test corpus में slide deck के examples नहीं, hostile cases होने चाहिए

Hostname test suite को parsing, canonicalization, display, credential matching, connection setup और logging के बीच agreement assert करना चाहिए। Unicode label को ASCII में बदलने वाले helper का test उपयोगी है, लेकिन इससे request path सुरक्षित साबित नहीं होता।

पहले pass के लिए production URL runtime का उपयोग करें। निम्न Node script WHATWG URL parser को चलाती है और वे fields दिखाती है जिनकी approval gateway को तुलना करनी चाहिए। यह जानबूझकर JSON print करती है, ताकि CI में diffs पढ़ने योग्य रहें।

const cases = [
  "https://example.test/",
  "https://example.test./",
  "https://münich.example.test/",
  "https://xn--example-ascii-label.test/",
  "https://pаypal.example.test/",
  "https://api\u200d.example.test/",
  "https://[email protected]/",
  "https://example.test:8443/",
  "https://127.0.0.1./"
];

for (const raw of cases) {
  try {
    const u = new URL(raw);
    console.log(JSON.stringify({
      raw,
      href: u.href,
      protocol: u.protocol,
      hostname: u.hostname,
      host: u.host,
      port: u.port,
      username: u.username,
      passwordPresent: u.password.length > 0
    }));
  } catch (error) {
    console.log(JSON.stringify({ raw, rejected: error.message }));
  }
}

Expected output का shape universal expected string से अधिक महत्वपूर्ण है, क्योंकि runtimes बदलते हैं और host parsing rules platform के अनुसार अलग हो सकते हैं। हर accepted case को ऐसा exactly one canonical hostname produce करना चाहिए जो सभी later stages तक पहुंचे। हर rejected case को साबित करना चाहिए कि gateway ने credential attach नहीं किया और network request नहीं भेजा।

Corpus में उन scripts के labels जोड़ें जिनका आपकी team वास्तव में सामना करती है, Unicode जैसे दिखने वाले dots, host में percent encoding, leading combining marks, brackets और IPv6 forms, upper-case A-labels, malformed A-labels, empty labels, local names और redirects। Bug reports से cases जोड़ें। Test suite तब उपयोगी बनती है जब उसमें वे strings हों जिनकी वजह से engineer ने log file देखकर परेशानी झेली, न कि example.com के दस variations।

WHATWG URL Standard web URL behavior के लिए उपयोगी baseline है, क्योंकि यह host parsing, percent-encoded-host failures, Unicode-to-ASCII processing और IPv4 edge cases निर्दिष्ट करता है। इससे यह मानने की अनुमति नहीं मिलती कि हर HTTP stack, DNS library या UI widget का behavior एक जैसा होगा। Corpus को अपने वास्तविक stack में चलाएं।

Redirects के लिए नया authority decision चाहिए

पहला approval उन सभी hosts को authorize नहीं करता जहां request बाद में जा सकता है। Redirect handling अक्सर उस application code से नीचे रहती है जिसने prompt दिखाया था, इसलिए credentials को अनजाने में आगे ले जाने की यह आम जगह है।

मान लें agent https://build.example.test/artifact मांगता है। User उस host के लिए deployment token approve करता है। Response https://downloads.example.test/file या, इससे भी खराब, किसी lookalike Unicode hostname पर redirect लौटाता है। अगर client redirects अपने-आप follow करता है और Authorization header रखता है, तो gateway approval boundary को bypass कर चुका है।

सरल rule अपनाएं: scheme, canonical hostname या effective port बदलने वाला HTTP redirect पिछली credential authorization को invalid कर देता है। Operation के लिए सुरक्षित हो तो gateway redirect को बिना credentials follow कर सकता है, लेकिन नए authority पर credential inject करने से पहले रुकना होगा। नए parsed URL से बना नया approval card दिखाएं।

Origin change और path change को अलग रखें। उसी canonical scheme, host और port के भीतर redirect को authorization रखने की अनुमति मिल सकती है, यदि operation के path rules इसकी अनुमति दें। इसे text-prefix comparison तक सीमित न करें। https://api.example.test.evil.test/ आश्वस्त करने वाली string से शुरू होता है, लेकिन उसका host अलग है।

Bearer tokens के लिए हर cross-authority redirect पर Authorization हटाना default रखें। Client certificates और SSH-style credentials के मामले में transport layer redirect होने से पहले ही identity चुन सकती है, इसलिए gateway को connection setup पर equivalent rule चाहिए। Principle वही है: authorization parsed authority से बंधी है, agent के initial intention से नहीं।

Credential selection की boundaries exact होनी चाहिए

कई API keys रखने वाले gateway को तय करना होता है कि कौन-सी key किस host पर जा सकती है। यह UI concern नहीं है। यही वह point है जहां display mistake network action बनती है।

Credential binding को structured data के रूप में रखें, जैसे:

{
  "scheme": "https",
  "host_ascii": "api.example.test",
  "port": 443,
  "allow_subdomains": false,
  "require_per_call_approval": true
}

host.endsWith("example.test") जैसी rule से बचें। इससे notexample.test स्वीकार हो जाता है, और preceding dot check वाला careless variant भी Unicode normalization या trailing root dot को गलत संभाल सकता है। Subdomains support करने हों तो canonical ASCII labels को split करके right to left तुलना करें। api.example.test parent example.test से तभी match हो जब binding subdomains की स्पष्ट अनुमति देती हो। Parent को reverse direction में child से कभी match नहीं होना चाहिए।

IP literals को registered names से अलग रखें। IP का reverse-resolve करके उस पर hostname credential rule लागू न करें। DNS names बदल सकते हैं और reverse DNS यह साबित नहीं करता कि कोई IP API credential के लिए authorized है। इसी तरह hostname resolve करके उससे मिलने वाले हर address को approve न करें। Credential TLS और HTTP authority में उपयोग किए गए hostname से बंधा है, जबकि connection controls private, loopback, link-local या अन्य disallowed addresses को अलग से सीमित कर सकते हैं।

Gateway को credential binding और approval में भी अंतर रखना चाहिए। Binding का उत्तर है, "क्या यह credential यहां कभी इस्तेमाल हो सकता है?" Approval का उत्तर है, "क्या किसी व्यक्ति ने इस agent process को इस request या session के लिए इसका उपयोग authorize किया?" इन सवालों को मिलाने से allowlist unattended signing oracle बन जाती है।

Audit records में वही सुरक्षित रहना चाहिए जो reviewer ने देखा

जब कोई approval बाद में गलत दिखे, operators को तीन सवालों के उत्तर चाहिए: agent ने क्या भेजा, gateway ने कौन-सी canonical authority execute की और reviewer ने कौन-सा exact text देखा? एक rendered URL इन तीनों का उत्तर नहीं दे सकता।

इन fields को अलग-अलग record करें:

• raw URL या उसका safely escaped representation;
• parsed scheme, canonical ASCII hostname, effective port और path;
• validated Unicode hostname rendering, यदि कोई हो;
• hostname risk flags, जैसे trailing root dot, mixed-script result, confusable protected-name match और invisible-character rejection;
• approval decision, credential identifier और gateway ने credentials attach किए या नहीं।

Client request शुरू करने से पहले approval record को immutable बनाएं। Client बाद में redirect follow करे तो अपने parsed authority और decision वाला linked child record बनाएं। "approved request succeeded" कहने वाली log line पर्याप्त नहीं है, जब महत्वपूर्ण तथ्य यह हो कि पहले host ने दूसरे host के लिए Location header लौटाया था।

Sallyport का Sessions journal और Activity journal में विभाजन इस evidence के लिए समझदारी भरा ढांचा है: session बताता है कि किस process को authority मिली, जबकि call record बताता है कि किस destination ने उसका उपयोग किया। इसका hash-chained audit log history को offline verify कर सकता है, लेकिन उपयोगी fields action होने से पहले capture होने चाहिए। Tamper-evident खाली field फिर भी खाली field ही होती है।

Suspicious hostnames को agent के लिए महंगा बनाएं, reviewer के लिए confusing नहीं

सबसे सुरक्षित approval UX किसी व्यक्ति से यह अपेक्षा नहीं करता कि वह दो seconds में Unicode specialist बन जाए। यह risky forms के लिए agent से अधिक authority मांगता है और reviewer को स्पष्ट decision लेने के लिए पर्याप्त evidence देता है।

इस behavior matrix का उपयोग करें:

Warning card को theatrical न बनाएं। Red text की दीवार लोगों को click through करना सिखाती है। कारण सरल भाषा में रखें: "यह hostname Latin और Cyrillic characters मिलाता है" या "इस hostname में invisible Unicode character है।" फिर canonical ASCII host, requested credential और action दिखाएं। लोग actions approve करते हैं, lectures नहीं।

पहला test ऐसा request होना चाहिए जो casual reader को protected host जैसा दिखे, लेकिन parse होने पर किसी दूसरी authority में बदल जाए। इसे exact agent shim, approval UI, credential selector, HTTP library, redirect code और audit logger से गुजारें। अगर कोई stage अलग hostname string produce करे और denial न कराए, तो gateway में अब भी दो truths हैं। कोई और policy toggle जोड़ने से पहले इसे ठीक करें।