حمله SSRF چیست؟ بررسی Server-Side Request Forgery و روش‌های جلوگیری

حمله SSRF یا Server-Side Request Forgery زمانی رخ می‌دهد که یک برنامه وب، API یا سرویس Backend تحت تأثیر ورودی کاربر، از طرف خود سرور به مقصدی ناخواسته درخواست شبکه ارسال کند. خطر اصلی SSRF این است که سرور معمولاً به شبکه داخلی، APIهای خصوصی، سرویس‌های Cloud و منابعی دسترسی دارد که کاربر اینترنتی مستقیماً نمی‌تواند به آن‌ها متصل شود. مهم‌ترین راهکارهای جلوگیری از SSRF شامل محدودکردن مقصدها با Allowlist، اعتبارسنجی دقیق URL و DNS، کنترل Redirect، محدودسازی Egress Traffic و اصل Least Privilege است.

مقدمه؛ وقتی مهاجم مستقیماً حمله نمی‌کند و سرور این کار را برای او انجام می‌دهد

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

معمولاً این منابع مستقیماً روی اینترنت قرار ندارند. Firewall، Network ACL، Reverse Proxy، VPN، Private Subnet و سایر کنترل‌های امنیت شبکه دسترسی مستقیم کاربران اینترنتی را محدود می‌کنند.

اما حمله SSRF مدل متفاوتی دارد.

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

در نتیجه مسیر ارتباط ممکن است از این حالت:

کاربر → سرویس مجاز

به این حالت تبدیل شود:

کاربر → برنامه آسیب‌پذیر → سرویس داخلی

در واقع مهاجم سعی می‌کند از اعتماد و دسترسی شبکه‌ای خود سرور استفاده کند.

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

MITRE نیز این ضعف را با شناسه CWE-918: Server-Side Request Forgery ثبت کرده است. تعریف CWE-918 بر شرایطی تمرکز دارد که نرم‌افزار یک URL یا مقصد مشابه را دریافت می‌کند اما به اندازه کافی اطمینان حاصل نمی‌کند درخواست واقعاً به Destination مورد انتظار فرستاده می‌شود.

از نظر دسته‌بندی OWASP نیز باید به یک تغییر مهم توجه کرد. SSRF در OWASP Top 10:2021 یک دسته مستقل با عنوان A10 بود، اما در OWASP Top 10:2025 دیگر یک دسته مستقل نیست و CWE-918 در دسته A01:2025 Broken Access Control قرار گرفته است. خود OWASP نیز اعلام کرده SSRF در نسخه 2025 در این دسته ادغام شده است.

این تغییر طبقه‌بندی نباید باعث شود مدیران سایت یا توسعه‌دهندگان SSRF را کم‌اهمیت تلقی کنند. در معماری‌های امروزی که از Cloud، Microservices، APIهای داخلی، Containerها و شبکه‌های Private استفاده می‌شود، یک SSRF می‌تواند دامنه اثر بسیار بالایی داشته باشد.

در این مقاله رخنه‌کاو، حمله SSRF را از دید آموزشی و دفاعی بررسی می‌کنیم؛ از نحوه شکل‌گیری این آسیب‌پذیری گرفته تا تفاوت آن با CSRF، ریسک‌های Cloud، DNS، Redirect، Allowlist، Egress Filtering، امنیت WordPress، Monitoring و معماری پیشنهادی برای جلوگیری از Server-Side Request Forgery.

حمله SSRF چیست؟

SSRF مخفف عبارت Server-Side Request Forgery است.

در یک برنامه معمولی، Server ممکن است به دلایل کاملاً قانونی نیاز داشته باشد از سرویس دیگری اطلاعات دریافت کند.

برای مثال سایت می‌تواند:

• تصویر کاربر را از یک URL خارجی دریافت کند؛
• یک Webhook ارسال کند؛
• وضعیت یک URL را بررسی کند؛
• از API سرویس دیگری اطلاعات بگیرد؛
• فایل خارجی Import کند؛
• Preview یک صفحه وب را بسازد؛
• Screenshot یک URL را تولید کند؛
• اطلاعات یک Feed را بخواند.

هیچ‌کدام از این قابلیت‌ها ذاتاً ناامن نیستند.

مشکل زمانی ایجاد می‌شود که کاربر بتواند Destination درخواست سمت Server را به شکلی خارج از Business Logic مورد انتظار کنترل کند.

برای مثال برنامه تصور می‌کند کاربر یک URL مربوط به تصویر عمومی اینترنت را وارد می‌کند، اما بررسی مناسبی انجام نمی‌دهد که مقصد نهایی Request واقعاً یک Resource عمومی و مجاز است.

در چنین شرایطی Application Server ممکن است به یک Proxy ناخواسته تبدیل شود.

مدل ساده SSRF چگونه است؟

یک جریان عادی را در نظر بگیرید:

User ↓ Web Application ↓ Trusted External API ↓ Response

اما در یک طراحی آسیب‌پذیر ممکن است جریان چنین شود:

User ↓ User-controlled Destination ↓ Web Application ↓ Unexpected Destination

مشکل در اینجا Request زدن Server نیست؛ مشکل این است که Destination درخواست به اندازه کافی تحت کنترل Policy برنامه قرار ندارد.

به همین دلیل یکی از مهم‌ترین اصول مقابله با SSRF این است:

User نباید بتواند آزادانه تعیین کند Server به چه مقصد شبکه‌ای متصل شود، مگر اینکه Business Requirement واقعاً چنین قابلیتی را نیاز داشته باشد و کنترل‌های چندلایه روی آن اجرا شوند.

چرا حمله SSRF می‌تواند بسیار خطرناک باشد؟

Serverهای Backend معمولاً نسبت به کاربران اینترنتی دسترسی بیشتری دارند.

برای مثال ممکن است یک سرور وب اجازه داشته باشد با این منابع ارتباط برقرار کند:

• API خصوصی شرکت؛
• Service Discovery؛
• پایگاه داده داخلی؛
• سامانه مانیتورینگ؛
• سرویس‌های Management؛
• Cluster داخلی؛
• Object Storage؛
• Cloud Metadata Service؛
• Microserviceهای داخلی؛
• سرویس‌های Localhost.

اما یک کاربر معمولی اینترنتی به این Resourceها دسترسی مستقیم ندارد.

از نظر معماری، ممکن است Firewall چنین Policy داشته باشد:

Internet → Internal API = Block

اما:

Application Server → Internal API = Allow

اگر Application Server به SSRF آسیب‌پذیر باشد، مهاجم سعی می‌کند درخواست خود را از مسیر Application Server عبور دهد.

این وضعیت نشان می‌دهد SSRF صرفاً یک اشکال ساده در URL Validation نیست؛ بلکه می‌تواند Trust Boundary شبکه را نیز تحت تأثیر قرار دهد.

SSRF در چه قابلیت‌هایی بیشتر ایجاد می‌شود؟

هر Feature که URL، Host، Endpoint یا Destination را از User دریافت کند و سپس Server براساس آن Request بسازد، باید از نظر SSRF بررسی شود.

دریافت تصویر از URL

برخی سایت‌ها به کاربر اجازه می‌دهند به جای Upload مستقیم، آدرس یک تصویر را وارد کند.

Server سپس تصویر را دانلود می‌کند.

این قابلیت از مثال‌های کلاسیک سطح حمله SSRF است و OWASP نیز Remote Image URL را به‌عنوان یکی از مثال‌های رایج مطرح می‌کند.

Webhookهای سفارشی

در بسیاری از SaaSها کاربر می‌تواند Webhook URL تعریف کند.

زمانی که یک Event رخ می‌دهد، Server به URL ثبت‌شده Request می‌فرستد.

اگر مقصد بدون محدودیت مناسب پذیرفته شود، Feature می‌تواند SSRF Risk ایجاد کند.

URL Preview

برنامه ممکن است برای ساخت Preview لینک:

