حمله SSRF چیست؟ و اهمیت آن در امنیت وب

مرسده رفیعی

فروردین 18, 1405

در دنیای امروز که سرویس‌های وب، APIها و معماری‌های مبتنی بر میکروسرویس به سرعت در حال گسترش هستند، حملات سمت سرور اهمیت بیشتری پیدا کرده‌اند.

یکی از خطرناک‌ترین این حملات، SSRF یا Server-Side Request Forgery است؛ حمله‌ای که به مهاجم اجازه می‌دهد از طریق سرور قربانی، درخواست‌هایی را به منابع داخلی یا خارجی ارسال کند. این حمله در سال‌های اخیر بارها باعث افشای اطلاعات، دسترسی غیرمجاز و حتی نفوذ کامل به زیرساخت شرکت‌های بزرگ شده است.

SSRF در لیست OWASP Top 10 قرار دارد و توسعه‌دهندگان باید آن را جدی بگیرند، زیرا اغلب از ورودی‌های کاربر مانند URLها سوءاستفاده می‌کند.

با افزایش استفاده از سرویس‌های ابری مانند AWS، حملات SSRF در سال 2026 بیش از 100 هزار مورد گزارش شده و کسب‌وکارها را تهدید می‌کند. در این مقاله، به بررسی حمله SSRF چیست؟ و اهمیت آن در امنیت وب، انواع آن و روش‌های نوین پیشگیری می‌پردازیم.

حمله SSRF چیست؟

حمله SSRF مخفف Server-Side Request Forgery (جعل درخواست سمت سرور) است. در این حمله، مهاجم سرور وب را مجبور می‌کند تا از طرف خود، درخواستی را به یک مقصد غیرمجاز ارسال کند. این درخواست می‌تواند به:

منابع داخلی شبکه (Internal Network)
سرویس‌های لوکال مثل 127.0.0.1
سرویس‌های ابری (Metadata Services)
APIهای حساس
فایل‌های داخلی سرور

ارسال شود.

حمله SSRF از اوایل دهه 2010 شناسایی شد، اما با رشد کلاد و میکروسرویس‌ها، شدت آن افزایش یافته است. در سال 2025، OWASP آن را به عنوان A10 در Top 10 قرار داد، زیرا مهاجمان از آن برای دسترسی به metadata سرورهای ابری مانند http://169.254.169.254 استفاده می‌کنند.

از آنجایی که سرورها معمولاً به شبکه‌های داخلی یا سرویس‌های خاصی دسترسی دارند که از اینترنت عمومی مخفی هستند، مهاجم با سوءاستفاده از اعتماد میان سرورها، به داده‌های حساس دسترسی پیدا می‌کند.

این آسیب‌پذیری می‌تواند به RCE (Remote Code Execution) منجر شود، به‌خصوص اگر با open redirection ترکیب شود.

مکانیسم عملکرد SSRF چگونه است؟

آسیب‌پذیری SSRF زمانی رخ می‌دهد که یک اپلیکیشن تحت وب، داده‌ها را از یک URL خارجی دریافت می‌کند (مانند آپلود عکس پروفایل از لینک، دریافت پیش‌نمایش سایت یا کار با وب‌هوک‌ها) اما ورودی کاربر را پیش از پردازش، اعتبارسنجی نمی‌کند.

در این حالت، اگر برنامه‌نویس ورودی کاربر را مستقیماً در توابعی مثل cURL در PHP یا fetch در JavaScript قرار دهد، مهاجم می‌تواند به جای آدرس مجاز، آدرس‌های حساس داخلی را جایگزین کند.

مثال ساده:

فرض کنید یک API دارید:

GET /fetch?url=https://example.com/image.jpg

اگر ورودی کنترل نشود، مهاجم می‌تواند بنویسد:

/fetch?url=http://127.0.0.1:8080/admin

و سرور به پنل ادمین داخلی درخواست می‌زند.

چه سرویس‌هایی بیشتر در معرض حمله SSRF هستند؟

سرویس‌های تبدیل محتوا: مانند تبدیل لینک وب‌سایت به فایل PDF یا تصویر (Screenshot services).
سیستم‌های ایمپورت داده: که فایل‌ها را از طریق URL از سرورهای دیگر دریافت می‌کنند.
وب‌هوک‌ها (Webhooks): که درخواست‌های HTTP را به آدرس‌های تعریف شده توسط کاربر ارسال می‌کنند.
APIهای شخص ثالث: زمانی که سرور برای دریافت اطلاعات از یک API خارجی، از ورودی کاربر استفاده می‌کند.

انواع حمله SSRF:

این حمله بر اساس نحوه پاسخ سرور به سه دسته زیر تقسیم می شود:

1. Basic SSRF (SSRF معمولی)

Basic SSRF یا SSRF معمولی (که گاهی به آن In-band SSRF نیز می‌گویند) ساده‌ترین و در عین حال خطرناک‌ترین نوع این آسیب‌پذیری است. ویژگی کلیدی این نوع حمله این است که پاسخ درخواستی که سرور به مقصد غیرمجاز ارسال کرده، مستقیماً به مهاجم بازگردانده می‌شود.

در واقع، مهاجم نه تنها می‌تواند سرور را مجبور به ارسال درخواست کند، بلکه نتیجه آن را هم روی صفحه نمایش خود می‌بیند.

تفاوت اصلی این مدل با نوع Blind (کور) در این است که مهاجم نیازی به حدس زدن ندارد. او دقیقاً می‌بیند که آیا پورت باز است یا خیر، محتوای فایل چیست و ساختار پاسخ‌های API داخلی به چه صورت است. این موضوع سرعت اکسپلویت (بهره‌برداری) را به شدت بالا می‌برد.

