SaaS outbound webhook सुरक्षा: customer URL में SSRF रोकें

Destination validation, नियंत्रित egress, tenant-specific secrets, सीमित retries और SSRF tests से customer endpoints तक webhook सुरक्षित पहुँचाएँ।

इस मार्गदर्शिका में

SaaS outbound webhook में SSRF कैसे रोकें?

Outbound webhook में आपका service customer द्वारा दिए URL से connection बनाता है। Malicious या compromised tenant delivery worker से internal system तक पहुँचने की कोशिश कर सकता है। हर destination को untrusted मानें। Save करते समय और connect करते समय validate करें, network egress सीमित करें और हर tenant का endpoint तथा secret अलग रखें। यह आपका service callbacks भेजता है उस path पर है; incoming signature और retry design अलग guide में है।

केवल जरूरी URL formats स्वीकारें

जब तक documented exception न हो HTTPS माँगें। URL में embedded credentials, unsupported schemes, control characters, ambiguous encoding और अनपेक्षित ports रोकें। Maintained URL parser से host normalize करें; केवल substring या 'trusted.com पर खत्म होता है' जैसी कमजोर जाँच पर भरोसा न करें।

इस बिंदु के स्रोत: OWASP Server-Side Request Forgery Prevention Cheat SheetOWASP Web Service Security Cheat Sheet

Connection के समय private और special-use destinations रोकें

IPv4 और IPv6 loopback, private, link-local, multicast, reserved तथा cloud metadata addresses deny करें। DNS resolve कर सभी returned addresses जाँचें, पर DNS rebinding भी संभालें: वास्तविक connection जिस address पर हो, उसे भी policy माननी चाहिए। Controlled egress proxy या network policy दूसरी सीमा देता है; केवल application validation काफी नहीं।

इस बिंदु के स्रोत: OWASP Server-Side Request Forgery Prevention Cheat SheetAmazon VPC: Control Traffic with Security Groups

Redirect और पूरे delivery request को नियंत्रित करें

जहाँ संभव हो automatic redirects बंद करें। यदि product redirects follow करता है, तो हर hop के destination पर वही policy फिर लागू करें। Connection तथा total timeout रखें, response size cap करें, methods और headers सीमित करें और internal authorization headers या cloud credentials customer host को कभी न भेजें।

इस बिंदु के स्रोत: OWASP Server-Side Request Forgery Prevention Cheat SheetOWASP REST Security Cheat Sheet

Outbound webhook destination worksheet
Tenant और endpoint ID	Scheme/port policy	DNS और egress checks	Secrets और payload scope	Timeout/retry/test owner
Billing event endpoint
Customer automation
Disabled या removed URL

Webhook credentials और tenant data कैसे सुरक्षित रखें?

हर tenant endpoint के लिए अलग signing secret रखें

Server पर high-entropy secret बनाएँ, setup में नियंत्रित तरीके से दिखाएँ और protected secret store में रखें। Exact body तथा timestamp पर documented HMAC algorithm से signature बनाएँ। थोड़े समय के overlap में rotation करें और पुष्टि के बाद पुराना secret revoke करें। Secret को endpoint URL में न डालें।

इस बिंदु के स्रोत: IETF RFC 2104: message authentication के लिए HMAC keyed-hashingGitHub Docs: webhook deliveries को validate करना

न्यूनतम event payload भेजें और delivery को tenant से बाँधें

Customer को notify करने के लिए जरूरी fields ही भेजें। पूरा record, credentials या sensitive personal data event में copy करने के बजाय stable object ID और ऐसा fetch path दें जिसके लिए customer पहले से authorized हो। Endpoint owner और event subscription tenant से जोड़ें; queued delivery चलते समय association फिर जाँचें।

इस बिंदु के स्रोत: AWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकनाOWASP Cheat Sheet: authorizationDigital Personal Data Protection Act, 2023

Retries सीमित रखें और delivery का पता चलने योग्य बनाएं

Recipient को deduplicate करने के लिए delivery ID और event ID रखें। Capped exponential backoff, maximum retry age और dead-letter या pause state बनाएँ। Administrator endpoint तुरंत disable कर सके। Retry किसी नए tenant URL या दूसरे tenant secret को चुपचाप न चुने। पूरा payload या secret log किए बिना response class और latency दर्ज करें।

इस बिंदु के स्रोत: GitHub Docs: webhooks के उपयोग की best practicesOWASP Cheat Sheet: loggingAmazon SQS Security Best Practices

SSRF और tenant isolation के कौन-से tests चलाएँ?

Address और URL parsing edge cases सुरक्षित test करें

Controlled test environment में IPv4/IPv6 loopback, private, link-local तथा metadata address, encoded hostname, alternate numeric IP, बदलते DNS answer और public/private mixed results शामिल करें। Disallowed scheme, user-info, unusual port और blocked destination की ओर redirect test करें; उन systems को probe न करें जिनके आप owner नहीं हैं।

इस बिंदु के स्रोत: OWASP Server-Side Request Forgery Prevention Cheat SheetNIST SP 800-115: सूचना सुरक्षा परीक्षण और आकलन की तकनीकी मार्गदर्शिका

Cross-tenant endpoint और secret substitution जाँचें

Tenant A और B के endpoint बनाएँ, A की delivery queue करें, फिर job के इंतजार में B का endpoint बदलें या secret rotate करें। हर attempt में persisted endpoint ID और tenant relation इस्तेमाल होना चाहिए, client URL या shared secret नहीं। Retry और dead-letter replay भी जाँचें।

इस बिंदु के स्रोत: AWS SaaS Lens: multi-tenant SaaS की विश्वसनीयता का परीक्षणAWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकना

Failure चलाकर worker capacity सुरक्षित रखें

Slow response, oversized body, connection reset, redirect loop और बार-बार server error दें। पुष्टि करें कि timeout, response limit, concurrency cap और retry budget लागू हों ताकि एक tenant का काम दूसरों को न रोके। Blocked internal destination, failure rate और endpoint churn पर alert रखें।

इस बिंदु के स्रोत: OWASP Server-Side Request Forgery Prevention Cheat SheetAmazon SQS Security Best PracticesOWASP Cheat Sheet: logging

SaaS outbound webhook सुरक्षा के सवाल

क्या customer के URL save करते समय validation करना पर्याप्त है?

नहीं। Delivery से पहले DNS बदल सकता है। Connection के समय भी destination policy लागू करें; restricted network egress को स्वतंत्र control बनाना बेहतर है।

इस बिंदु के स्रोत: OWASP Server-Side Request Forgery Prevention Cheat Sheet

क्या webhook worker customer endpoint के redirects follow करे?

केवल तब जब यह जरूरी हो और हर redirect hop को उसी scheme, address तथा egress policy से validate किया जाए। अन्यथा redirects बंद रखें ताकि public endpoint internal system तक रास्ता न बने।

इस बिंदु के स्रोत: OWASP Server-Side Request Forgery Prevention Cheat Sheet

क्या सभी tenants एक signing secret साझा करें?

नहीं। Endpoint या tenant के अलग secrets रखें ताकि एक customer दूसरे की delivery forge न कर सके। Rotation और revocation संभव हों और secret URL, logs या error message में न जाए।