• Title؛
• Description؛
• تصویر؛
• Metadata

صفحه را از سمت Server دریافت کند.

هر URL Preview Service باید از نظر SSRF Threat Model داشته باشد.

Import from URL

CMS، فروشگاه اینترنتی، Data Importer یا Media Manager ممکن است اجازه واردکردن فایل از URL بدهد.

Screenshot Service

سرویس‌هایی که از یک Website Screenshot می‌گیرند معمولاً مجبور هستند URL را از سمت Backend باز کنند.

اگر Browser یا Renderer سمت Server بتواند آزادانه به شبکه‌های داخلی متصل شود، SSRF Risk اهمیت زیادی پیدا می‌کند.

PDF Generator

برخی PDF Generatorها یک URL را Render و تبدیل به PDF می‌کنند.

Security Boundary این نوع سرویس‌ها نیز باید مشخص باشد.

Proxy Endpoint

APIهایی که عمداً Content خارجی را Proxy می‌کنند، ذاتاً سطح حمله بیشتری دارند و باید Policy دقیق Destination داشته باشند.

Webhook Tester

قابلیت «Test Webhook» ممکن است فوراً Requestی از Backend به URL تعیین‌شده توسط User بفرستد.

Feed Reader

RSS، XML Feed، Price Feed و Remote Data Source نیز ممکن است Server-side Fetch انجام دهند.

SSRF فقط مربوط به HTTP نیست

یکی از اشتباهات رایج این است که SSRF را فقط یک مشکل HTTP بدانیم.

OWASP توضیح می‌دهد که SSRF محدود به HTTP نیست. بسته به Library، Framework و Schemeهای پشتیبانی‌شده، Request دوم ممکن است از Protocolهای دیگری نیز استفاده کند. به همین علت Policy امن باید Protocolها و Schemeهای مجاز را صراحتاً محدود کند.

در طراحی دفاعی، اگر Business فقط به HTTP و HTTPS نیاز دارد، هیچ دلیل منطقی برای اجازه‌دادن Schemeهای دیگر وجود ندارد.

اصل مهم:

Allow only what the application actually needs.

انواع SSRF

SSRF را می‌توان براساس نحوه مشاهده نتیجه Request و سطح کنترل مهاجم تقسیم‌بندی کرد.

SSRF معمولی یا In-Band SSRF

در این مدل Server به Destination درخواست می‌زند و Response یا بخشی از آن نیز به Client برگردانده می‌شود.

از نظر افشای اطلاعات، این حالت می‌تواند حساس باشد؛ زیرا User ممکن است داده‌ای را ببیند که مستقیماً برای او قابل دسترسی نبوده است.

Blind SSRF

در Blind SSRF، Server Request را ارسال می‌کند اما Response مقصد مستقیماً به User نمایش داده نمی‌شود.

Blind بودن به معنی بی‌خطر بودن نیست.

یک Request سمت سرور ممکن است همچنان:

• State یک سرویس را تغییر دهد؛
• Network Connection ایجاد کند؛
• یک عملیات داخلی را Trigger کند؛
• باعث مصرف Resource شود؛
• از طریق Logging یا Side Effect قابل مشاهده باشد.

بنابراین دفاع باید جلوی Request غیرمجاز را بگیرد، نه اینکه صرفاً Response را مخفی کند.

SSRF با کنترل محدود

گاهی User فقط بخشی از Destination را کنترل می‌کند.

مثلاً:

Host ثابت است اما Path قابل کنترل است.

یا:

Domain ثابت است اما Subdomain قابل انتخاب است.

یا:

Host قابل انتخاب است ولی Protocol ثابت است.

این محدودیت می‌تواند Risk را کاهش دهد، اما تضمین امنیت نیست. Policy باید براساس ساختار واقعی Request بررسی شود.

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

فرض کنید سازمان چنین معماری‌ای دارد:

Internet ↓ Reverse Proxy ↓ Public Web Application ↓ Private Application Network ↓ Internal API

Internal API از Internet قابل دسترس نیست.

در حالت عادی این طراحی یک Boundary امنیتی ایجاد می‌کند.

اما Public Web Application به Internal API دسترسی دارد.

اگر User بتواند Public Application را وادار کند Request دلخواه به Internal Network ارسال کند، Server تبدیل به واسطه‌ای بین دو Trust Zone می‌شود.

بنابراین SSRF اغلب ترکیبی از این دو مشکل است:

1. User-controlled Network Destination
2. Excessive Network Trust

برای همین اصلاح SSRF باید هم در Application Layer و هم در Infrastructure Layer انجام شود.

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

SSRF و CSRF فقط از نظر نام شبیه هستند.

در CSRF چه اتفاقی می‌افتد؟

در Cross-Site Request Forgery، مهاجم تلاش می‌کند مرورگر کاربر قربانی را مجبور کند Request ناخواسته‌ای به سایتی که قربانی در آن احراز هویت شده ارسال کند.

عامل ارسال Request:

Browser

است.

در SSRF چه اتفاقی می‌افتد؟

در Server-Side Request Forgery، مهاجم تلاش می‌کند Backend Server را مجبور کند Requestی به Destination ناخواسته بفرستد.

عامل ارسال Request:

Server

است.

<table> <thead> <tr> <th>ویژگی</th> <th>SSRF</th> <th>CSRF</th> </tr> </thead> <tbody> <tr> <td>فرستنده Request</td> <td>Server</td> <td>مرورگر قربانی</td> </tr> <tr> <td>مشکل اصلی</td> <td>کنترل Destination سمت Server</td> <td>ارسال عملیات ناخواسته با Session قربانی</td> </tr> <tr> <td>کنترل اصلی</td> <td>Allowlist، Validation و Egress Control</td> <td>CSRF Token، SameSite و Origin Controls</td> </tr> <tr> <td>دسترسی به شبکه داخلی</td> <td>ممکن است بسیار مهم باشد</td> <td>معمولاً مدل متفاوتی دارد</td> </tr> </tbody> </table>

در نتیجه Anti-CSRF Token راهکار جلوگیری از SSRF نیست.

تفاوت SSRF با Open Redirect

در Open Redirect معمولاً Application باعث می‌شود مرورگر User به URL دیگری هدایت شود.

اما در SSRF خود Server به Destination متصل می‌شود.

با این حال Redirect در دفاع SSRF بسیار مهم است.

ممکن است URL اولیه از نظر Security Policy مجاز باشد اما Remote Server پاسخ Redirect بدهد و HTTP Client مقصد دوم را بدون Validation دنبال کند.

در چنین حالتی Validation اولیه عملاً کافی نیست.

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

تفاوت SSRF با XSS و SQL Injection

در XSS مشکل اصلی اجرای داده ناامن در Browser است.

در SQL Injection، ورودی User روی Query دیتابیس اثر می‌گذارد.

در SSRF، ورودی User روی Network Destination یا Request سمت Server اثر می‌گذارد.

بنابراین ابزارهای دفاعی متفاوت هستند.

Prepared Statement جلوی SQL Injection را می‌گیرد اما SSRF را حل نمی‌کند.

Output Encoding برای XSS مهم است اما Destination Validation نیست.

هر Vulnerability باید کنترل متناسب با Root Cause خودش را داشته باشد.

ارتباط SSRF و XXE

XXE یا XML External Entity آسیب‌پذیری متفاوتی است، اما می‌تواند در برخی Parserها باعث ایجاد Outbound Request شود.

OWASP نیز اشاره می‌کند که XXE در بعضی شرایط می‌تواند زمینه SSRF ایجاد کند و MITRE رابطه نزدیکی بین CWE-918 و CWE-611 را مطرح می‌کند.

بنابراین اگر برنامه XML غیرقابل اعتماد پردازش می‌کند، تنظیمات Parser نیز باید در Threat Model SSRF در نظر گرفته شوند.

چرا SSRF در Cloud اهمیت ویژه‌ای دارد؟

در Cloud معمولاً Application به منابع متعددی در محیط داخلی Provider دسترسی دارد.

برای مثال ممکن است Workload به:

• Metadata Service؛
• Identity Service؛
• Storage API؛
• Internal Load Balancer؛
• Management API؛
• Container Service

متصل شود.

به همین دلیل SSRF در Cloud می‌تواند از یک ضعف ساده در Fetch کردن URL به Incident بزرگ‌تری تبدیل شود.

یکی از معروف‌ترین موضوعات در این حوزه Instance Metadata Service است.

Metadata Service اطلاعاتی درباره Instance و Environment در اختیار Software داخل ماشین قرار می‌دهد.

اگر Application آسیب‌پذیر بتواند به Metadata Service دسترسی پیدا کند، احتمال افشای اطلاعات یا Credentialهای موقت باید در Threat Model در نظر گرفته شود.

IMDSv2 و دفاع در برابر SSRF در AWS

AWS برای EC2 دارای Instance Metadata Service است.

AWS توضیح می‌دهد IMDSv2 یک روش Session-oriented است که ابتدا Session Token ایجاد می‌کند و سپس درخواست‌های Metadata باید Token معتبر داشته باشند.

AWS Security Guidance نیز توصیه می‌کند EC2 Instanceها از IMDSv2 استفاده کنند و IMDSv1 در صورت امکان غیرفعال شود؛ زیرا IMDSv2 حفاظت قوی‌تری در برابر سوءاستفاده‌هایی از جمله برخی سناریوهای SSRF ایجاد می‌کند.

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

فعال‌سازی IMDSv2 جایگزین اصلاح SSRF نیست.

اگر Application مقصدهای دلخواه را بدون Policy Fetch می‌کند، ضعف اصلی همچنان وجود دارد.

IMDSv2 فقط یک Defense in Depth برای کاهش Blast Radius است.

SSRF در Microservices

در معماری Microservices، Applicationهای مختلف دائماً با یکدیگر ارتباط دارند.

ممکن است Architecture شامل سرویس‌هایی مانند:

Frontend API ↓ User Service ↓ Order Service ↓ Payment Service ↓ Reporting Service

باشد.

بسیاری از این Serviceها Public نیستند.

اشتباه رایج این است که تصور شود:

«چون API فقط از داخل شبکه قابل دسترس است، Authentication لازم نیست.»

این فرض خطرناک است.

اگر یک Service عمومی‌تر به SSRF آسیب‌پذیر باشد، ممکن است Request از همان شبکه داخلی به Service دیگر برسد.

در معماری امن، Internal Service نیز باید براساس حساسیتش:

• Authentication؛
• Authorization؛
• TLS؛
• Network Policy؛
• Least Privilege

داشته باشد.

SSRF و Zero Trust

Zero Trust می‌گوید Trust نباید فقط از Network Location ناشی شود.

به عبارت ساده:

«داخل شبکه است» نباید معادل «مورد اعتماد است» باشد.

SSRF دقیقاً یکی از دلایلی است که این اصل اهمیت دارد.

اگر Internal API هر Requestی از Private Network را بدون Authentication بپذیرد، یک Server آسیب‌پذیر در همان Network می‌تواند به حلقه ضعیف معماری تبدیل شود.

یک مدل بهتر:

Identity + Authentication + Authorization + Network Policy

است.

مهم‌ترین سؤال دفاعی: آیا واقعاً User باید URL کامل وارد کند؟

پیش از طراحی پیچیده‌ترین URL Validator، یک سؤال ساده بپرسید:

آیا Business Feature واقعاً به URL آزاد نیاز دارد؟

گاهی جواب خیر است.

فرض کنید Application فقط باید اطلاعات سه Provider مشخص را دریافت کند.

به‌جای اینکه User یک URL کامل وارد کند، می‌تواند فقط این مقدار را انتخاب کند:

Provider A Provider B Provider C

و Server Destination واقعی را از Configuration داخلی خودش بسازد.

این طراحی Attack Surface را بسیار کاهش می‌دهد.

به‌طور کلی:

هرچه User کنترل کمتری روی Scheme، Host، Port، Path و Header داشته باشد، سطح حمله کمتر است.

Allowlist چیست؟

Allowlist یعنی فقط Destinationهایی که از قبل مجاز شناخته شده‌اند قابل استفاده باشند.

فرض کنید Feature فقط باید با:

api.partner.example

ارتباط داشته باشد.

در این صورت به جای تلاش برای پیدا کردن همه URLهای خطرناک، می‌توان Policy را چنین تعریف کرد:

فقط Domain مشخص فقط HTTPS فقط Port مشخص فقط Pathهای لازم

اجازه داشته باشند.

OWASP در SSRF Prevention Cheat Sheet دو Scenario را از هم جدا می‌کند: حالتی که Application فقط باید با سرویس‌های شناخته‌شده ارتباط داشته باشد و حالتی که واقعاً باید به Destinationهای خارجی مختلف Request بزند. در حالت اول، Allowlist راهکار ترجیحی است.

Allowlist چرا بهتر از Denylist است؟

Denylist می‌گوید:

«همه چیز مجاز است، مگر مواردی که من خطرناک شناخته‌ام.»

Allowlist می‌گوید:

«هیچ Destinationی مجاز نیست، مگر مواردی که صراحتاً تأیید شده‌اند.»

در فضای Network Destination، Denylist مشکل دارد؛ زیرا انواع مختلف Address وجود دارد:

• IPv4؛
• IPv6؛
• Hostname؛
• Redirect؛
• Alternate Representation؛
• DNS Mapping.

بنابراین Block کردن چند رشته مانند localhost طراحی کاملی نیست.

OWASP نیز تأکید می‌کند Allowlist در صورت امکان گزینه ترجیحی است و Denylist می‌تواند در برابر Bypassهای مختلف شکننده باشد.

URL Validation دقیقاً باید چه چیزهایی را بررسی کند؟

URL فقط یک String ساده نیست.

URL از اجزای مختلفی تشکیل شده است:

Scheme Host Port Path Query Fragment Userinfo

برای SSRF مهم‌ترین بخش‌ها معمولاً Scheme، Host، Port و Destination واقعی هستند.

Scheme Validation

اگر Application فقط به HTTPS نیاز دارد، فقط HTTPS را Allow کنید.

اگر HTTP نیز واقعاً لازم است، HTTP و HTTPS.

Protocolهای غیرضروری را فعال نگذارید.

Host Validation

Host باید براساس Business Policy بررسی شود.

اگر Allowlist وجود دارد، Domain باید دقیقاً با Domain مجاز تطبیق داشته باشد.

بررسی‌هایی مانند:

«آیا عبارت example.com در URL وجود دارد؟»

کافی نیست.

URL باید ابتدا با Parser استاندارد Parse شود.

Port Validation

اگر Feature فقط Portهای استاندارد نیاز دارد، User نباید بتواند آزادانه هر Portی را انتخاب کند.

Path Validation

در برخی API Integrationها حتی Path نیز باید محدود شود.

Userinfo

در بیشتر Featureها نیازی نیست URL دارای Credential داخلی باشد.

قبول کردن ساختارهای اضافی بدون نیاز واقعی، Parsing و Security Review را پیچیده‌تر می‌کند.

چرا Regex به‌تنهایی برای URL Validation مناسب نیست؟

URL Grammar پیچیده است.

Regex دست‌ساز معمولاً بسیاری از Edge Caseها را از دست می‌دهد.

رویکرد بهتر این است:

URL ↓ Standard Parser ↓ Extract Components ↓ Apply Security Policy

یعنی ابتدا URL با Parser معتبر Framework یا Language Parse شود و سپس Scheme، Host، Port و سایر اجزا براساس Policy بررسی شوند.

OWASP نیز برای ورودی‌های پیچیده توصیه می‌کند از Libraryهای معتبر Validation/Parsing استفاده شود و به Patternهای ساده دستی اتکا نشود.

DNS چرا در SSRF اهمیت دارد؟

فرض کنید یک Domain از نظر نام ظاهراً مجاز است.

زمانی که Server می‌خواهد به آن متصل شود، DNS باید Domain را به IP Resolve کند.

بنابراین Security Decision فقط براساس String Domain کافی نیست.

باید در نظر گرفت Destination نهایی چه IPای است و آن Address متعلق به چه Network Rangeی است.

برای مثال Architecture ممکن است Policy داشته باشد که Application به:

Public Internet

اجازه دسترسی داشته باشد، اما به:

Private Network

خیر.

در این صورت Resolved IP نیز باید در Policy قرار بگیرد.

IPv4 و IPv6 را همزمان در نظر بگیرید

یک اشتباه رایج این است که Validation فقط برای IPv4 طراحی شود.

در حالی که Infrastructure مدرن می‌تواند IPv6 داشته باشد.

اگر Policy شبکه‌ای قرار است Private، Loopback یا سایر Address Classها را محدود کند، باید هر دو Address Family را در نظر بگیرد.

Security Rule نباید به Representation خاص IP وابسته باشد.

DNS Rebinding و مشکل Time-of-Check / Time-of-Use

فرض کنید Application در مرحله Validation یک Domain را Resolve می‌کند.

Destination مجاز است.

چند لحظه بعد HTTP Client دوباره همان Domain را Resolve می‌کند.

اگر نتیجه DNS تغییر کرده باشد، Address استفاده‌شده در مرحله Connection ممکن است با Address بررسی‌شده متفاوت باشد.

این نوع مشکل به مفهوم Time-of-Check / Time-of-Use نزدیک است.

OWASP در راهنمای SSRF خود درباره DNS Pinning/Rebinding هشدار می‌دهد و توصیه می‌کند طراحی Validation و DNS Resolution به‌گونه‌ای باشد که Domainهای مورد اعتماد به IPهای غیرمنتظره Internal Resolve نشوند.

Redirect چگونه Validation را دور می‌زند؟

فرض کنید Server فقط URL اولیه را بررسی کند.

مرحله اول:

URL → مجاز

Server Request می‌زند.

Remote Server پاسخ می‌دهد:

Redirect → Destination دوم

اگر HTTP Client به‌طور خودکار Redirect را دنبال کند، ممکن است Destination دوم هیچ Validationی نشده باشد.

بنابراین دو انتخاب دفاعی وجود دارد:

1. Follow Redirect را غیرفعال کنید؛
2. هر Redirect Target را مانند Request اولیه دوباره بررسی کنید.

OWASP به‌طور مشخص غیرفعال‌کردن Automatic Redirect را در کنترل SSRF توصیه می‌کند تا Redirect به ابزار Bypass Validation تبدیل نشود.

کنترل Egress Traffic؛ لایه‌ای که اغلب فراموش می‌شود

بسیاری از تیم‌ها Firewall را فقط برای Inbound Traffic تصور می‌کنند.

مثلاً:

چه کسی می‌تواند وارد Server شود؟

اما برای SSRF باید سؤال دیگری نیز مطرح شود:

Server اجازه دارد به کجا متصل شود؟

این همان Egress Control است.

فرض کنید Web Server فقط برای عملکرد خودش نیاز دارد با:

• Payment Provider؛
• Email Provider؛
• CDN API

ارتباط برقرار کند.

اگر Server بدون هیچ محدودیتی بتواند با تمام شبکه‌های داخلی و هر IP اینترنت ارتباط ایجاد کند، Blast Radius یک SSRF افزایش می‌یابد.

Egress Filtering چیست؟

Egress Filtering یعنی ترافیک خروجی Workload براساس Policy محدود شود.

مدل ضعیف:

Server → Any Destination = Allow

مدل امن‌تر:

Server → Required Service A = Allow Server → Required Service B = Allow Server → Internal Management Network = Deny Server → Other Destinations = Deny or Restricted

امکان اجرای این مدل به معماری و Business Requirement بستگی دارد.

برخی برنامه‌ها واقعاً نیاز دارند به Destinationهای بسیار متنوع اینترنتی متصل شوند. در این شرایط Application Validation و Monitoring اهمیت بیشتری پیدا می‌کند.

Deny by Default در Egress Policy

در محیط‌های حساس می‌توان Egress را نیز طبق اصل:

Deny by Default

طراحی کرد.

یعنی Workload به صورت پیش‌فرض اجازه ارتباط خروجی ندارد و تنها Destinationهای لازم باز می‌شوند.

این معماری مزیت بزرگی دارد:

اگر Application Validation در یک Feature دچار Bug شود، Network Layer هنوز می‌تواند بسیاری از Destinationها را مسدود کند.

این همان مفهوم Defense in Depth است.

Network Segmentation

Web Server نباید بدون ضرورت در همان Trust Zone سرویس‌های بسیار حساس قرار گیرد.

یک معماری نمونه:

Public Tier ↓ Application Tier ↓ Data Tier ↓ Management Tier

هر Tier فقط باید به بخش‌هایی که برای عملکرد خودش لازم دارد دسترسی داشته باشد.

برای Container Environment نیز می‌توان از Network Policy مناسب استفاده کرد.

هدف Network Segmentation حذف کامل SSRF نیست.

هدف:

کاهش دامنه اثر SSRF در صورت وقوع

است.

سرویس‌های داخلی باید Authentication داشته باشند

یکی از خطرناک‌ترین فرض‌ها این است:

«این API داخلی است، پس نیازی به Authentication ندارد.»

Internal بودن یک Endpoint به‌تنهایی Boundary قابل اعتماد کاملی نیست.

SSRF، Compromised Host، Misconfiguration و Insider Access همگی می‌توانند این فرض را نقض کنند.

برای سرویس‌های حساس باید براساس Threat Model از:

• Service Identity؛
• Authentication؛
• Authorization؛
• mTLS؛
• Tokenهای Scoped

استفاده شود.

اصل Least Privilege در SSRF

Least Privilege فقط برای User Account نیست.

Application Server نیز باید حداقل دسترسی لازم را داشته باشد.

برای مثال:

اگر Web Application نیازی به Management Network ندارد، نباید Reachability آن را داشته باشد.

اگر Service Account فقط نیاز به Read یک Resource دارد، Permission Write لازم نیست.

اگر Server فقط با دو API خارجی کار می‌کند، Egress آزادانه به تمام مقصدها شاید ضروری نباشد.

هر دسترسی اضافی می‌تواند Blast Radius یک Vulnerability احتمالی را افزایش دهد.

Response مقصد را مستقیماً Proxy نکنید

فرض کنید Business Feature فقط نیاز دارد بررسی کند یک URL Online است.

در این حالت User شاید فقط نیاز داشته باشد بداند:

Available / Unavailable

اما اگر برنامه تمام Response Body مقصد را به User برگرداند، Data Exposure Potential افزایش می‌یابد.

اصل مناسب:

Minimum Necessary Response

است.

اگر محتوای Remote Resource لازم نیست، آن را به Client برنگردانید.

اندازه Response را محدود کنید

حتی اگر Destination قانونی باشد، Server نباید بدون محدودیت Data دریافت کند.

برای HTTP Client محدودیت‌هایی مانند موارد زیر اهمیت دارند:

Maximum Response Size Connection Timeout Read Timeout Maximum Redirect Count

این کنترل‌ها علاوه بر Security برای Stability و جلوگیری از Resource Exhaustion نیز مفید هستند.

Timeout چرا مهم است؟

Request به Destination کند یا غیرقابل دسترس می‌تواند Worker یا Connection را برای مدت طولانی اشغال کند.

اگر قابلیت Fetch عمومی باشد، این رفتار می‌تواند Resource Consumption ایجاد کند.

به همین دلیل:

• Connection Timeout؛
• Overall Request Timeout؛
• Read Timeout

باید متناسب با Business Logic تعریف شوند.

Method درخواست را محدود کنید

اگر Feature فقط GET نیاز دارد، نباید User بتواند Method دلخواه انتخاب کند.

کنترل User روی موارد زیر باید حداقلی باشد:

• HTTP Method؛
• Destination؛
• Header؛
• Body؛
• Port.

هر Control Surface اضافی Risk Surface را گسترش می‌دهد.

Headerهای Client را کورکورانه Forward نکنید

Proxy Endpointها گاهی Headerهای Request Client را به Destination Forward می‌کنند.

این طراحی باید بسیار دقیق بررسی شود.

Header ممکن است شامل:

Authorization Cookie Internal Token Tracing Data Service Credential

باشد.

راهکار امن‌تر معمولاً ساختن Headerهای خروجی توسط Server براساس Allowlist است.

یعنی:

فقط Headerهایی که Feature واقعاً نیاز دارد.

Credential را به Destination متصل کنید

فرض کنید Application برای ارتباط با Service A یک API Key دارد.

اگر User بتواند Destination Request را تغییر دهد اما Server همچنان API Key سرویس A را به Request اضافه کند، Credential ممکن است به Destination نامناسب ارسال شود.

در معماری امن:

Credential A فقط با Destination A

استفاده می‌شود.

این Binding باید در Server Configuration باشد، نه در داده‌ای که Client تعیین می‌کند.

SSRF در WordPress چگونه ایجاد می‌شود؟

WordPress دارای HTTP API داخلی برای ارسال Request است.

توابعی مانند:

wp_remote_get()

برای Requestهای عادی کاملاً معتبر هستند.

اما اگر URL مستقیماً توسط User تعیین شده باشد، SSRF Threat Model تغییر می‌کند.

مستندات رسمی WordPress درباره wp_safe_remote_get() توضیح می‌دهند که این تابع برای شرایطی مناسب است که HTTP Request به یک URL دلخواه انجام می‌شود. URL اولیه و URLهای Redirectشده توسط wp_http_validate_url() بررسی می‌شوند تا خطر SSRF کاهش پیدا کند و فقط HTTP و HTTPS پشتیبانی می‌شوند.

تفاوت wp_remote_get و wp_safe_remote_get

از نظر امنیتی باید Context را در نظر گرفت.

اگر Developer خودش Destination ثابت و مورد اعتماد را ساخته است، wp_remote_get() می‌تواند کاملاً طبیعی باشد.

اما وقتی URL از User، Plugin Setting یا منبعی با Trust پایین می‌آید، WordPress یک گزینه اختصاصی‌تر دارد:

wp_safe_remote_get()

این تابع برای Safe HTTP Request طراحی شده و Validation بیشتری روی URL و Redirectها انجام می‌دهد.

wp_safe_remote_request در وردپرس

برای Requestهایی که الزاماً GET نیستند، WordPress تابع:

wp_safe_remote_request()

را نیز ارائه می‌کند.

مستندات رسمی WordPress می‌گویند URL اولیه و URLهایی که Redirect به آن‌ها انجام می‌شود با wp_http_validate_url() بررسی می‌شوند و تنها HTTP/HTTPS پشتیبانی می‌شود.

با این حال هیچ Safe Function عمومی نمی‌تواند Business Logic شما را حدس بزند.

اگر Plugin شما فقط باید به:

api.example.com

وصل شود، همچنان بهتر است Business Allowlist مخصوص خودتان را نیز داشته باشید.

الگوی مناسب SSRF Prevention در WordPress

یک مسیر دفاعی مناسب می‌تواند چنین باشد:

User Input ↓ Sanitization ↓ Parse ↓ Business Allowlist ↓ WordPress Safe HTTP API ↓ Timeout / Response Limit ↓ Minimal Response ↓ Logging

توسعه‌دهنده نباید URL ورودی از:

REST API AJAX Form Query Parameter User Meta Option

را بدون بررسی مناسب مستقیماً وارد HTTP Client کند.

SSRF در افزونه‌های WordPress

Pluginهای WordPress ممکن است قابلیت‌هایی مانند این‌ها داشته باشند:

• Import Image by URL؛
• Check Website Status؛
• Remote Backup؛
• Webhook؛
• External Feed؛
• URL Preview؛
• License Server؛
• API Integration.

هر یک از این قابلیت‌ها باید Context امنیتی جداگانه داشته باشند.

یک License API ثابت با یک URL Preview عمومی، Threat Model یکسانی ندارد.

SSRF در WooCommerce

WooCommerce و Pluginهای مرتبط می‌توانند Integrationهای فراوان داشته باشند:

• Payment Gateway؛
• Shipping Service؛
• Accounting API؛
• ERP؛
• Webhook؛
• Product Feed؛
• Remote Media.

در Custom Development مهم است Developer بداند چه Destinationهایی واقعاً باید User-controlled باشند و کدام‌ها باید Server-side Configuration باشند.

آیا sanitize_text_field جلوی SSRF را می‌گیرد؟

خیر.

Sanitization و Destination Authorization دو مفهوم متفاوت هستند.

یک URL می‌تواند از نظر Text Sanitization کاملاً معتبر باشد اما به Destination غیرمجاز اشاره کند.

اصل مهم:

Valid Input لزوماً Safe Destination نیست.

برای SSRF باید Semantic Validation انجام شود؛ یعنی مشخص شود مقصد براساس Business Policy مجاز است یا خیر.

آیا WAF جلوی SSRF را می‌گیرد؟

WAF می‌تواند یک لایه کمک‌کننده باشد، اما درمان اصلی SSRF نیست.

در SSRF معمولاً دو Request داریم:

Request اول:

Client → Application

Request دوم:

Application → Destination

WAF ممکن است روی Request اول دید خوبی داشته باشد، اما تصمیم واقعی درباره مقصد Request دوم به Context برنامه، DNS و Network Policy بستگی دارد.

بنابراین کنترل اصلی باید در:

Application Network Internal Services

باشد.

WAF یک Defense in Depth است.

آیا Rate Limiting از SSRF جلوگیری می‌کند؟

خیر.

Rate Limiting می‌تواند تعداد Requestها را کاهش دهد و Automated Abuse را محدود کند.

اما اگر یک Destination غیرمجاز همچنان قابل دسترسی باشد، Root Cause برطرف نشده است.

Rate Limiting بهتر است بعد از Controls اصلی قرار گیرد:

Prevention ↓ Containment ↓ Rate Limit ↓ Detection

Logging برای تشخیص SSRF

Applicationهایی که Outbound HTTP Request ایجاد می‌کنند باید Visibility کافی داشته باشند.

یک Log دفاعی مناسب می‌تواند Contextهایی مانند این‌ها داشته باشد:

• Feature Name؛
• User ID؛
• Tenant ID؛
• Destination Domain؛
• Resolved IP؛
• Port؛
• Method؛
• Allow/Deny Decision؛
• Response Status؛
• Duration؛
• Redirect Count.

اما Secret یا Token کامل نباید بدون ضرورت در Log ذخیره شود.

چه رفتارهایی در Monitoring مشکوک هستند؟

از دید دفاعی، رفتارهای زیر می‌توانند نیازمند Investigation باشند:

Request به تعداد زیادی Domain متفاوت، افزایش Destinationهای Denied، تلاش برای ارتباط با Network Rangeهای غیرمنتظره، افزایش Timeoutها، Portهای غیرمعمول، Redirectهای زیاد یا Fetchهای پرتعداد توسط یک User.

هیچ‌کدام از این موارد به‌تنهایی اثبات Attack نیستند.

اما می‌توانند Security Signal مناسبی باشند.

DNS Logging در تشخیص SSRF

بخش بزرگی از Server-side Fetchها ابتدا DNS Query ایجاد می‌کنند.

در محیط‌های Enterprise، DNS Log می‌تواند Visibility خوبی درباره Destinationهای غیرمعمول ایجاد کند.

اگر Workloadی که معمولاً فقط با چند Domain مشخص ارتباط دارد ناگهان تعداد زیادی Domain ناشناس Resolve کند، این تغییر ارزش Investigation دارد.

Egress Proxy به‌عنوان Control مرکزی

برخی سازمان‌ها Outbound HTTP Traffic را از یک Egress Proxy عبور می‌دهند.

مزایای بالقوه:

• کنترل Destination مرکزی؛
• Logging؛
• Domain Filtering؛
• Policy Enforcement؛
• Audit.

این طراحی برای همه معماری‌ها الزامی نیست، اما در محیط‌های Enterprise می‌تواند SSRF Defense را متمرکزتر کند.

SSRF در Container و Kubernetes

در Kubernetes باید توجه کرد Pod آسیب‌پذیر از نظر Network به چه چیزهایی دسترسی دارد.

اگر همه Podها بتوانند آزادانه با یکدیگر یا Management Serviceها ارتباط داشته باشند، SSRF Blast Radius افزایش می‌یابد.

NetworkPolicy می‌تواند ارتباطات را محدود کند.

همچنین Service Account هر Workload باید فقط Permissionهای موردنیاز را داشته باشد.

Network Segmentation و IAM باید یکدیگر را تکمیل کنند.

SSRF و Serverless

Serverless Functionها نیز می‌توانند SSRF داشته باشند.

اگر Function:

• URL دریافت کند؛
• از آن Data Fetch کند؛
• به VPC یا Cloud Service دسترسی داشته باشد،

همان Threat Model وجود دارد.

Serverless بودن Application SSRF را از بین نمی‌برد.

در این محیط نیز باید:

Destination Validation IAM Least Privilege Network Controls Secret Isolation

رعایت شوند.

SSRF و API Gateway

API Gateway می‌تواند بخشی از Architecture باشد اما به‌تنهایی SSRF را حل نمی‌کند.

اگر Backend پس از دریافت Request از Gateway خودش به URL User-controlled متصل شود، SSRF همچنان ممکن است.

Gateway بیشتر روی Client-to-Server Traffic کنترل دارد.

Server-to-Destination Request نیازمند Controls جداگانه است.

Blind SSRF را چگونه از دید دفاعی بررسی کنیم؟

در تست دفاعی نیازی به اجرای سناریوهای مخرب نیست.

می‌توان از Destinationهای کنترل‌شده و Test Environment استفاده کرد و بررسی کرد آیا Application برخلاف Policy به Destination غیرمجاز Test Request می‌زند یا خیر.

هدف تست:

اثبات Enforcement Policy

است.

نه دسترسی به سیستم‌های واقعی.

چگونه SSRF را در Code Review پیدا کنیم؟

یکی از روش‌های مفید تحلیل Data Flow است.

دو مفهوم مهم:

Source و Sink

Source

جایی که داده غیرقابل اعتماد وارد می‌شود:

• Request Parameter؛
• Form؛
• API Body؛
• Database Data قابل کنترل User؛
• Webhook Setting.

Sink

جایی که داده برای Network Operation استفاده می‌شود:

• HTTP Client؛
• URL Fetcher؛
• Browser Renderer؛
• File Downloader؛
• Webhook Sender.

Reviewer باید بررسی کند آیا بین Source و Sink یک Security Policy معتبر وجود دارد یا خیر.

MITRE نیز Static Analysis را یکی از روش‌های تشخیص برخی نمونه‌های CWE-918 می‌داند؛ ابزار می‌تواند جریان داده بین Source و Network Sink را بررسی کند.

SAST برای SSRF

Static Application Security Testing می‌تواند بعضی Patternها را پیدا کند.

برای مثال:

User Input → HTTP Client

بدون Validation قابل مشاهده.

اما SAST محدودیت دارد.

ابزار همیشه نمی‌تواند تشخیص دهد یک Business Allowlist واقعاً درست است یا Destination برای سازمان مجاز محسوب می‌شود.

بنابراین:

SAST + Code Review + Testing

ترکیب مناسب‌تری است.

Threat Modeling برای SSRF

در Threat Model هر Server-side Fetch Feature باید پاسخ این سؤال‌ها مشخص باشد:

چه کسی URL را تعیین می‌کند؟

Server به چه Networkهایی دسترسی دارد؟

Destination مورد انتظار چیست؟

آیا Redirect وجود دارد؟

آیا DNS قابل تغییر است؟

چه Credentialی همراه Request ارسال می‌شود؟

Response چه می‌شود؟

اگر Validation Fail شود چه اتفاقی می‌افتد؟

این سؤالات قبل از کدنویسی می‌توانند بسیاری از SSRFها را حذف کنند.

معماری پیشنهادی برای جلوگیری از SSRF

یک Flow دفاعی مناسب می‌تواند چنین باشد:

User Input ↓ آیا URL آزاد واقعاً لازم است؟ ↓ URL Parser استاندارد ↓ Scheme Allowlist ↓ Host / Domain Policy ↓ Port Validation ↓ DNS Resolution ↓ Resolved IP Validation ↓ Redirect Policy ↓ Egress Network Policy ↓ HTTP Client محدود ↓ Response Size / Timeout ↓ Response Filtering ↓ Security Logging

هیچ مرحله‌ای به‌تنهایی جای مراحل دیگر را نمی‌گیرد.

مرحله اول؛ ورودی را کمینه کنید

بهترین User-controlled URL، URLی است که اصلاً User مجبور نیست وارد کند.

اگر امکان دارد Full URL را با شناسه داخلی جایگزین کنید.

مثلاً:

provider=1

و Server خودش Endpoint را از Configuration بخواند.

مرحله دوم؛ Allowlist طراحی کنید

Destinationهای مجاز باید صریح و مستند باشند.

هر Domain جدید نیازمند Review باشد.

مرحله سوم؛ Parse کنید، Split نکنید

URL باید با Standard URL Parser پردازش شود.

String Operation ساده برای Host Extraction خطر ایجاد می‌کند.

مرحله چهارم؛ Destination واقعی را بررسی کنید

Domain و Resolved Address باید با Policy سازگار باشند.

مرحله پنجم؛ Redirect را مجدد بررسی کنید

هر Hop یک Destination جدید است.

مرحله ششم؛ Egress را محدود کنید

Infrastructure نباید Application را به تمام Network باز بگذارد مگر واقعاً لازم باشد.

مرحله هفتم؛ Internal Service را امن کنید

به Network Location اعتماد کامل نکنید.

مرحله هشتم؛ HTTP Client را محدود کنید

Timeout، Size Limit، Redirect Limit و Method Policy داشته باشید.

مرحله نهم؛ Data Exposure را کم کنید

Remote Response را فقط به اندازه Business Requirement پردازش کنید.

مرحله دهم؛ Monitor کنید

Outbound Behavior باید قابل Audit باشد.

اشتباهات رایج در جلوگیری از SSRF

اشتباه اول: فقط localhost را مسدود کنیم

SSRF فقط Localhost نیست.

Networkهای خصوصی، Link-local، IPv6، Internal DNS و Cloud Serviceها نیز ممکن است در Threat Model باشند.

اشتباه دوم: فقط 127.0.0.1 را Block کنیم

Address Validation نباید به یک Representation خاص وابسته باشد.

اشتباه سوم: فقط URL String را بررسی کنیم

Destination واقعی باید پس از Parsing و Resolution بررسی شود.

اشتباه چهارم: Allowlist را با Contains پیاده‌سازی کنیم

Domain Matching باید دقیق باشد.

وجود نام یک Domain مورد اعتماد در بخشی از URL به معنی مورد اعتماد بودن Host نیست.

اشتباه پنجم: Redirect را نادیده بگیریم

Destination اولیه ممکن است امن باشد اما Destination دوم خیر.

اشتباه ششم: فقط WAF نصب کنیم

WAF Business Logic و Destination Network را جایگزین نمی‌کند.

اشتباه هفتم: فقط Input Sanitization انجام دهیم

Sanitization تعیین نمی‌کند URL از نظر Policy مجاز است.

اشتباه هشتم: تمام Protocolها را آزاد بگذاریم

فقط Protocolهایی فعال باشند که Business نیاز دارد.

اشتباه نهم: همه Portها را باز بگذاریم

Port Range نیز بخشی از Destination Policy است.

اشتباه دهم: Raw Response را به User نمایش دهیم

Data Minimization باید رعایت شود.

اشتباه یازدهم: Internal API را بدون Authentication اجرا کنیم

Private Network به‌تنهایی Trust Boundary کافی نیست.

اشتباه دوازدهم: Headerهای ورودی را Forward کنیم

Credential و Token ممکن است به Destination نامناسب منتقل شوند.

اشتباه سیزدهم: Egress Filtering نداشته باشیم

Application Bug بدون Egress Restriction Blast Radius بیشتری دارد.

اشتباه چهاردهم: فقط IPv4 را بررسی کنیم

IPv6 نیز باید در Policy دیده شود.

اشتباه پانزدهم: IMDSv2 را جای Patch SSRF بدانیم

IMDSv2 یک Defense in Depth است، نه درمان Root Cause.

چک‌لیست توسعه‌دهندگان برای جلوگیری از SSRF

• مشخص کنید آیا User واقعاً باید Full URL وارد کند.
• در صورت امکان Destination را Server-side تعیین کنید.
• برای سرویس‌های مشخص از Allowlist استفاده کنید.
• فقط Schemeهای لازم مانند HTTPS را فعال کنید.
• از URL Parser استاندارد استفاده کنید.
• Host را براساس Policy دقیق بررسی کنید.
• Portهای مجاز را محدود کنید.
• DNS Resolution را در Security Decision لحاظ کنید.
• IPv4 و IPv6 را هر دو بررسی کنید.
• Private و Internal Destinationها را مطابق Threat Model محدود کنید.
• Redirect خودکار را غیرفعال یا مقصد هر Redirect را مجدداً Validate کنید.
• Egress Traffic سرور را محدود کنید.
• Network Segmentation داشته باشید.
• Internal APIها را Authenticate کنید.
• Principle of Least Privilege را روی Service Accountها اجرا کنید.
• Headerهای Client را کورکورانه Forward نکنید.
• Credential را فقط برای Destination مربوط به خودش ارسال کنید.
• Request Method را محدود کنید.
• Timeout تعریف کنید.
• Maximum Response Size تعیین کنید.
• Raw Response غیرضروری را به User برنگردانید.
• Logging مناسب برای Outbound Request داشته باشید.
• روی رفتارهای غیرعادی Alert تعریف کنید.
• SSRF Testهای منفی در CI/CD داشته باشید.
• در WordPress برای URLهای غیرقابل اعتماد از Safe HTTP API مناسب استفاده کنید.
• Cloud Metadata Service را با کنترل‌های Provider امن کنید.

چک‌لیست مدیر سایت و تیم DevOps

حتی اگر برنامه‌نویس نیستید، می‌توانید از تیم فنی بخواهید به چند سؤال مهم پاسخ دهد.

چه Featureهایی در سایت از Server به Internet Request می‌زنند؟

آیا Webhook داریم؟

آیا Remote Image Import داریم؟

آیا Feed یا URL Preview داریم؟

آیا Pluginهای WordPress URL خارجی دریافت می‌کنند؟

آیا Server Egress Firewall دارد؟

Web Server به چه شبکه‌های داخلی دسترسی دارد؟

آیا Management Network از Web Tier جدا شده است؟

آیا Internal API Authentication دارد؟

آیا DNS و Outbound Traffic Log می‌شوند؟

آیا Cloud Metadata Protection فعال است؟

آخرین Security Review برای Server-side Fetchها چه زمانی انجام شده است؟

اگر SSRF در سایت پیدا شد چه کنیم؟

اگر در Application خودتان SSRF پیدا کردید، فقط یک Regex به URL اضافه نکنید و Incident را بسته تلقی نکنید.

Feature را محدود کنید

اگر امکان دارد قابلیت آسیب‌پذیر را تا زمان Patch محدود یا موقتاً غیرفعال کنید.

Network Reachability را بررسی کنید

مشخص کنید Server آسیب‌پذیر از نظر Network واقعاً به چه Resourceهایی دسترسی داشته است.

Outbound Logها را بررسی کنید

موارد مهم:

Application Log DNS Log Firewall Log Proxy Log Cloud Audit Log

هستند.

Credential Exposure را ارزیابی کنید

اگر Server به سرویس‌هایی دسترسی داشته که Credential یا Sensitive Data ارائه می‌کرده‌اند، Incident Response باید این احتمال را بررسی کند.

Destination Validation را اصلاح کنید

Allowlist، DNS/IP Policy و Redirect Handling باید بررسی شوند.

Infrastructure را اصلاح کنید

اگر Server دسترسی شبکه‌ای بیش از نیاز داشته است، Egress و Segmentation را بهبود دهید.

Internal APIها را بررسی کنید

اگر Internal Service فقط به «Private بودن Network» اعتماد می‌کند، Authentication و Authorization آن را بازبینی کنید.

Regression Test بنویسید

Patch بدون Test می‌تواند در آینده دوباره شکسته شود.

تست SSRF به شکل ایمن و دفاعی

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

برای تست دفاعی لازم نیست به Resourceهای واقعی حساس دسترسی پیدا کنید.

می‌توان Test Environment و Destinationهای کنترل‌شده ایجاد کرد.

هدف Test باید چنین باشد:

مقصد مجاز → Allowed

مقصد خارج از Policy → Denied

Scheme غیرمجاز → Denied

Port غیرمجاز → Denied

Redirect خارج از Policy → Denied

این روش Security Control را آزمایش می‌کند بدون آنکه نیاز به سوءاستفاده واقعی وجود داشته باشد.

SSRF Regression Testing

برای Featureهای Server-side Fetch بهتر است Testهای خودکار داشته باشید.

برای مثال Test Suite باید بررسی کند تغییرات Future در:

HTTP Client URL Parser Proxy Configuration Business Logic

باعث حذف Security Policy نشوند.

این موضوع مخصوصاً پس از Refactor اهمیت زیادی دارد.

مقایسه کنترل‌های SSRF

<table> <thead> <tr> <th>راهکار</th> <th>هدف</th> <th>نقش در دفاع</th> </tr> </thead> <tbody> <tr> <td>Allowlist</td> <td>محدودکردن Destination</td> <td>کنترل بسیار مؤثر در صورت امکان</td> </tr> <tr> <td>URL Parsing</td> <td>تحلیل صحیح اجزای URL</td> <td>ضروری</td> </tr> <tr> <td>DNS/IP Validation</td> <td>بررسی مقصد واقعی</td> <td>کنترل مهم</td> </tr> <tr> <td>Redirect Control</td> <td>جلوگیری از تغییر مقصد پس از Validation</td> <td>ضروری در Clientهای دارای Redirect</td> </tr> <tr> <td>Egress Filtering</td> <td>محدودکردن دسترسی خروجی Server</td> <td>Defense in Depth بسیار مهم</td> </tr> <tr> <td>Network Segmentation</td> <td>کاهش Reachability</td> <td>کاهش Blast Radius</td> </tr> <tr> <td>Internal Authentication</td> <td>کاهش اعتماد به شبکه داخلی</td> <td>Defense in Depth</td> </tr> <tr> <td>WAF</td> <td>کاهش برخی رفتارهای مشکوک</td> <td>مکمل، نه درمان اصلی</td> </tr> <tr> <td>Rate Limiting</td> <td>کاهش حجم سوءاستفاده</td> <td>کنترل مکمل</td> </tr> <tr> <td>IMDSv2</td> <td>محافظت بهتر Metadata در AWS</td> <td>Defense in Depth</td> </tr> </tbody> </table>

