چگونه از Server Side Request Forgery جلوگیری کنیم؟ معرفی حملات SSRF و انواع آن

چگونه از Server Side Request Forgery جلوگیری کنیم؟ معرفی حملات SSRF و انواع آن

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

SSRF چیست؟

 Server-Side Request Forgeryیک آسیب‌پذیری امنیتی در برنامه‌های وب است که به مهاجمان امکان می‌دهد از طریق سرور قربانی، درخواست‌های غیرمجاز به منابع داخلی یا خارجی ارسال کنند. در این حمله مهاجم سرور را فریب می‌دهد تا درخواست‌هایی را به آدرس‌های دلخواه ارسال کند که این درخواست‌ها می‌توانند شامل خواندن داده‌های حساس، اجرای دستورات خاص یا برقراری ارتباط با سیستم‌های داخلی باشد که معمولاً از دسترس کاربران خارجی خارج هستند. این آسیب‌پذیری اغلب در برنامه‌هایی که ورودی‌های کاربر را برای انجام درخواست‌های HTTP پردازش می‌کنند، مانند APIها، وب‌هوک‌ها و سیستم‌های دانلود فایل مشاهده می‌شود.

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

SSRF چیست؟

حملات SSRF چه تأثیری دارند؟

حملات SSRF می‌توانند منجر به افشای اطلاعات حساس، دور زدن محدودیت‌های امنیتی و حتی اجرای حملات پیشرفته‌تر مانند RCE (اجرای کد از راه دور) شوند. این حملات به مهاجمان امکان می‌دهند تا به منابع داخلی که معمولاً از دسترس کاربران خارجی خارج هستند، دسترسی پیدا کنند و از طریق آن‌ها داده‌های حساس مانند اطلاعات احراز هویت، تنظیمات سرورها یا پایگاه‌های داده را استخراج کنند. مهاجمان حتی می‌توانند از سرور قربانی به‌عنوان یک واسطه برای حمله به سایر سیستم‌ها استفاده کنند و بدین ترتیب شناسایی و ردیابی خود را دشوارتر کنند.

SSRF چگونه کار می‌کند؟

۱. دریافت ورودی کنترل‌نشده از کاربر

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

۲. ارسال درخواست از سمت سرور

پس از دریافت ورودی، سرور برای انجام وظیفه خود (مثلاً دانلود فایل یا دریافت داده) یک درخواست HTTP یا شبکه‌ای ارسال می‌کند. نکته مهم این است که این درخواست با سطح دسترسی و اعتبار خود سرور انجام می‌شود، نه کاربر و همین موضوع SSRF را بسیار خطرناک می‌کند.

۳. دسترسی به منابع داخلی یا حساس

مهاجم با دستکاری ورودی می‌تواند سرور را مجبور کند به منابعی مانند شبکه داخلی، دیتابیس‌ها، سرویس‌های مدیریت، یا آدرس‌های لوکال مانند localhost یا 127.0.0.1 درخواست ارسال کند. این منابع معمولاً از بیرون قابل دسترسی نیستند اما برای سرور مجاز هستند.

۴. دریافت پاسخ و سوءاستفاده از اطلاعات

در برخی موارد پاسخ درخواست مستقیماً به مهاجم نمایش داده می‌شود که به آن SSRF مستقیم گفته می‌شود. در حالت‌های پیشرفته‌تر مانند Blind SSRF، مهاجم با تحلیل رفتار سرور یا درخواست‌های جانبی، وجود آسیب پذیری و اطلاعات داخلی را تشخیص می‌دهد.

دریافت پاسخ و سوءاستفاده از اطلاعات

انواع حملات SSRF

Basic SSRF (حمله SSRF ساده)

در نوع ساده یا Basic SSRF مهاجم از قابلیتی در برنامه استفاده می‌کند که به او اجازه می‌دهد آدرسی را وارد کرده و سرور از طرف او درخواست ارسال کند. برای مثال، اگر یک وب‌سایت امکان بارگذاری تصویر از طریق وارد کردن URL را داشته باشد، مهاجم می‌تواند به‌جای آدرس تصویر، یک آدرس داخلی یا مقصد مخرب وارد کند. در این حالت سرور به اشتباه تصور می‌کند در حال انجام یک وظیفه عادی است، اما درواقع درخواست مخرب به مقصدی غیرمجاز ارسال شده است.

Blind SSRF (حمله SSRF غیرمستقیم)

در حملات Blind SSRF پاسخ سرور به درخواست مخرب مستقیماً به مهاجم نمایش داده نمی‌شود. مهاجم باید با مشاهده رفتار غیرمستقیم سیستم (مانند تاخیر در پاسخ یا تغییر وضعیت سرویس) متوجه وجود آسیب پذیری شود. این نوع حمله معمولاً پیچیده‌تر است و برای شناسایی آن از ابزارهایی مانند Burp Collaborator یا DNS Logger استفاده می‌شود تا وجود درخواست‌های شبکه از سمت سرور تأیید گردد.

SSRF به شبکه داخلی (Internal SSRF)

در این نوع حمله هدف SSRF ایجاد دسترسی غیرمجاز به منابع داخلی شبکه (Internal Services) است. از آنجا که بسیاری از سرویس‌های داخلی فایروال یا احراز هویت خارجی ندارند، مهاجم می‌تواند از طریق SSRF آن‌ها را شناسایی کرده، اطلاعات از آن‌ها استخراج کند یا حتی دستورات مدیریتی ارسال نماید. این نوع حمله یکی از خطرناک‌ترین انواع SSRF به‌ویژه در سازمان‌هایی است که از ساختار شبکه خصوصی استفاده می‌کنند.

SSRF به شبکه داخلی (Internal SSRF)

SSRF با انتقال داده‌ها (Data Exfiltration)

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

SSRF در سرویس‌های Cloud یا API

در فضای Cloud و APIها، SSRF به مراتب خطرناک‌تر می‌شود زیرا سرور ممکن است به متادیتا و اطلاعات حساس سرویس‌دهنده ابری (مانند AWS, GCP یا Azure) دسترسی مستقیم داشته باشد. در چنین شرایطی، مهاجم می‌تواند با یک درخواست SSRF، توکن‌های دسترسی (Access Tokens) یا کلیدهای API را به‌دست آورد و کنترل سرویس ابری را در دست بگیرد. این نوع حملات در سال‌های اخیر در گزارش‌های امنیتی متعدد (از جمله حملات AWS EC2 Metadata) مشاهده شده است.

مشکلات و پیامدهای SSRF

  • افشای اطلاعات حساس سرور
  • دسترسی غیرمجاز به شبکه داخلی
  • دور زدن فایروال‌ها و کنترل‌های امنیتی
  • سرقت توکن‌ها و کلیدهای دسترسی
  • نفوذ به سرویس‌های ابری (Cloud Compromise)
  • اجرای حملات زنجیره‌ای (Pivoting)
  • افزایش سطح دسترسی مهاجم (Privilege Escalation)

مثال عملی از حمله SSRF

1.یافتن نقطه آسیب‌پذیر

مهاجم ابتدا یک صفحه وب را که امکان دریافت یک URL و فچ کردن (fetch) محتوا از آن را دارد، شناسایی می‌کند. برای مثال، فرض کنید یک API در سرور وجود دارد که درخواست‌های زیر را می‌پذیرد:

				
					POST /fetch-image HTTP/1.1  
Host: example.com  
Content-Type: application/json  
{
"url": "http://example.com/profile.jpg"
}

				
			

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

۲. ارسال درخواست مخرب

مهاجم به جای ارسال یک لینک معتبر، یک URL داخلی را که معمولاً در دسترس کاربران خارجی نیست، ارسال می‌کند. برای مثال: 

				
					{
"url": "http://localhost:8080/admin"
}
				
			

اگر سرور این درخواست را بدون بررسی بپذیرد، می‌تواند به صفحات داخلی (مانند داشبورد مدیریتی) یا منابع حساس سرور دسترسی پیدا کند.

۳. استخراج اطلاعات داخلی

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

۴. اجرای حملات پیشرفته‌تر

مهاجم ممکن است از این روش برای: 

  • اسکن شبکه داخلی و شناسایی سرویس‌های داخلی
  • دسترسی به سرویس‌های داخلی مثل Redis یا AWS metadata
  • اجرای دستورات بر روی سرور آسیب‌پذیر (در صورت امکان)

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

اعتبارسنجی و محدودسازی ورودی URL

مهم‌ترین اقدام برای جلوگیری از SSRF اعتبارسنجی دقیق ورودی‌هایی است که شامل URL، IP یا hostname می‌شوند. باید تنها پروتکل‌های مجاز (مانند https) و دامنه‌های مشخص‌شده در لیست سفید (Allowlist) پذیرفته شوند و هرگونه ورودی مشکوک یا غیرمنتظره رد گردد. استفاده از لیست سیاه به‌تنهایی کافی نیست و معمولاً قابل دور زدن است.

استفاده از Allowlist به‌جای Blocklist

در طراحی امن به‌جای مسدود کردن آدرس‌های خطرناک، بهتر است تنها مقصدهای کاملاً شناخته‌شده و مورد اعتماد مجاز باشند. این روش احتمال دور زدن کنترل‌ها از طریق IPهای لوکال، DNS Rebinding یا آدرس‌های رمزگذاری‌شده را به‌شدت کاهش می‌دهد و یکی از مؤثرترین راهکارهای دفاعی در برابر SSRF محسوب می‌شود.

استفاده از Allowlist به‌جای Blocklist

جلوگیری از دسترسی به IPهای داخلی و لوکال

سرور نباید اجازه ارسال درخواست به آدرس‌هایی مانند 127.0.0.1، localhost، 169.254.169.254 یا رنج‌های خصوصی شبکه را داشته باشد. این کار می‌تواند از طریق بررسی IP نهایی پس از Resolve شدن DNS انجام شود تا از دور زدن محدودیت‌ها جلوگیری شود.

محدودسازی سطح دسترسی سرور (Least Privilege)

سرورها و سرویس‌ها باید با حداقل سطح دسترسی ممکن اجرا شوند. در صورت وقوع SSRF، محدود بودن مجوزها باعث می‌شود مهاجم نتواند به منابع حیاتی مانند دیتابیس‌ها، متادیتای Cloud یا سرویس‌های مدیریتی دسترسی پیدا کند و اثر حمله کاهش یابد.

جداسازی شبکه داخلی و سرویس‌های حساس

تقسیم‌بندی شبکه (Network Segmentation) باعث می‌شود حتی اگر SSRF رخ دهد، سرور نتواند به همه بخش‌های شبکه داخلی دسترسی داشته باشد. این روش یکی از اصول کلیدی امنیت زیرساخت است و نقش مهمی در مهار حملات SSRF دارد.

بخش بندی شبکه چست؟ چگونه Network Segmentation را در شبکه پیاده سازی کنیم؟

استفاده از فایروال و فیلترهای خروجی (Egress Filtering)

با اعمال محدودیت روی ترافیک خروجی سرور، می‌توان از ارسال درخواست به مقاصد غیرمجاز جلوگیری کرد. این کنترل به‌ویژه در محیط‌های Cloud و میکروسرویس‌ها بسیار حیاتی است و احتمال سوءاستفاده از SSRF را کاهش می‌دهد.

استفاده از فایروال و فیلترهای خروجی (Egress Filtering)

مانیتورینگ و لاگ‌برداری از درخواست‌های غیرعادی

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

چند نمونه واقعی از حمله SSRF

۱. حمله SSRF به AWS EC2 Metadata Service

یکی از معروف‌ترین نمونه‌های SSRF مربوط به سوءاستفاده از سرویس متادیتای AWS EC2 است. مهاجمان با ارسال درخواست SSRF به آدرس 169.254.169.254 توانستند توکن‌ها و کلیدهای دسترسی AWS را استخراج کرده و کنترل منابع ابری قربانی را در اختیار بگیرند. این حملات باعث شد AWS نسخه‌های امن‌تر متادیتا (IMDSv2) را معرفی کند.

حمله SSRF به AWS EC2 Metadata Service

۲. آسیب پذیری SSRF در GitHub (2016)

در سال ۲۰۱۶ یک آسیب پذیری SSRF در GitHub کشف شد که به مهاجمان اجازه می‌داد به سرویس‌های داخلی GitHub دسترسی پیدا کنند. این ضعف می‌توانست منجر به افشای اطلاعات داخلی شود، اما قبل از سوءاستفاده گسترده، توسط تیم امنیتی GitHub شناسایی و برطرف شد.

آسیب پذیری SSRF در GitHub (2016)

۳. حمله SSRF در Google Cloud Platform

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

حمله SSRF در Google Cloud Platform

گوگل کلود (Google Cloud) چیست؟ استفاده از GCP چه مزایایی دارد؟

۴. آسیب پذیری SSRF در Shopify

Shopify نیز در گذشته با گزارش‌هایی از SSRF مواجه شد که امکان دسترسی به سرویس‌های داخلی و اطلاعات پیکربندی را فراهم می‌کرد. این موارد از طریق برنامه‌های جانبی و APIها رخ داد و نقش اعتبارسنجی ورودی‌ها را در محیط‌های API‑محور برجسته کرد.

آسیب پذیری SSRF در Shopify

جمع‌بندی…

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

سوالات متداول

۱. SSRF چیست و چرا خطرناک است؟

SSRF نوعی آسیب پذیری است که در آن سرور فریب می‌خورد تا درخواست‌هایی را به مقصدهای ناخواسته ارسال کند و می‌تواند منجر به افشای اطلاعات و نفوذ داخلی شود.

۲. تفاوت SSRF با CSRF چیست؟

در SSRF سرور قربانی می‌شود و درخواست را ارسال می‌کند، اما در CSRF مرورگر کاربر قربانی است و درخواست جعلی از سمت کاربر ارسال می‌شود.

حمله CSRF چیست و چگونه با آن مقابله کنیم؟

۳. SSRF بیشتر در چه بخش‌هایی از برنامه رخ می‌دهد؟

بیشتر در APIها، سرویس‌های بارگذاری فایل، پردازش URL، Webhookها و میکروسرویس‌ها مشاهده می‌شود.

۴. Blind SSRF چگونه شناسایی می‌شود؟

از طریق مانیتورینگ رفتار سرور، لاگ‌های DNS، تاخیر پاسخ‌ها و ابزارهایی مانند Burp Collaborator.

۵. چرا SSRF در محیط‌های Cloud خطرناک‌تر است؟

زیرا سرور به متادیتا و توکن‌های دسترسی Cloud دسترسی دارد و در صورت SSRF ممکن است کل زیرساخت به خطر بیفتد.

۶. آیا فایروال به‌تنهایی جلوی SSRF را می‌گیرد؟

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

7. آیا SSRF فقط در وب‌اپلیکیشن‌ها رخ می‌دهد؟

خیر، هر سرویسی که از سمت سرور درخواست شبکه‌ای ارسال کند، می‌تواند در معرض SSRF باشد.

موارد اخیر

برترین ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دیدگاه