SaaS SSRF prevention: outbound requests और URL fetching सुरक्षित करें
Fixed destinations, strict validation, egress controls और redirect-safe clients से SaaS URL previews, imports और callbacks में server-side request forgery जोखिम घटाएँ।
इस मार्गदर्शिका में
Server-side request forgery (SSRF) क्या है?
Server-side request forgery (SSRF) तब होता है जब service को attacker द्वारा चुनी network request करने के लिए बहकाया जाता है। URL preview, image import, document conversion और custom callback जैसी सुविधाएँ अनजाने में internet-facing application को internal services या cloud metadata तक पहुँचा सकती हैं। Fixed destinations को प्राथमिकता दें; user-chosen destination सचमुच जरूरी हो तो उसे validate करें और network egress को अलग सुरक्षा परत बनाएँ।
जब product destination चुन सकती हो तो पूरी URL user से न लें
ज्ञात integration के लिए trusted configuration में provider endpoint तय करें और केवल request के लिए जरूरी business data स्वीकारें। User को partner चुनना हो तो hostname या provider identifier लें, approved list से मिलाएँ और scheme, port तथा path स्वयं बनाएँ। पूरी URL में ऐसे parsing edge cases और redirects होते हैं जिन्हें सुरक्षित रूप से validate करना कठिन है।
जरूरी schemes, hosts और ports की allowlist बनाएँ
यदि मनमानी public URLs लेना product का स्पष्ट feature है तो जरूरी protocols जैसे HTTP या HTTPS ही स्वीकारें, embedded credentials और असामान्य ports reject करें तथा maintained URL parser से hostname validate करें। साधारण string prefix या regular expression को destination की सुरक्षा का फैसला न करने दें।
Network layer पर internal और metadata networks सुरक्षित करें
URL fetch करने वाले workers से outbound connections सीमित करें ताकि वे internal control planes, private networks, loopback, link-local services या cloud metadata तक न पहुँचें—जब तक documented dependency को अलग सुरक्षा न दी गई हो। Controlled egress proxy या firewall policy लें और fetch worker को व्यापक service credentials न दें।
| Feature / destination | User का नियंत्रण | URL और DNS validation | Egress boundary / identity | Redirect और response limits |
|---|---|---|---|---|
| URL preview | ||||
| Partner callback | ||||
| File या image import |
URL validation और redirects कैसे संभालें?
Resolved addresses validate करें और DNS बदलाव का ध्यान रखें
एक hostname कई IPv4 या IPv6 addresses पर resolve हो सकता है और validation तथा connection के बीच DNS जवाब बदल सकता है। सभी resolved addresses को destination policy से जाँचें और ऐसा client या egress layer रखें जो दूसरी DNS lookup से जाँच को bypass न होने दे। Private या reserved destination अस्वीकार करें, जब तक use case में उसकी जरूरत और अलग सुरक्षा स्पष्ट न हो।
Automatic redirects बंद करें या हर hop फिर validate करें
अनुमत public URL किसी prohibited address पर redirect कर सकती है। Fetching client में automatic redirects बंद रखना सरल है। Redirect जरूरी हो तो हर नए scheme, host, port और resolved address को follow करने से पहले validate करें और hops की छोटी सीमा रखें।
अलग और सीमित fetch client इस्तेमाल करें
केवल जरूरी protocols तथा methods allow करें, connection और total timeout कम रखें, response size और content types सीमित करें तथा user के session cookies या authorization headers आगे न भेजें। Fetcher को application credentials और internal service discovery से अलग रखें। Sensitive data वाले arbitrary raw responses लौटाने की बजाय केवल processed result दें।
SaaS application में SSRF सुरक्षा कैसे test करें?
हर उस feature की inventory बनाएँ जो outbound request करती है
Webhooks, import tools, URL previews, image तथा document fetchers, PDF generation, link scanners और integrations की समीक्षा करें। देखें कि user या customer administrator host, scheme, port, path, redirect या DNS व्यवहार बदल सकता है या नहीं। Asynchronous jobs भी जाँचें; उन्हें web server से व्यापक network access मिल सकती है।
Controlled test environment में blocked destinations जाँचें
अनुमति वाले test network में सुरक्षित mock endpoints से पुष्टि करें कि disallowed address ranges, अनपेक्षित ports, schemes और redirect targets reject होते हैं। असली cloud metadata services या third-party internal networks को probe न करें। Application validation और network egress policy दोनों test करें।
Outbound व्यवहार सीमित और monitor करें
Feature, requesting tenant, approved destination और परिणाम log करें; संवेदनशील URL parameters या response body अनावश्यक रूप से न रखें। बार-बार blocked destination, असामान्य request volume और unexpected egress पर alert दें। सामान्य integrations को भी visible रखें ताकि incident responder अपेक्षित call और misuse में फर्क कर सके।
SaaS SSRF prevention के सवाल
क्या localhost block करना SSRF रोकने के लिए पर्याप्त है?
नहीं। Internal IPv4 और IPv6 ranges, link-local addresses, cloud metadata, alternate encodings, DNS बदलाव और redirects दूसरे रास्ते दे सकते हैं। सावधानी से destination validate करें और network egress controls भी रखें।
क्या HTTPS इस्तेमाल करने पर कोई भी URL लेना सुरक्षित है?
नहीं। HTTPS connection encrypt करता है, पर destination को सुरक्षित नहीं बनाता। जाँचें कि server कहाँ connect करेगा, internal destinations रोकें और fetched host को user credentials आगे न भेजें।
क्या URL previews में redirects की अनुमति दें?
केवल जरूरत हो और हर redirect target फिर validate किया जाए तभी। Automatic redirects बंद रखना सरल है; अन्यथा हर hop पर scheme, host, address और port policy लागू करें तथा hop count सीमित रखें।
क्या webhook signature SSRF रोकती है?
Signature message की authenticity या integrity verify करती है; वह यह तय नहीं करती कि server को configured destination से connect करना चाहिए या नहीं। Outbound destination अलग से validate और सीमित करें तथा inbound webhook delivery में signature जाँचें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .