flawopen.com/SSRF/Node.js fetch() और SSRF
क्या Node.js fetch() SSRF रोकता है?
नहीं। सर्वर-साइड fetch() अनुरोध सर्वर से भेजता है। कॉलर गंतव्य चुन सके तो सर्वर उन प्रणालियों तक पहुँच सकता है जहाँ कॉलर सीधे नहीं पहुँच सकता। यह बिना पता जाँचे भरोसेमंद कुरियर से सामान भेजने जैसा है। जोखिम नेटवर्क, पहचान, URL नीति और redirects पर निर्भर है।
providerId जैसे उपयोगकर्ता विकल्प को ऐप में तय origin से स्थिर रूप से जोड़ें; मनमाना URL न लें।मूल कारण: सर्वर कॉलर-चुने गंतव्य पर भरोसा करता है
Node.js fetch() सामान्य HTTP client है, SSRF नीति नहीं। यह नहीं तय करता कि ऐप किन नेटवर्क तक जाए; browser CORS सर्वर की सीमा नहीं बनाता। URL parse करना पर्याप्त नहीं: अनुमत hostname निषिद्ध IP पर resolve हो सकता है और उत्तर दूसरे host पर redirect कर सकता है। उपयोगकर्ता के avatar, webhook, दस्तावेज़ या preview लाने वाली सुविधा ऐसा जोखिम बना सकती है।
अनुरोध भरोसा-सीमा कैसे पार करता है
कॉलर URL को प्रभावित करता है
Endpoint पूरा URL या उसे बनाने का डेटा लेता है, जैसे image preview का पता।
सर्वर अनुरोध भेजता है
HTTP client सर्वर प्रक्रिया का network route, DNS, proxy और पहचान उपयोग करता है।
Redirect गंतव्य बदलता है
Fetch डिफ़ॉल्ट रूप से redirect मानता है। शुरुआती अनुमत host Location में प्रतिबंधित host दे सकता है।
उत्तर पहुँच योग्य डेटा खोल सकता है
नेटवर्क व नीति अनुमति दें तो आंतरिक सेवा या 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 रोकथाम जाँच-सूची
- ✓मनमाने URL की जगह सत्यापित provider key को ऐप-नियंत्रित तय गंतव्य से जोड़ें।
- ✓केवल
https:और अपेक्षित port लें; URL credentials, अनपेक्षित host, IP literal और निषिद्ध ranges रोकें। - ✓
redirect: "error"से redirects रोकें; जरूरत हो तो हर connection से पहले लक्ष्य जाँचें। - ✓सभी A/AAAA उत्तर जाँचें और hostname प्रमाणन बनाए रखते हुए connection को सत्यापित IP से बाँधें। retry और proxy पर भी यही नियम लागू करें।
- ✓IPv6 सहित loopback, private, link-local और metadata नेटवर्क को egress firewall या proxy से रोकें। केवल ऐप जाँच पर निर्भर न रहें।
- ✓समय, response bytes और concurrency सीमित करें; cookies, authorization headers या cloud credentials न भेजें।
- ✓AWS पर अतिरिक्त सुरक्षा हेतु IMDSv2 आवश्यक करें और metadata पहुँच सीमित करें; यह URL व egress नियंत्रणों का विकल्प नहीं है।
आम सवाल
नहीं। Redirect, IPv4/IPv6 रूप, DNS rebinding, proxy और resolution-connection race साधारण जाँच को पार कर सकते हैं। तय allowlist बेहतर है। मनमाने destination होने पर हर IP जाँचें, connection को उसी पर बाँधें और network egress पर भी रोकें।
नहीं। IMDSv2 token प्रक्रिया कुछ जोखिम घटाती है, पर अन्य आंतरिक सेवाएँ या अलग configured metadata फिर भी पहुँच में हो सकते हैं। गंतव्य और egress नियंत्रण जारी रखें।
प्राथमिक स्रोत
- OWASP — SSRF रोकथाम चीट शीट
- Node.js — वैश्विक fetch API
- WHATWG Fetch मानक — redirect mode
- AWS — EC2 Instance Metadata विकल्प
- CWE-918 — Server-Side Request Forgery