SSRF چیست و در سطح پروتکل چه اتفاقی می‌افتد؟
جعل درخواست سمت سرور (Server-Side Request Forgery) زمانی رخ می‌دهد که برنامه یک آدرس یا نام میزبان را از ورودی کاربر می‌گیرد و بدون کنترل کافی، خودِ سرور به آن آدرس درخواست می‌زند. مهاجم به‌جای اینکه مستقیماً به یک منبع داخلی دست بزند — که فایروال جلوی او را می‌گیرد — سرورِ قابل‌اعتمادِ برنامه را بهعنوان واسطه به کار می‌گیرد. سرور از درون شبکه است، پس به منابعی می‌رسد که برای مهاجمِ بیرونی نامرئی‌اند: سرویس‌های داخلی روی 127.0.0.1، رنج‌های خصوصی مثل 10.0.0.0/8، پنل‌های مدیریتی بی‌احراز هویت، و اندپوینت متادیتای ابری.
معمول‌ترین نقطه‌ی بروز، قابلیت‌هایی است که «یک URL بده تا برایت بیاورم» انجام می‌دهند: دریافت تصویر از روی لینک، وب‌هوک، تبدیل HTML به PDF، پیش‌نمایش لینک، وارد کردن فید RSS، و پروکسی‌های داخلی. اهمیت SSRF در همین است که مرز اعتماد شبکه را دور می‌زند؛ به همین دلیل هم در کنترل دسترسی شکسته طبقهبندی میشود.
انواع SSRF: معمولی و کور
دو گونه‌ی اصلی وجود دارد و تفاوتشان تعیین‌کننده‌ی روش تست است:
- SSRF معمولی (Standard): پاسخِ درخواستِ داخلی به مهاجم بازتاب داده میشود. مهاجم محتوای صفحه‌ی داخلی یا خروجی متادیتا را مستقیم می‌بیند.
- SSRF کور (Blind): هیچ پاسخی به مهاجم برنمی‌گردد. وجود آسیب‌پذیری فقط از راه کانال جانبی (Out-of-Band) قابل اثبات است. یک نشانه‌ی تشخیصی مهم: اگر فقط یک درخواست DNS ببینید ولی درخواست HTTP بعدی رخ ندهد، معمولاً یعنی برنامه نام را resolve کرده اما خروجی HTTP در سطح شبکه مسدود بوده است.
SSRF کور بی‌خطرتر نیست؛ فقط سخت‌تر کشف میشود. بسیاری از زنجیره‌های سرقت اعتبارنامه‌ی ابری از دل SSRF کور شروع شده‌اند.
هدف‌های داخلی و متادیتای ابری
پرارزش‌ترین هدف SSRF در محیط ابری، سرویس متادیتای نمونه (Instance Metadata Service) است:
- AWS EC2:
http://169.254.169.254/latest/meta-data/و روی نمونه‌های Nitro آدرس IPv6 آن[fd00:ec2::254]. - GCP:
http://metadata.google.internal/که هدرMetadata-Flavor: Googleمی‌خواهد. - Azure: که هدر
Metadata: trueلازم دارد.
«SSRF روی AWS یعنی گرفتنِ آنی اعتبارنامه‌ی IAM.» این جمله دیگر پیش‌فرض درستی نیست. IMDSv2 اول یک توکن نشست می‌خواهد که فقط با درخواست PUT به /latest/api/token گرفته میشود؛ اکثر ابزارهای SSRF فقط GET می‌زنند. سپس هر GET باید هدر سفارشی X-aws-ec2-metadata-token را حمل کند وگرنه پاسخ 401 است، و پاسخِ PUT به‌صورت پیش‌فرض محدودیت hop برابر ۱ دارد. Amazon Linux 2023 از مارس ۲۰۲۳، لانچ‌های Console Quick Start از نوامبر ۲۰۲۳، و انواع نمونه‌های تازه‌عرضه‌شده از میانه‌ی ۲۰۲۴ به‌صورت پیش‌فرض فقط IMDSv2 هستند. IMDSv1 هنوز ممکن است، اما فرض درست این است: «بررسی کن IMDSv1 فعال است یا نه»، نه «SSRF یعنی اعتبارنامه‌ی تضمینی».
سناریوی واقعی
یک سامانه‌ی صدور فاکتور قابلیتی دارد که لوگوی شرکت را از روی یک URL دریافت و در PDF جاسازی میکند. کاربر می‌تواند آدرس لوگو را وارد کند. مهاجم به‌جای آدرس تصویر، آدرس http://169.254.169.254/latest/meta-data/iam/security-credentials/ را وارد میکند. سرور آن را دریافت میکند و اگر نمونه روی IMDSv1 مانده باشد، نام نقش و سپس اعتبارنامه‌ی موقت IAM در PDF ظاهر میشود. اگر روی IMDSv2 باشد، همان درخواست با 401 شکست می‌خورد و مهاجم باید سراغ اهداف داخلی دیگر (پنل‌های مدیریتی، Redis بی‌رمز) برود. همین تفاوت، مرز بین یک یافته‌ی بحرانی و یک یافته‌ی متوسط است.
چگونه در تست نفوذ کشف میشود
هر پارامتری که آدرس، نام میزبان یا مسیر می‌گیرد کاندید است. روال کاری:
- هر ورودی مشکوک را با یک دامنهی OAST مثل Burp Collaborator جایگزین کنید و منتظر تعامل DNS/HTTP بمانید — این تنها روش قابل‌اتکا برای SSRF کور است.
- آدرس‌های داخلی و متادیتا را با کدگذاریهای جایگزین امتحان کنید تا فیلترها را بسنجید.
- زنجیرهی ریدایرکت را آزمایش کنید: میزبان مجاز که به هدف داخلی ۳۰۲ می‌دهد.
- رفتار خطا را رصد کنید؛ اختلاف زمان پاسخ بین یک IP باز و بسته اغلب وجود SSRF کور را لو می‌دهد.
ابزار محوری اینجا Burp Suite با Collaborator است. برای اطلاعات بیشتر درباره‌ی روش کلی، راهنمای تست نفوذ وب را ببینید.
نمونه‌ی فنی
یک درخواست ساده که پارامتر url را به هدف داخلی می‌برد:
POST /api/fetch-preview HTTP/1.1
Host: app.example.com
Content-Type: application/json
{"url": "http://169.254.169.254/latest/meta-data/"}و نمونه‌ای از دور زدن فیلترِ ساده با کدگذاریهای جایگزینِ 127.0.0.1:
http://127.1/
http://2130706433/ (decimal)
http://0x7f000001/ (hex)
http://[::ffff:127.0.0.1]/ارتباط با OWASP و CWE
مهم‌ترین تغییر ۲۰۲۵ همین‌جاست: SSRF دیگر دستهی مستقل نیست. در OWASP Top 10:2021 این آسیب‌پذیری دستهی مستقل A10 بود، اما در OWASP Top 10:2025 شناسهی CWE-918 در دل A01:2025 کنترل دسترسی شکسته ادغام شده است. صفحه‌ی رسمی A01 صراحتاً می‌گوید SSRF زیر این دسته رفته است. با این حال یک ناسازگاری تاکسونومی باقی است: در راهنمای تست OWASP (WSTG) آزمون SSRF هنوز زیر بخش اعتبارسنجی ورودی قرار دارد. در CWE Top 25 سال ۲۰۲۵، شناسهی CWE-918 در رتبه‌ی ۲۲ است.
پرسش‌های متداول
آیا SSRF از OWASP Top 10 حذف شده است؟
بهعنوان دستهی مستقل بله. در نسخهی ۲۰۲۵ شناسهی CWE-918 داخل A01 کنترل دسترسی شکسته ادغام شده است. این یعنی جای طبقهبندی عوض شده، نه اینکه اهمیت فنی SSRF کم شده باشد.
چرا مسدود کردن 169.254.169.254 برای جلوگیری از SSRF کافی نیست؟
چون فهرست سیاهِ IP بهسادگی دور زده میشود: کدگذاریهای دهدهی و شانزدهشانزدهی، فرم کوتاهشده مثل 127.1، دامنهای که مهاجم آن را به آدرس داخلی resolve میکند، DNS rebinding، زنجیرهی ریدایرکت و آدرس IPv6 متادیتا ([fd00:ec2::254]). راه درست فهرست سفید و اتصال به IP از پیش resolveشده است.
SSRF کور را چطور میشود اثبات کرد؟
با کانال جانبی. یک دامنهی OAST (مثل Burp Collaborator) بسازید، آن را در پارامتر تزریق کنید و منتظر تعامل DNS یا HTTP بمانید. اگر فقط جستجوی DNS دیدید ولی درخواست HTTP نیامد، معمولاً یعنی خروجی HTTP در سطح شبکه بسته است.
آیا IMDSv2 جلوی همه‌ی حملات SSRF ابری را می‌گیرد؟
خیر، اما سرقت آنیِ اعتبارنامه از راه یک GET ساده را بسیار سخت‌تر میکند. IMDSv2 هنوز اهداف داخلی دیگر (سرویس‌های بی‌احراز هویت، پایگاه‌داده‌های باز) را محافظت نمی‌کند؛ دفاع کامل نیازمند فهرست سفید و کنترل خروجی است.