سؤالات متداول درباره حمله SSRF

SSRF چیست؟

SSRF یا Server-Side Request Forgery آسیب‌پذیری‌ای است که در آن Application تحت تأثیر ورودی User از طرف Server به Destination خارج از محدوده مورد انتظار Request ارسال می‌کند.

SSRF مخفف چیست؟

SSRF مخفف Server-Side Request Forgery است.

مهم‌ترین خطر SSRF چیست؟

مهم‌ترین خطر این است که Server ممکن است به Resourceهایی در شبکه داخلی، Cloud یا Infrastructure دسترسی داشته باشد که User خارجی مستقیماً به آن‌ها دسترسی ندارد.

آیا SSRF فقط در URLهای HTTP رخ می‌دهد؟

خیر. SSRF ذاتاً فقط به HTTP محدود نیست و رفتار دقیق به Protocolها و Schemeهایی بستگی دارد که Library و Application پشتیبانی می‌کنند. به همین دلیل Protocol Allowlist اهمیت دارد.

تفاوت SSRF و CSRF چیست؟

در SSRF، Server Request را ارسال می‌کند. در CSRF، مرورگر User قربانی Request ناخواسته را ارسال می‌کند.

Blind SSRF چیست؟

حالتی است که Server Request ناخواسته را ایجاد می‌کند اما Response مقصد مستقیماً به Client نمایش داده نمی‌شود.

آیا Blind SSRF خطرناک است؟

بله. مخفی بودن Response به معنی جلوگیری از Request یا Side Effectهای احتمالی نیست.

آیا Allowlist بهترین روش جلوگیری از SSRF است؟

اگر Application فقط نیاز دارد با Destinationهای مشخص ارتباط داشته باشد، Allowlist یکی از قوی‌ترین گزینه‌ها است و OWASP نیز این رویکرد را در چنین Scenarioهایی توصیه می‌کند.

آیا Denylist کافی است؟

معمولاً خیر. تنوع Address Representation، DNS، IPv6 و Redirect باعث می‌شود Denylist به‌تنهایی کنترل قابل اتکایی نباشد.

آیا WAF حمله SSRF را متوقف می‌کند؟

WAF می‌تواند کمک کند، اما نمی‌تواند جایگزین Destination Validation، Egress Filtering و معماری صحیح Server شود.

آیا HTTPS جلوی SSRF را می‌گیرد؟

خیر. HTTPS ارتباط Transport را ایمن‌تر می‌کند اما نمی‌گوید Server مجاز بوده به آن Destination متصل شود.

آیا Firewall جلوی SSRF را می‌گیرد؟

Inbound Firewall به‌تنهایی خیر. Egress Filtering و Network Segmentation در SSRF اهمیت ویژه دارند.

آیا Cloud Serverها بیشتر در معرض خطر SSRF هستند؟

ماهیت آسیب‌پذیری یکسان است، اما وجود Metadata Service، Internal API و Cloud Credentials می‌تواند Impact یک SSRF را در بعضی Cloud Architectureها افزایش دهد.

IMDSv2 چیست؟

IMDSv2 نسخه Session-oriented سرویس Metadata در Amazon EC2 است و AWS آن را به‌عنوان حفاظت قوی‌تر در برابر برخی مسیرهای سوءاستفاده، از جمله سناریوهای SSRF، توصیه می‌کند.

آیا IMDSv2 SSRF را رفع می‌کند؟

خیر. IMDSv2 یک Defense in Depth است. Application آسیب‌پذیر همچنان باید Patch شود.

SSRF در WordPress چگونه ایجاد می‌شود؟

معمولاً زمانی که Plugin، Theme یا Custom Endpoint یک URL کنترل‌شده توسط User را بدون کنترل کافی با WordPress HTTP API یا Client دیگری Fetch کند.

برای URLهای تحت کنترل User در WordPress چه کنیم؟

WordPress برای Requestهای Arbitrary URL توابعی مانند wp_safe_remote_get() و wp_safe_remote_request() را ارائه کرده که URL و Redirectها را برای کاهش SSRF Risk اعتبارسنجی می‌کنند. در کنار آن‌ها باید Business Allowlist خود Application نیز اجرا شود.

آیا Sanitize کردن URL برای SSRF کافی است؟

خیر. Sanitization فقط شکل داده را اصلاح می‌کند. باید مشخص شود Destination از نظر Security Policy نیز مجاز است.

چرا Redirect در SSRF خطرناک است؟

چون Destination اولیه ممکن است Validation را Pass کند اما Request در ادامه به Destination دیگری Redirect شود. مقصد جدید نیز باید Validate شود.

بهترین روش جلوگیری از SSRF چیست؟

بهترین راه یک کنترل منفرد نیست؛ باید Defense in Depth شامل کمینه‌کردن URLهای User-controlled، Allowlist، URL Parsing، DNS/IP Validation، Redirect Control، Egress Filtering، Network Segmentation، Least Privilege و Monitoring اجرا شود.

جمع‌بندی

حمله SSRF یا Server-Side Request Forgery یکی از آسیب‌پذیری‌های مهم امنیت وب و API است که در آن Application تحت تأثیر ورودی User از طرف Server به Destination غیرمنتظره درخواست ارسال می‌کند.

خطر اصلی این ضعف از تفاوت سطح دسترسی User و Server ناشی می‌شود.

ممکن است یک User اینترنتی نتواند مستقیماً به Private API، Management Interface، Microservice یا Cloud Resource متصل شود، اما Backend Server چنین Network Reachability داشته باشد.

در چنین شرایطی Server آسیب‌پذیر می‌تواند ناخواسته به واسطه‌ای برای عبور از Trust Boundary تبدیل شود.

در OWASP Top 10:2025، SSRF دیگر مانند نسخه 2021 یک دسته مستقل نیست و CWE-918 در دسته A01 Broken Access Control ادغام شده است. این تغییر طبقه‌بندی به معنی کاهش اهمیت SSRF نیست و MITRE همچنان CWE-918 را به‌عنوان یک ضعف مشخص Server-Side Request Forgery تعریف می‌کند.

مهم‌ترین اقدام دفاعی این است که پیش از هر چیز بررسی شود آیا User واقعاً باید URL کامل را کنترل کند یا خیر. اگر Business Logic اجازه دهد، بهتر است Destinationها Server-side تعریف شوند.

در صورت نیاز واقعی به Remote URL، باید چند لایه امنیتی اجرا شود:

URL با Parser استاندارد تحلیل شود، Scheme و Port محدود شوند، Host و DNS براساس Policy بررسی شوند، Redirect کنترل شود و در صورت امکان Destinationها در Allowlist قرار گیرند.

در کنار Application Security، Infrastructure نیز اهمیت زیادی دارد.

Egress Filtering و Network Segmentation می‌توانند جلوی دسترسی Server به بخش‌هایی را بگیرند که برای فعالیت عادی Application لازم نیستند. Internal Serviceها نیز نباید صرفاً به دلیل قرارداشتن در شبکه خصوصی بدون Authentication و Authorization باشند.

در WordPress نیز Developer باید هنگام کار با URLهای کنترل‌شده توسط User از Safe HTTP API مناسب استفاده کند. مستندات رسمی WordPress صریحاً توضیح می‌دهند که wp_safe_remote_get() و wp_safe_remote_request() URL و Redirectها را با هدف جلوگیری از SSRF اعتبارسنجی می‌کنند.

در Cloud نیز مکانیزم‌هایی مانند AWS IMDSv2 می‌توانند Blast Radius را کاهش دهند، اما همچنان نباید جایگزین Patch اصلی Application شوند. AWS نیز IMDSv2 را به‌عنوان Defense in Depth در برابر دسته‌ای از سناریوها از جمله SSRF معرفی کرده است.