FlawOpen

flawopen.com/SSRF/Node.js fetch() और SSRF

क्या Node.js fetch() SSRF रोकता है?

CWE-918: Server-Side Request ForgeryNode.js सुरक्षा संदर्भ
सरल भाषा में

नहीं। सर्वर-साइड fetch() अनुरोध सर्वर से भेजता है। कॉलर गंतव्य चुन सके तो सर्वर उन प्रणालियों तक पहुँच सकता है जहाँ कॉलर सीधे नहीं पहुँच सकता। यह बिना पता जाँचे भरोसेमंद कुरियर से सामान भेजने जैसा है। जोखिम नेटवर्क, पहचान, URL नीति और redirects पर निर्भर है।

SSRF (CWE-918)सर्वर अविश्वसनीय कॉलर द्वारा चुने या प्रभावित गंतव्य को अनुरोध भेजकर नेटवर्क भरोसा-सीमा पार करता है।
अनुमत गंतव्य सूचीproviderId जैसे उपयोगकर्ता विकल्प को ऐप में तय origin से स्थिर रूप से जोड़ें; मनमाना URL न लें।
Redirect जाँचउत्तर दूसरा गंतव्य बता सकता है। अपने-आप redirect मानने से केवल शुरुआती URL की जाँच बेकार हो सकती है।
DNS rebindingएक hostname अलग-अलग IP पर resolve हो सकता है। एक बार DNS जाँचकर HTTP client को फिर resolve करने देना TOCTOU खिड़की बनाता है।

मूल कारण: सर्वर कॉलर-चुने गंतव्य पर भरोसा करता है

Node.js fetch() सामान्य HTTP client है, SSRF नीति नहीं। यह नहीं तय करता कि ऐप किन नेटवर्क तक जाए; browser CORS सर्वर की सीमा नहीं बनाता। URL parse करना पर्याप्त नहीं: अनुमत hostname निषिद्ध IP पर resolve हो सकता है और उत्तर दूसरे host पर redirect कर सकता है। उपयोगकर्ता के avatar, webhook, दस्तावेज़ या preview लाने वाली सुविधा ऐसा जोखिम बना सकती है।

अनुरोध भरोसा-सीमा कैसे पार करता है

Step 1

कॉलर URL को प्रभावित करता है

Endpoint पूरा URL या उसे बनाने का डेटा लेता है, जैसे image preview का पता।

Step 2

सर्वर अनुरोध भेजता है

HTTP client सर्वर प्रक्रिया का network route, DNS, proxy और पहचान उपयोग करता है।

Step 3

Redirect गंतव्य बदलता है

Fetch डिफ़ॉल्ट रूप से redirect मानता है। शुरुआती अनुमत host Location में प्रतिबंधित host दे सकता है।

Step 4

उत्तर पहुँच योग्य डेटा खोल सकता है

नेटवर्क व नीति अनुमति दें तो आंतरिक सेवा या cloud metadata पहुँच में आ सकते हैं। यह हर fetch में स्वतः नहीं होता।

Node.js के जोखिमपूर्ण और सुरक्षित पैटर्न

जोखिमपूर्ण
// कॉलर द्वारा दिया मनमाना URL न लें।
const response = await fetch(userProvidedUrl);
अधिक सुरक्षित
// कॉलर केवल key चुनता है, नेटवर्क गंतव्य नहीं।
const destinations = new Map([
  ["status", new URL("https://status.example/")],
  ["docs", new URL("https://docs.example/")],
]);

const target = destinations.get(providerId);
if (!target) throw new Error("Unknown provider");

const response = await fetch(target, {
  redirect: "error",
  signal: AbortSignal.timeout(3000),
});
if (!response.ok) throw new Error("Upstream request failed");

यदि उपयोगकर्ता को URL देना आवश्यक हो

जहाँ संभव हो provider ID लें और अनुरोध तय destination map से बनाएँ। मनमाने public URL अनिवार्य हों तो केवल आवश्यक schemes और ports दें; user-info, loopback, private, link-local तथा निषिद्ध IPv4/IPv6 अस्वीकार करें। सभी DNS पते जाँचें और बिना दूसरी अनजाँची lookup के सत्यापित IP से जोड़ें। Redirect बंद करें या हर चरण जाँचें। 169.254.169.254 और सक्षम IPv6 metadata सहित outbound नेटवर्क रोकें। समय, response size, concurrency सीमित करें; आंतरिक credentials आगे न भेजें।

SSRF रोकथाम जाँच-सूची

आम सवाल

क्या localhost और private IP रोकना काफी है?

नहीं। Redirect, IPv4/IPv6 रूप, DNS rebinding, proxy और resolution-connection race साधारण जाँच को पार कर सकते हैं। तय allowlist बेहतर है। मनमाने destination होने पर हर IP जाँचें, connection को उसी पर बाँधें और network egress पर भी रोकें।

क्या IMDSv2 लागू करने से SSRF खत्म होती है?

नहीं। IMDSv2 token प्रक्रिया कुछ जोखिम घटाती है, पर अन्य आंतरिक सेवाएँ या अलग configured metadata फिर भी पहुँच में हो सकते हैं। गंतव्य और egress नियंत्रण जारी रखें।

प्राथमिक स्रोत

संबंधित सुरक्षा विषय और घटना विश्लेषण देखें:पूरा सुरक्षा निर्देशिका →
यह भी देखें सर्वर-साइड रिक्वेस्ट फ़ॉर्जरी (SSRF, CWE-918): यह कैसे काम करता है और हर भाषा में इससे कैसे बचें — flawopen.com SSRF और क्लाउड मेटाडेटा: जोखिम और बचाव AI PR बॉट: SSRF से सुरक्षा — flawopen.com