Authenticated agent requests के लिए HTTP redirect validation

HTTP redirect validation तब होनी चाहिए, जब एजेंट क्रेडेंशियल अगले URL पर भेजने से पहले उसकी जांच कर रहा हो। रीडायरेक्ट किसी एक अनुरोध का मामूली विस्तार नहीं है। यह remote server का निर्देश है कि एक और अनुरोध किया जाए, अक्सर किसी अलग authority, अलग method और अलग network destination पर।

यह अंतर तब अक्सर नजरअंदाज हो जाता है, जब लोग एजेंट को API client से जोड़कर client की default redirect setting चालू छोड़ देते हैं। एजेंट approved API को अनुरोध भेजता है। API जवाब देता है, 302 Location: https://somewhere-else/...। Client उसे फॉलो कर लेता है। अगर authentication बहुत जल्दी जोड़ दी गई, तो पहले endpoint, किसी redirect parameter या compromised dependency पर नियंत्रण रखने वाला हमलावर स्वीकृत कॉल को क्रेडेंशियल भेजने वाली सेवा में बदल सकता है।

मैंने देखा है कि इसे यह कहकर टाल दिया जाता है कि अच्छी HTTP libraries host बदलने पर अक्सर Authorization हटा देती हैं। यह सुरक्षा मददगार है, लेकिन न तो हर जगह लागू होती है और न ही पर्याप्त है। इससे custom credential headers, signed query parameters, cookies, redirected request bodies, DNS changes या same-host redirects से किसी खतरनाक endpoint तक पहुंचने का सवाल हल नहीं होता। Library defaults को अपनी policy मानने के बजाय redirect decision स्पष्ट रूप से बनाएं।

रीडायरेक्ट नया authorization decision बनाते हैं

हर redirect hop की जांच पहले URL जितनी ही सावधानी से करनी चाहिए, क्योंकि अगला destination server चुनता है। Client ने एक resource मांगा था और उसे Location field में किसी दूसरे URI का प्रस्ताव देने वाला जवाब मिला। मूल allow decision अपने-आप उस proposed URI पर लागू नहीं होता।

RFC 9110 redirects को उनके status codes से परिभाषित करता है और user agents को बताता है कि वे कैसे प्रतिक्रिया दे सकते हैं या देनी चाहिए। यह नहीं कहता कि initial request के साथ लगा API credential हर उस URI के लिए authorized है जिसे server लौटा सकता है। इस अंतर की जिम्मेदारी caller की है। Agent gateway में caller यह तय करता है कि वह कौन-सी downstream actions करेगा।

Code और logs में इन दो घटनाओं को अलग रखें:

1. Server पहले से किए गए अनुरोध के लिए redirect response भेजता है।
2. Client resolved target पर नया अनुरोध करने का निर्णय लेता है।

पहली घटना एक तथ्य है। दूसरी privileged action है। अगर implementation इन्हें client.Do(request) जैसी सुविधा वाली call के अंदर automatic redirects के साथ मिला देती है, तो वह वह क्षण छिपा देती है जब policy लागू होनी चाहिए।

एक redirect एक साथ कई सीमाएं पार कर सकता है। https://api.example.test/v1/export शायद https://downloads.example.test/file पर जाए और फिर storage provider के time-limited object URL पर। यह chain वैध हो सकती है। इसका मतलब यह भी है कि «पहला host approved है» जैसी ढीली rule final connection के बारे में लगभग कुछ नहीं बताती।

Relative redirects भी उतनी ही सावधानी मांगते हैं। Location: ../admin को पैदा करने वाले URL के आधार पर standards-compliant URL parser से resolve करें। Strings को जोड़कर URL न बनाएं। // से शुरू होने वाला path scheme-relative होता है और host बदल सकता है। Encoded delimiters और empty Location value जैसे असामान्य रूपों ने clients में काफी असंगतियां पैदा की हैं, इसलिए gateway को अनुमान लगाने के बजाय अस्पष्टता अस्वीकार करनी चाहिए।

Destination पास होने के बाद ही क्रेडेंशियल जोड़ें

सुरक्षित क्रम सरल है: response पाएं, candidate destination parse करें, उसकी validation करें, अगला request बनाएं, फिर उस destination के लिए स्वीकृत क्रेडेंशियल ही जोड़ें। Credential injection अंतिम dispatch point पर होना चाहिए, ऐसे mutable request object में नहीं जो पूरी redirect chain में बना रहे।

अधिकांश leaks इसी design error से होते हैं। कोई wrapper Authorization: Bearer ... वाला request बनाता है, उसे भेजता है और HTTP client को redirect के बाद request clone या replay करने देता है। Wrapper token को एक host के लिए रखना चाहता था, लेकिन अब हर send पर उसका नियंत्रण नहीं रहता।

ऐसे request description का इस्तेमाल करें जिसमें secret material न हो। उसमें method, body, permitted credential reference और initial URL हो सकते हैं। हर hop के लिए validation के बाद नया wire request बनाएं। Dispatch layer credential को तभी lookup करे, जब target की अनुमति मिल चुकी हो।

एक छोटा model इस तरह दिख सकता है:

request intent:
  method: POST
  initial URL: https://api.acme.test/v1/reports
  credential reference: billing-api-prod
  body digest: sha256:...

for each response:
  if status is not a supported redirect: return response
  target = resolve(response.request_url, response.headers["Location"])
  decision = validate(target, request intent, response.status)
  if decision is reject: record rejection and stop
  next_request = build(decision.method, target, permitted body)
  inject(credential reference, target, next_request)
  send(next_request)

महत्वपूर्ण बात pseudocode नहीं, secret का lifetime है। Token केवल उस request में मौजूद रहता है जिसने destination validation पास कर ली है। वह किसी generic object में नहीं रहता, जिसे redirect callback गलती से आगे भेज दे।

यह क्रम credential scope को लागू करना भी संभव बनाता है। api.acme.test के लिए bearer token को uploads.acme.test पर अपने-आप authenticate नहीं करना चाहिए, भले दोनों नाम एक ही कंपनी के हों। हर destination rule को स्पष्ट credential reference दें। अगर दो services जानबूझकर एक credential साझा करती हैं, तो उस संबंध को rule में लिखें, DNS suffix से उसका अनुमान न लगाएं।

Origin matching एक leak रोकता है, बाकी नहीं

Strict origin match स्पष्ट host changes को रोकता है, लेकिन इससे यह तय नहीं होता कि redirected request सुरक्षित है। Origin में scheme, host और port शामिल होते हैं। इनमें से किसी भी field के बदलने को boundary मानें, जब तक आपके पास स्पष्ट exception न हो।

Scheme महत्वपूर्ण है। HTTPS से HTTP पर redirect network पर headers या request contents उजागर कर सकता है। Authenticated traffic के लिए downgrade अस्वीकार करें। HTTP से HTTPS का redirect सुरक्षित लग सकता है, फिर भी authority बदलता है और अनपेक्षित endpoint छिपा सकता है। इसे सामान्य तरीके से validate करें।

Port भी महत्वपूर्ण है। https://api.example.test और https://api.example.test:8443 अलग origins हैं। Developers इसे अक्सर भूल जाते हैं, क्योंकि browsers default ports छिपा देते हैं और local test environments में alternate ports लगातार इस्तेमाल होते हैं। Public API के लिए बना token administration service तक पहुंच सकता है, अगर allow rule केवल hostname जांचती हो।

जब API host अलग-अलग applications चलाता हो, तब path भी मायने रखता है। /v1/files से /internal/debug/export का redirect उसी origin पर रहता है, लेकिन इससे body उजागर हो सकती है या unsafe state change हो सकता है। Path allowlist को application authorization का विकल्प न बनाएं, लेकिन redirect targets को उन API prefixes तक सीमित करें जिनकी integration को वास्तव में जरूरत है।

Query parameters के साथ विशेष सावधानी रखें। Redirect target में pre-signed URL, state parameter या one-time download token हो सकता है। व्यवहार में ये values credentials ही हैं, भले Authorization header का इस्तेमाल न करती हों। पुराने request के query parameters को नए URL में copy न करें। Parsed redirect target का ठीक वही रूप इस्तेमाल करें, और userinfo fields, fragments या credential जैसे parameters को रोकने वाली rule लागू करें।

व्यावहारिक baseline यह है कि same-origin redirects तभी अनुमति पाएं जब scheme HTTPS रहे, port approved रहे, target path integration के allowed API surface में हो और redirect status intended method की अनुमति देता हो। Cross-origin redirects को named destination rules वाली अलग category मानें।

Redirect status codes आपके भेजे जाने वाले request को बदलते हैं

Redirect status codes method semantics रखते हैं। इन्हें नजरअंदाज करने वाला client सुरक्षित read को अनपेक्षित write में बदल सकता है या sensitive body को फिर से भेज सकता है। हर 3xx response को «Location फॉलो करो» में न बदलें।

RFC 9110 के अनुसार 307 और 308 request method और content को बनाए रखते हैं। अगर मूल request report definition वाला POST था, तो 307 या 308 client से वही POST और body नए target पर भेजने को कहते हैं। यह सबसे जोखिम वाला redirect case है, क्योंकि नया host business data और side effects वाला request दोनों पा सकता है।

Status 303 client को मूल method की परवाह किए बिना GET या HEAD से representation लेने का निर्देश देता है। यह अक्सर form-style submission के बाद दिखाई देता है। Agent action के लिए इसे तभी अनुमति दें जब redirected GET target अलग से approved हो और integration इस pattern की अपेक्षा करती हो। केवल इसलिए 303 को Authorization header नहीं मिलना चाहिए कि initial POST में वह header था।

301 और 302 पुराने समस्याग्रस्त status codes हैं। RFC 9110 इन responses के लिए POST को GET में बदलने की लंबे समय से चली आ रही practice बताता है, जबकि 307 और 308 उन callers के लिए मौजूद हैं जिन्हें method बनाए रखना होता है। Libraries के व्यवहार में अंतर होता है, खासकर non-POST methods और bodies के मामले में। Autonomous client क्या भेजेगा, इसका निर्णय इस अस्पष्टता पर न छोड़ें।

व्यवहार लिखित रूप में तय करें। उदाहरण के लिए:

• 301 और 302 को केवल GET और HEAD requests के लिए फॉलो करें।
• 303 को केवल credential-free GET या HEAD से फॉलो करें, फिर credential जोड़ने से पहले target को दोबारा validate करें।
• 307 और 308 को तभी फॉलो करें, जब destination rule मूल method और body class की स्पष्ट अनुमति देती हो।
• POST, PATCH या DELETE जैसी non-idempotent method के बाद redirect अस्वीकार करें, जब तक integration में documented redirect flow न हो।

इससे खराब design वाली API शायद टूट जाए। यह कहीं बेहतर है, बजाय इसके कि payment instruction, source upload या administrative command को remote server द्वारा चुने गए किसी स्थान पर चुपचाप replay कर दिया जाए। अगर vendor को redirected writes की जरूरत है, तो सीमित exception जोड़ें और ठीक sequence की testing करें।

Destination rules को hostname string से अधिक जानकारी चाहिए

एक उपयोगी redirect validator target को ऐसी rule के सामने जांचता है जिसमें उस service का पर्याप्त विवरण हो जिसे आप call करना चाहते हैं। Bare hostname allowlist आकर्षक लगती है, क्योंकि वह छोटी होती है। लेकिन exceptions जुड़ते-जुड़ते ऐसी स्थिति आ सकती है जहां कोई नहीं बता सके कि agent क्या और कहां भेज सकता है।

हर permitted redirect destination के लिए ये बातें तय करें:

• कौन-सी schemes allowed हैं, आमतौर पर केवल HTTPS।
• कौन-से normalized hostnames और ports allowed हैं।
• Redirected request किन methods और path prefixes का इस्तेमाल कर सकता है।
• वहां कौन-सा credential reference, यदि कोई हो, जोड़ा जा सकता है।
• क्या target private या local network addresses पर resolve हो सकता है।

Matching से पहले normalize करें। DNS hostnames को lowercase करें, trailing dot को एकसमान तरीके से हटाएं, bracketed IPv6 literals को सही तरह parse करें और malformed percent encoding अस्वीकार करें। Raw URL strings की तुलना कभी न करें। https://[email protected]/ में @ से पहले trusted name होने के बावजूद host evil.test है।

Authority check के लिए endsWith("example.test") का इस्तेमाल न करें। यह notexample.test को भी स्वीकार कर लेता है। *.example.test जैसी delimiter-aware suffix rule को भी ownership review की जरूरत होती है। Wildcard subdomains में preview systems, customer-controlled names, redirectors या किसी दूसरी group द्वारा managed infrastructure हो सकता है।

Validator को केवल boolean के बजाय कारण सहित decision लौटाना चाहिए। Operators को पता होना चाहिए कि उसने scheme downgrade, unapproved port, disallowed method, private address या redirect limit समाप्त होने के कारण request अस्वीकार किया। यह जानकारी token values हटाकर action record में रखें।

Redirect limit छोटी और fixed रखें। इससे loops रुकते हैं और लंबी chain दिखाई देती है। Agent से मिली count को स्वीकार न करें। Gateway यह limit तय करता है, क्योंकि network actions की जिम्मेदारी उसी की है।

सामान्य download flow privileged request leak कर सकता है

खतरनाक cases आमतौर पर attack के नाम से नहीं आते। वे अक्सर ऐसे सामान्य सुविधा endpoints लगते हैं जो URL स्वीकार करते हैं या download location लौटाते हैं।

मान लें कि agent को approved billing API से report लाने को कहा गया है। Agent bearer token के साथ POST /v1/exports भेजता है। API download URL पर 303 लौटाती है। Gateway उसे अपने-आप फॉलो करता है और bearer token भी भेज देता है, क्योंकि उसका custom header injector HTTP library के redirect hook से पहले चल चुका था।

शुरू में download host उसी team द्वारा चलाया जाने वाला दूसरा service है। कुछ महीनों बाद configuration बदलती है और export endpoint customers को storage provider इस्तेमाल करने देने के लिए destination parameter स्वीकार करने लगता है। Report parameters तक पहुंच रखने वाला हमलावर अपने नियंत्रण वाले URL को देता है। Approved API उस URL पर redirect लौटाती है। HTTP library इसे सामान्य 303 मानती है, और gateway पहले ही X-Service-Token जोड़ चुका है।

कुछ भी बहुत असामान्य नहीं हुआ। पहला API request allowed था, redirect syntax valid था और token agent prompt में कभी नहीं आया। गलती यह थी कि target पता चलने से पहले credential assign कर दिया गया।

सही implementation 303 record करती है, target resolve करती है, पहचानती है कि host के लिए कोई destination rule नहीं है और रुक जाती है। Operator को कोई रहस्यमय outbound call नहीं, बल्कि rejected redirect दिखाई देता है। अगर intended download service को access चाहिए, तो उसके exact host के लिए अलग rule बनाएं और ऐसा download credential इस्तेमाल करें जो billing API को call न कर सके।

Agents इस failure का एक और रास्ता जोड़ते हैं। Agent issue text, repository configuration file, API response field या tool के instruction के जरिए URL को प्रभावित कर सकता है। केवल इसलिए यह न मानें कि URL developer से आया है क्योंकि वह आपके agent द्वारा बनाए गए request के अंदर दिखाई देता है। Data बहुत जल्दी routing input बन सकता है।

DNS checks connection के समय होनी चाहिए

केवल hostname validation server-side request forgery को नहीं रोकती। Review के समय hostname public address पर resolve हो सकता है, लेकिन client के connect करने पर loopback, link-local या private space पर। Redirect handling हमलावर को इस अंतर का फायदा उठाने के बार-बार अवसर देती है।

हर approved hostname को connection time के करीब resolve करें और लौटने वाले हर address को network rules के विरुद्ध जांचें। Loopback ranges, unspecified addresses, link-local ranges, private ranges, multicast addresses और उनके IPv6 equivalents को अस्वीकार करें, जब तक कोई rule उन्हें स्पष्ट रूप से अनुमति न देती हो। Redirect URLs में दिए literal IP addresses पर भी यही व्यवहार लागू करें।

Hostname को एक बार resolve करके एक address approve न करें और फिर किसी अलग HTTP stack को उसे दोबारा resolve करने दें। इससे time-of-check और time-of-use gap बनता है। Connection को उसी address set का इस्तेमाल करना चाहिए जिसे आपने evaluate किया है, या transport को peer address की भरोसेमंद पुष्टि और mismatch पर rejection की सुविधा देनी चाहिए। Connection pools, proxies और dual-stack DNS शामिल होने पर यह काम जितना सुनाई देता है उससे कठिन होता है।

Corporate proxy deployments के लिए exception model स्पष्ट रखें। अगर gateway केवल किसी explicit proxy से connect करता है, तो proxy को network peer के रूप में validate करें और proxy request बनाने से पहले application destination rules बनाए रखें। केवल इसलिए सभी private ranges को safe न मानें कि organization private service addresses इस्तेमाल करती है। उन internal hosts और ports के नाम दें जिनकी agent को जरूरत है।

DNS rebinding एक वजह है कि redirect rule को hostname की स्थायी मंज़ूरी नहीं माना जा सकता। Cache behavior, TTLs और resolver differences उत्तर बदल सकते हैं। जिस connection को बनाने वाले हैं, उसी के लिए decision लें और selected peer address log करें, लेकिन इसे application destination के authorized होने का प्रमाण न समझें।

Cookies, signed URLs और bodies भी credentials हैं

Teams अक्सर Authorization को सुरक्षित करती हैं और बाकी outbound material को वैसे ही छोड़ देती हैं। Redirect कई अन्य channels से credentials या sensitive data leak कर सकता है।

Cookies के domain और path rules होते हैं, लेकिन agent gateway को machine credentials के लिए सामान्य browser-style cookie jar पर निर्भर नहीं रहना चाहिए। Privileged calls के लिए cookies को default रूप से बंद रखें। अगर integration को cookies चाहिए, तो jar को उसी integration तक सीमित करें और हर redirect target के लिए cookie attachment का फिर से मूल्यांकन करें।

Pre-signed URLs authorization को query string में रखते हैं। आमतौर पर इन्हें कोई दूसरा service token जोड़े बिना काम करना चाहिए। अगर destination rule किसी pre-signed storage URL को पहचानती है, तो उसे URL में पहले से मौजूद authorization material के साथ और सीमित method, आमतौर पर GET या PUT, से dispatch करें। आदत के कारण अपने standard headers न जोड़ें।

Request bodies में भी secrets होते हैं। JSON body में source archive, customer data या opaque signed assertion हो सकती है। 307 और 308 के लिए स्पष्ट rule मांगें जो उस सटीक service को body replay की अनुमति देती हो। दूसरे redirect codes पर body को चुपचाप transform या resend न करें। Client library की सुविधा sensitive content को दोहराने का कारण नहीं है।

जब client उसे जोड़ता है, तो HTTP Referer paths और query values उजागर कर सकता है। API clients को सामान्यतः redirects के दौरान Referer header आगे नहीं ले जाना चाहिए। इसी तरह original internal route, agent session या user identity बताने वाले headers को भी हटाएं, जब तक destination rule को उनकी स्पष्ट जरूरत न हो।