در مقابله با Basic SSRF، علاوه بر محدود کردن IPها، غیرفعال کردن پروتکل‌های غیرضروری (مثل file:// یا gopher://) در کتابخانه‌هایی مثل cURL بسیار حیاتی است.

2. Blind SSRF (SSRF کور)

Blind SSRF یا SSRF کور زمانی رخ می‌دهد که مهاجم می‌تواند سرور را مجبور به ارسال درخواست به یک مقصد غیرمجاز کند، اما پاسخ آن درخواست را مستقیماً دریافت نمی‌کند.

در این حالت، صفحه وب هیچ تغییری نمی‌کند و محتوای فایل یا سرویس داخلی در مرورگر مهاجم نمایش داده نمی‌شود. به همین دلیل به آن «کور» می‌گویند؛ زیرا مهاجم باید از روش‌های غیرمستقیم برای تایید نفوذ استفاده کند.

نفوذگر چگونه متوجه وجود Blind SSRF می‌شود؟

از آنجایی که پاسخی در کار نیست، مهاجم از تکنیک‌های Out-of-band (OOB) استفاده می‌کند. رایج‌ترین روش‌ها عبارتند از:

استفاده از DNS/HTTP Loggers:

مهاجم سرور را مجبور می‌کند تا به یک دامنه تحت کنترل خودش درخواست بزند (مثلاً http://attacker-server.com). سپس مهاجم لاگ‌های سرور خود را چک می‌کند؛ اگر درخواستی از سمت آی‌پی سرورِ قربانی ثبت شده باشد، یعنی آسیب‌پذیری SSRF وجود دارد.

ابزارهایی مانند Burp Collaborator یا interactsh دقیقاً برای همین کار طراحی شده‌اند.

تحلیل زمانی (Time-based):

مهاجم زمان پاسخ‌دهی سرور را اندازه می‌گیرد. اگر درخواست به یک پورت باز ارسال شود، سرور سریع پاسخ می‌دهد؛ اما اگر به یک پورت بسته یا آی‌پی ناموجود ارسال شود، ممکن است سرور تا زمان Timeout شدن منتظر بماند. این تفاوت زمانی نشان‌دهنده وضعیت شبکه داخلی است.

در این نوع حمله، پاسخِ درخواستِ ارسال شده به مهاجم نمایش داده نمی‌شود. نفوذگر برای تایید موفقیت حمله باید از روش‌های غیرمستقیم (Out-of-band) استفاده کند.

بسیاری از برنامه‌نویسان برای مقابله با Blind SSRF، لیستی از آی‌پی‌های ممنوعه (مثل 127.0.0.1) را بلاک می‌کنند. در حملات کور، مهاجم از DNS Rebinding استفاده می‌کند:

مهاجم دامنه‌ای را ثبت می‌کند که در اولین فراخوانی به یک آی‌پی عمومی (مجاز) اشاره می‌کند تا از سد فیلتر بگذرد.
در دومین فراخوانی (زمانی که سرور قصد دارد درخواست اصلی را ارسال کند)، مهاجم تنظیمات DNS را تغییر می‌دهد تا دامنه به 127.0.0.1 اشاره کند.
به این ترتیب، سرور فریب خورده و درخواستی را به خودش (Localhost) ارسال می‌کند.

3. Partial SSRF (SSRF محدود)

در این حالت، مهاجم پاسخ کامل را نمی‌بیند، اما می‌تواند از طریق رفتارهای جانبی سرور به اطلاعاتی دست پیدا کند.

نشانه‌ها: تفاوت در زمان پاسخ‌دهی سرور (Time-based)، کدهای وضعیت HTTP (مثلاً کد 200 برای پورت باز و 500 برای پورت بسته) یا پیام‌های خطای خاص.
کاربرد: این روش معمولاً برای Port Scanning (پویش پورت‌های داخلی شبکه) استفاده می‌شود تا مشخص گردد چه سرویس‌هایی روی شبکه داخلی فعال هستند.

در سناریوهای Partial SSRF (یا SSRF محدود)، مهاجم مستقیماً به پاسخ کامل سرور مقصد دسترسی ندارد و تنها می‌تواند از طریق نشانه‌های غیرمستقیم (مانند کدهای وضعیت HTTP، تفاوت در زمان پاسخ‌گویی یا پیام‌های خطا) به وقوع حمله پی ببرد. در چنین شرایطی، موفقیت حمله کاملاً به توانایی مهاجم در پیاده‌سازی تکنیک‌های Bypass بستگی دارد.

مهاجم با بهره‌گیری از متدهایی نظیر کدگذاری‌های خاص (Encoding)، سوءاستفاده از تفاوت در پردازش DNS (مانند DNS Rebinding) و یا دستکاری پروتکل‌ها، تلاش می‌کند تا لایه‌های اعتبارسنجی را دور زده و درخواست خود را به زیرساخت‌های حساس داخلی تحمیل کند.

در محیط‌های مدرن، Blind SSRF بسیار رایج‌تر است، زیرا برنامه‌نویسان معمولاً خروجی مستقیم توابع ارسال درخواست را به کاربر نمایش نمی‌دهند، اما همچنان اجازه می‌دهند که درخواست در پس‌زمینه (Background) اجرا شود.

روش‌های جلوگیری از SSRF:

برای جلوگیری از این آسیب‌پذیری، باید رویکرد «دفاع در عمق» را پیاده‌سازی کرد.

در ادامه، موثرترین روش‌های مقابله با SSRF آورده شده است:

1- استفاده از لیست سفید (Allowlist)

بهترین راهکار این است که به سرور اجازه ندهید به هر آدرسی متصل شود.

دامنه‌های مجاز: فقط به لیست مشخصی از دامنه‌های مورد اعتماد اجازه دسترسی بدهید.
پروتکل‌های محدود: تنها پروتکل‌های ضروری (مانند http و https) را مجاز کنید و پروتکل‌های خطرناکی مثل file:// ،gopher:// یا ftp:// را مسدود نمایید.

2- اعتبارسنجی و فیلترینگ مقصد

اگر نمی‌توانید از لیست سفید استفاده کنید، باید ورودی کاربر را به دقت کنترل کنید:

رد کردن آدرس‌های Localhost: درخواست‌ها به 127.0.0.1 یا localhost را مسدود کنید.
محدود کردن IPهای خصوصی (Private IPs): از ارسال درخواست به رنج‌های شبکه‌های داخلی جلوگیری کنید (مانند 10.0.0.0/8 یا 192.168.0.0/16).
بررسی پس از حل نام دامنه (DNS Resolution): مهاجمان ممکن است با استفاده از تکنیک DNS Rebinding فیلترها را دور بزنند. برای جلوگیری، باید IP نهایی حاصل از DNS را قبل از ارسال درخواست چک کنید.

3- امنیت در لایه شبکه (Network Layer)

امنیت نباید فقط در کد برنامه باشد؛ تنظیمات شبکه نقش حیاتی دارند:

Firewall Rules: فایروال سرور (مانند iptables) را طوری تنظیم کنید که ترافیک خروجی (Egress) به مقصدهای غیرضروری یا شبکه‌های حساس داخلی مسدود شود.
بخش‌بندی شبکه (Network Segmentation): سرورهای وب را در یک بخش مجزا قرار دهید تا حتی در صورت نفوذ، دسترسی مستقیم به سرویس‌های حساس (مثل دیتابیس یا سرویس‌های ابری) نداشته باشند.

4- غیرفعال کردن تغییر مسیر (Disable Redirects)

مهاجمان اغلب از HTTP Redirect (کدهای 301 و 302) برای دور زدن فیلترها استفاده می‌کنند. اگر برنامه شما به انتقال کاربر به آدرس دیگر نیاز ندارد، قابلیت Follow Redirect را در کتابخانه‌های HTTP (مانند cURL یا Requests) غیرفعال کنید.

5- مدیریت دسترسی به Metadata

در محیط‌های ابری (مانند AWS، Azure یا GCP)، سرویس‌های Metadata اطلاعات بسیار حساسی (مثل کلیدهای دسترسی) را روی یک IP خاص (معمولاً 169.254.169.254) ارائه می‌دهند.

دسترسی به این IP را از طریق فایروال یا تنظیمات Cloud مسدود کنید.
در AWS از نسخه جدید سرویس (IMDSv2) استفاده کنید که نیاز به Token دارد و در برابر (SSRF) Server Side Request Forgery مقاوم‌تر است.

تفاوت SSRF با CSRF:

تفاوت اصلی بین SSRF و CSRF در هدف، مکانیسم و لایه حمله است. SSRF سرور را هدف قرار می‌دهد، در حالی که CSRF مرورگر کاربر را فریب می‌دهد.

هدف حمله:

SSRF (Server-Side Request Forgery) سرور وب را مجبور به ارسال درخواست‌های ناخواسته به منابع داخلی یا خارجی می‌کند، مثل دسترسی به localhost یا metadata ابری.
CSRF (Cross-Site Request Forgery) کاربر احراز هویت‌شده را وادار به اجرای عملیات ناخواسته روی سایت می‌کند، بدون دسترسی مستقیم مهاجم به داده‌ها.

مکانیسم فنی:

در SSRF، مهاجم URL مخرب (مثل http://127.0.0.1) را inject می‌کند و سرور آن را پردازش می‌کند؛ حمله سمت سرور است.
CSRF از طریق لینک/فرم مخرب در سایت دیگر، کوکی‌های کاربر را برای درخواست جعلی به سایت اصلی استفاده می‌کند؛ حمله سمت کلاینت است.

ویژگی	SSRF	CSRF
هدف	سرور	کاربر
محل اجرا	سمت سرور	سمت مرورگر
نیاز به تعامل کاربر	ندارد	دارد
سطح خطر	بسیار بالا	متوسط تا بالا
نوع سوءاستفاده	ارسال درخواست از سرور	ارسال درخواست از کاربر
امکان دسترسی به شبکه داخلی	دارد	ندارد

بهترین ابزارها برای اسکن SSRF:

بهترین ابزارها برای اسکن حمله SSRF شامل ترکیبی از اسکنرهای خودکار و پروکسی‌های دستی هستند که به طور خاص برای شناسایی آسیب‌پذیری‌های Server-Side Request Forgery طراحی شده‌اند.