Headers को तीन groups में बांटें: वे headers जिन्हें हमेशा फिर से बनाया जा सकता है, वे जिन्हें केवल named destination के लिए अनुमति है और वे जिन्हें redirect के पार कभी नहीं जाना चाहिए। यह अस्पष्ट «sensitive headers» list रखने से अधिक भरोसेमंद है। Permitted upload के लिए Content-Type harmless हो सकता है, लेकिन X-Internal-Actor उस व्यक्ति की पहचान बता सकता है जिसने अगले host को कभी authorize नहीं किया।

पूरी chain को कई hops वाली एक action की तरह audit करें

Audit record में redirect chain दिखनी चाहिए, लेकिन उस material को उजागर किए बिना जिसने request को privileged बनाया। केवल final URL और status code पर्याप्त नहीं हैं। उनसे पता नहीं चलता कि client ने origin पार किया, method बदला, authentication हटाया या connect करने से पहले suspicious target अस्वीकार किया।

Initial request intent, हर response status, redaction के बाद हर raw Location value, resolved target, policy result, selected method और उस hop के लिए इस्तेमाल credential class दर्ज करें। Stable credential identifier रखें, token, password या पूरा signed URL कभी नहीं। Full URL का hash correlation में मदद कर सकता है, लेकिन कम entropy वाले input में hash को सुरक्षित redaction न समझें।

सभी hops को एक parent action identifier से जोड़ें। तब investigator «agent ने export मांगा» और «gateway ने export पूरा करते समय चार network calls कीं» के बीच फर्क कर सकेगा। इससे operator chain के असामान्य व्यवहार करने पर live session revoke भी कर सकता है।

Tamper-evident log बाद में उपयोगी evidence देता है, लेकिन unsafe redirect को रोकता नहीं। Prevention forwarding path में होनी चाहिए। Sallyport agent sessions और individual calls को एक encrypted, hash-chained audit log में record करता है, इसलिए redirect-aware action records chain को final result में समेटने के बजाय decision trail बनाए रख सकते हैं।

जानबूझकर rejected cases के साथ log की testing करें। Cross-origin 302, HTTPS-to-HTTP redirect, POST के बाद 307, malformed Location field और loopback पर resolve होने वाला target चलाएं। अगर इन records से reviewer को यह पता नहीं चलता कि gateway क्यों रुका, तो incident के लिए मजबूर होने से पहले event schema सुधारें।

Redirect behavior को tool contract का हिस्सा बनाएं

HTTP API call करने वाले tool को अपने users को बताना चाहिए कि वह redirects फॉलो करता है या नहीं और किन शर्तों पर। «Uses standard HTTP» कोई contract नहीं है। Libraries के बीच behavior बदलता है और client बदलने, proxy जोड़ने या authentication को middleware में ले जाने पर भी बदल सकता है।

अलग-अलग endpoints वाले local redirect fixture के विरुद्ध tests लिखें। Fixture नियंत्रित status codes और Locations लौटाए, फिर incoming method, body digest, host और headers capture करे। Assertions से साबित होना चाहिए कि unapproved target को credential header नहीं मिलता, 303 POST body replay नहीं करता और permitted 307 केवल वही headers और body भेजता है जिन्हें rule अनुमति देती है।

Agent को अपने tool arguments में redirect policy चुनने न दें। Agent किसी known integration का अनुरोध कर सकता है और सामान्य request parameters दे सकता है। Gateway तय करता है कि उस integration के लिए redirect following उपलब्ध है या नहीं, कितने hops की अनुमति है और कौन-से credentials इस्तेमाल किए जा सकते हैं। यह separation prompt injection को follow_redirects=true बनने से रोकती है।

पहले implementation के लिए जानबूझकर सीमित contract चुनें: केवल approved HTTPS redirects को GET और HEAD के लिए फॉलो करें, validation के बाद destination के अनुसार credentials जोड़ें और हर redirected write को अस्वीकार करें। Exceptions तभी जोड़ें जब आप vendor flow, destination boundary, method behavior और audit record की स्पष्ट व्याख्या कर सकें। कुछ explicit rejections developers को परेशान करेंगी। हमलावर को भेजा गया token सबको कहीं ज्यादा परेशान करेगा।