🔥 وقتی خودِ Server تبدیل به ابزار مهاجم می‌شود!

تصور کن یک سایت از تو یک URL می‌گیرد:

https://example.com/image.jpg

سرور این URL را دریافت می‌کند و خودش به آن درخواست می‌فرستد.

در حالت عادی همه‌چیز طبیعی است.

اما اگر کاربر بتواند سرور را مجبور کند به یک مقصد داخلی درخواست بفرستد چه؟

مثلاً:

http://127.0.0.1/

یا یک سرویس داخلی آزمایشگاه:

http://192.168.56.20/

اینجاست که وارد دنیای SSRF می‌شویم.

⚠️ تمام تست‌های این آموزش فقط باید روی آزمایشگاه شخصی، سرویس‌های ساختگی یا سامانه‌ای که مجوز تست آن را دارید انجام شود.

1. SSRF چیست؟

SSRF مخفف:

Server-Side Request Forgery

است.

در SSRF، مهاجم تلاش می‌کند برنامه‌ای که روی Server اجرا می‌شود را وادار کند به مقصدی که مهاجم انتخاب کرده درخواست ارسال کند.

به زبان ساده:

حالت عادی:

User
 ↓
Website
 ↓
Internet Resource

اما در SSRF:

Attacker
   ↓
Website
   ↓
Server
   ↓
Internal / External Resource

نکته مهم این است که:

درخواست از طرف Server ارسال می‌شود، نه مستقیماً از طرف Browser.

2. یک مثال ساده

فرض کنید یک برنامه قابلیت دریافت تصویر از URL دارد:

URL:
https://example.com/image.jpg

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

User URL
   ↓
Application
   ↓
HTTP Request
   ↓
Target Server
   ↓
Response
   ↓
Application
   ↓
User

اگر برنامه URL را بدون کنترل مناسب قبول کند، ممکن است کاربر بتواند مقصد درخواست را تغییر دهد.

3. چرا SSRF خطرناک است؟

شدت SSRF به محیط و دسترسی Server بستگی دارد.

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

مثلاً:

🌐 Public Website
        │
        ▼
   Application
        │
        ├── Internet
        │
        ├── Internal Server
        │
        ├── Internal API
        │
        └── Local Service

بنابراین SSRF در شرایط خاص می‌تواند باعث:

• دسترسی به سرویس‌های داخلی
• مشاهده اطلاعاتی که نباید عمومی باشند
• تعامل با APIهای داخلی
• شناسایی سطحی سرویس‌های داخلی
• دور زدن برخی محدودیت‌های شبکه

شود.

Impact واقعی باید بر اساس چیزی که در محیط مجاز آزمایش شده تعیین شود.

4. SSRF با Open Redirect چه تفاوتی دارد؟

این دو را نباید با هم اشتباه گرفت.

Open Redirect

کاربر را به مقصد دیگری Redirect می‌کند:

User
 ↓
Website
 ↓
Redirect
 ↓
Another Website

SSRF

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

User
 ↓
Website
 ↓
Server
 ↓
Target

در SSRF، Server نقش درخواست‌کننده را دارد.

5. SSRF مستقیم چیست؟

در نوع ساده، Response مقصد مستقیماً به کاربر برگردانده می‌شود.

مثلاً:

User
 ↓
URL Parameter
 ↓
Server
 ↓
Target
 ↓
Response
 ↓
User

فرض کنیم یک Endpoint آزمایشگاهی داریم:

/fetch?url=https://example.com

اگر Backend URL را دریافت و Fetch کند، نقطه‌ای برای بررسی SSRF داریم.

6. SSRF کور یا Blind SSRF چیست؟

گاهی Server درخواست را ارسال می‌کند اما Response را به کاربر نشان نمی‌دهد.

در این حالت:

User
 ↓
Application
 ↓
Target

ولی:

Target Response
      X
      ↓
    User

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

به این حالت:

Blind SSRF

می‌گوییم.

تشخیص Blind SSRF معمولاً به یک کانال مشاهده یا لاگ در محیط آزمایشگاهی نیاز دارد.

7. ساختار یک SSRF

فرآیند کلی را این‌طور تصور کنید:

┌──────────────┐
│    User      │
└──────┬───────┘
       │
       │ URL
       ▼
┌──────────────┐
│ Web Server   │
└──────┬───────┘
       │
       │ HTTP Request
       ▼
┌──────────────┐
│ Target       │
│ Resource     │
└──────────────┘

در یک برنامه امن، Server باید قبل از ارسال Request بررسی کند:

Is this destination allowed?

8. چه ورودی‌هایی می‌توانند SSRF ایجاد کنند؟

SSRF فقط در پارامتر url اتفاق نمی‌افتد.

نقاط احتمالی عبارت‌اند از:

url=
uri=
target=
dest=
redirect=
link=
image=
callback=
webhook=
endpoint=
feed=

همچنین ممکن است URL داخل JSON ارسال شود:

{
  "url": "https://example.com"
}

یا:

{
  "webhook": "https://example.com/callback"
}

وجود چنین پارامتری به معنی آسیب‌پذیری نیست؛ فقط نقطه‌ای است که باید بررسی شود.

9. SSRF در Webhookها

Webhookها یکی از نمونه‌های جالب هستند.

فرض کنید یک برنامه اجازه می‌دهد:

Webhook URL:
https://example.com/callback

سرور باید به این URL درخواست ارسال کند.

اگر کنترل مناسبی وجود نداشته باشد، این قابلیت ممکن است به یک SSRF Sink تبدیل شود.

معماری:

User
 ↓
Webhook URL
 ↓
Application Server
 ↓
HTTP Request
 ↓
Destination

10. SSRF در Image Fetcher

فرض کنید سایت قابلیتی دارد:

Import Image From URL

کاربر:

https://example.com/logo.png

را وارد می‌کند.

Backend:

Download URL
      ↓
Server HTTP Client
      ↓
Download Resource

اگر URL بدون Validation مناسب پردازش شود، باید احتمال SSRF بررسی شود.

11. آزمایشگاه SSRF

برای این قسمت بهتر است یک Web App آزمایشگاهی بسیار ساده داشته باشیم.

ساختار:

┌─────────────────────────┐
│       Kali Linux        │
│                         │
│ Browser + Burp Suite    │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│   Vulnerable Web App    │
│                         │
│      URL Fetcher        │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│ Internal Test Service   │
│       127.0.0.1         │
└─────────────────────────┘

این محیط کاملاً محلی است.

12. اولین درخواست

فرض کنیم برنامه آزمایشگاهی Endpoint زیر را دارد:

GET /fetch?url=https://example.com HTTP/1.1
Host: lab.local

برنامه URL را دریافت می‌کند و Server آن را Fetch می‌کند.

حالا درخواست را در:

Burp Suite → HTTP history

مشاهده می‌کنیم.

13. ارسال Request به Repeater

Request را انتخاب کنید:

Right Click
    ↓
Send to Repeater

در Repeater می‌توانیم Request را کنترل‌شده بررسی کنیم.

مثلاً:

GET /fetch?url=https://example.com HTTP/1.1

هدف ما بررسی رفتار Backend است.

14. تست مقصد محلی در آزمایشگاه

در یک محیط کاملاً کنترل‌شده می‌توانیم مقصد را به سرویس محلی آزمایشگاه تغییر دهیم:

http://127.0.0.1/

یا در صورت نیاز:

http://localhost/

سپس Response را مقایسه می‌کنیم.

اگر Server بتواند منبع محلی را Fetch کند، یک رفتار مهم برای بررسی SSRF داریم.

15. چرا 127.0.0.1 مهم است؟

آدرس:

127.0.0.1

به سیستم محلی اشاره می‌کند.

یعنی:

127.0.0.1
    ↓
Same Host

اگر یک Web Application روی Server اجرا شود، درخواست به:

http://127.0.0.1/

ممکن است به خود همان Server برسد.

به همین دلیل در SSRF، مقصدهای Local و Internal اهمیت زیادی دارند.

16. Private IP چیست؟

برخی محدوده‌های IP برای شبکه‌های خصوصی استفاده می‌شوند.

مثلاً:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

در یک آزمایشگاه ممکن است ساختار شبکه‌ای مثل این داشته باشیم:

192.168.56.10
192.168.56.20
192.168.56.30

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

17. تفاوت External و Internal Request

External

Server
 ↓
Internet
 ↓
Public Website

Internal

Server
 ↓
Private Network
 ↓
Internal Service

مشکل SSRF زمانی جدی‌تر می‌شود که Server بتواند منابعی را ببیند که کاربر مستقیماً نمی‌تواند ببیند.

18. بررسی Response

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

Status Code
Response Length
Content-Type
Response Body
Redirect
Response Time

مثلاً:

Target A
→ 200 OK

Target B
→ 403 Forbidden

Target C
→ Timeout

این تفاوت‌ها می‌توانند اطلاعاتی درباره رفتار Backend در اختیار تستر قرار دهند.

اما:

تفاوت Response به‌تنهایی اثبات SSRF نیست؛ باید مشخص شود درخواست واقعاً از Server ارسال شده است.

19. SSRF و Redirect

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

https://allowed.example

اما مقصد با Redirect تغییر کند:

Allowed URL
     ↓
Redirect
     ↓
Another Destination

اگر برنامه فقط URL اولیه را بررسی کند و مقصد نهایی را کنترل نکند، ممکن است Validation دور زده شود.

بنابراین هنگام طراحی دفاع:

Redirectها نیز باید در نظر گرفته شوند.

20. SSRF و DNS Rebinding

یکی از مباحث پیشرفته‌تر SSRF:

DNS Rebinding

است.

در این تکنیک، یک نام دامنه می‌تواند در شرایط خاص به IPهای متفاوت Resolve شود.

به صورت مفهومی:

Domain
 ↓
DNS Resolution
 ↓
Public IP

و بعد:

Same Domain
 ↓
DNS Resolution
 ↓
Internal IP

به همین دلیل صرفاً بررسی اولیه DNS یا IP ممکن است کافی نباشد.

برای پیاده‌سازی دفاعی، باید چرخه کامل Resolution و Connection به‌دقت مدیریت شود.

21. SSRF و Metadata Services

در برخی زیرساخت‌های Cloud، سرویس‌های داخلی برای Metadata وجود دارند.

این سرویس‌ها ممکن است اطلاعاتی درباره محیط اجرای ماشین ارائه کنند.

به همین دلیل:

Application Server
        ↓
Internal Metadata Service

یکی از سناریوهای مهم در بحث SSRF است.

⚠️ در این آموزش وارد استخراج Credential یا اطلاعات حساس از سرویس‌های Cloud نمی‌شویم. این بخش را فقط به عنوان مفهوم معماری و ریسک امنیتی در نظر بگیرید و آزمایش‌ها را روی سرویس ساختگی خودتان انجام دهید.

22. SSRF فقط HTTP نیست

در برخی برنامه‌ها URL Handlerهای مختلف پشتیبانی می‌شوند.

ممکن است Backend با Schemeهای مختلف کار کند.

بنابراین هنگام طراحی یک سیستم امن نباید فرض کنیم:

Only HTTP

بلکه باید دقیقاً مشخص شود:

Which schemes are allowed?
Which protocols are required?

بهترین حالت:

فقط Protocol موردنیاز را Allow کنید.

23. SSRF در APIها

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

مثلاً:

POST /api/import HTTP/1.1
Content-Type: application/json

Body:

{
  "source": "https://example.com/data.json"
}

اگر Backend این URL را Fetch کند:

JSON
 ↓
API
 ↓
Server HTTP Client
 ↓
URL

باید SSRF را به عنوان یک ریسک احتمالی بررسی کنیم.

24. پیدا کردن SSRF Sink

در تست نفوذ دنبال جاهایی باشید که:

User Input
       ↓
URL Parser
       ↓
HTTP Client
       ↓
Server Request

نمونه قابلیت‌ها:

Import URL
Image Downloader
Webhook
PDF Generator
URL Preview
Remote File Fetch
RSS Importer
External API Connector

این‌ها نقطه‌های احتمالی هستند، نه آسیب‌پذیری قطعی.

25. Burp Suite در تست SSRF

Burp Suite برای این قسمت بسیار کاربردی است.

فرآیند:

Browser
 ↓
Burp Proxy
 ↓
Request
 ↓
Repeater
 ↓
Modify URL
 ↓
Send
 ↓
Compare Response

در Repeater می‌توانیم بدون تغییر برنامه، رفتار Request را در محیط آزمایشگاهی بررسی کنیم.

26. یک تست کنترل‌شده

فرض کنید Request اصلی:

GET /fetch?url=https://example.com HTTP/1.1

است.

در آزمایشگاه می‌توانیم ابتدا یک URL متعلق به سرویس خودمان قرار دهیم:

http://127.0.0.1:8080/

و Response را ثبت کنیم.

سپس یک سرویس تست داخلی دیگر را بررسی کنیم:

http://192.168.56.30:8080/

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

27. SSRF یا فقط URL Fetching؟

هر URL Fetcher آسیب‌پذیر نیست.

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

User Input
 ↓
Validate URL
 ↓
Resolve Host
 ↓
Check Destination
 ↓
Allowlist
 ↓
Connect
 ↓
Validate Redirect
 ↓
Return Data

داشته باشد.

بنابراین وجود قابلیت Fetch کردن URL به تنهایی Finding نیست.

28. روش امن جلوگیری از SSRF

یکی از مهم‌ترین دفاع‌ها:

Allowlist

به جای:

Allow Everything

از:

Allow Only Required Destinations

استفاده کنید.

مثلاً اگر برنامه فقط باید به:

api.example.com

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

29. Blocklist چرا کافی نیست؟

یک طراحی ضعیف:

Block:
127.0.0.1

اما:

Allow Everything Else

این روش می‌تواند در برابر روش‌های مختلف دور زدن Validation ضعیف باشد.

بهتر است:

Default Deny
+
Strict Allowlist

استفاده شود.

30. کنترل IP

Server باید مقصد را بررسی کند.

به صورت مفهومی:

URL
 ↓
Resolve
 ↓
IP
 ↓
Is IP Allowed?
 ↓
Yes → Continue
No  → Block

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

31. جلوگیری از Redirect Bypass

اگر برنامه Redirect را دنبال می‌کند:

URL A
 ↓
Redirect
 ↓
URL B

باید مقصد نهایی نیز دوباره بررسی شود.

یعنی:

Validate Initial URL
        ↓
Request
        ↓
Follow Redirect?
        ↓
Validate Destination Again

32. محدود کردن خروجی و منابع

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

• Timeout داشته باشیم
• Response Size محدود شود
• Content-Type بررسی شود
• تعداد Redirect محدود شود
• Connection محدود شود
• Protocol محدود شود

این کنترل‌ها علاوه بر امنیت SSRF می‌توانند به کاهش سوءاستفاده از منابع کمک کنند.

33. Network-Level Defense

امنیت فقط در Application نیست.

یک لایه دفاعی مهم:

Application
      ↓
Network Firewall
      ↓
Egress Filtering
      ↓
Allowed Destinations

حتی اگر یک Bug در Application وجود داشته باشد، محدود کردن خروجی Network می‌تواند Impact را کاهش دهد.

34. Principle of Least Privilege

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

اگر یک Application فقط به:

API Server

نیاز دارد، نباید بتواند به همه:

Internal Network

متصل شود.

این همان مفهوم:

Least Privilege

است.

35. ثبت Log و Monitoring

برای تشخیص رفتارهای مشکوک، درخواست‌های خروجی Server را مانیتور کنید.

موارد مهم:

Destination Host
Destination IP
Port
Protocol
Timestamp
Application
Response Status

اگر یک Application ناگهان شروع به اتصال به مقصدهای غیرمعمول کند، لاگ‌ها می‌توانند به شناسایی رفتار مشکوک کمک کنند.

36. نمونه Finding در گزارش Pentest

عنوان

Server-Side Request Forgery (SSRF)

Severity

Medium / High

شدت نهایی به Impact و دسترسی Server بستگی دارد.

Description

The application accepts a user-controlled URL and
performs a server-side request without sufficient
destination validation.

Impact

An attacker may potentially cause the application
server to interact with unintended internal or
external resources.

Evidence

در گزارش باید موارد زیر ثبت شوند:

Original Request
Modified Request
Response
Affected Endpoint
Test Environment

37. Remediation

راهکارهای اصلی:

✅ Allowlist destinations
✅ Validate hostname
✅ Validate resolved IP
✅ Block unauthorized private/loopback destinations
✅ Validate redirects
✅ Restrict protocols
✅ Apply network egress filtering
✅ Use timeouts
✅ Limit response size
✅ Apply least privilege
✅ Log outbound requests

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

38. چک‌لیست تست SSRF

Discovery

• URL Fetcher وجود دارد؟

• Webhook وجود دارد؟

• Remote Import وجود دارد؟

• Image Fetcher وجود دارد؟

• API دارای URL ورودی است؟

Validation

• URL Validation وجود دارد؟

• Hostname بررسی می‌شود؟

• IP بررسی می‌شود؟

• Loopback مسدود است؟

• Private Network کنترل شده؟

• Redirect بررسی می‌شود؟

• Protocol محدود شده؟

Infrastructure

• Egress Filtering وجود دارد؟

• Server دسترسی غیرضروری به شبکه داخلی ندارد؟

• سرویس‌های داخلی از Application جدا شده‌اند؟

• Logging فعال است؟

39. تمرین عملی قسمت ۱۳

در یک Web App آزمایشگاهی:

مرحله ۱

یک قابلیت URL Fetcher ایجاد یا استفاده کنید.

مرحله ۲

یک URL عمومی و بی‌خطر آزمایشگاهی را وارد کنید.

مرحله ۳

Request را با Burp Suite مشاهده کنید.

مرحله ۴

Request را به Repeater بفرستید.

مرحله ۵

URL را به سرویس محلی آزمایشگاه تغییر دهید:

http://127.0.0.1/

مرحله ۶

Response را مقایسه کنید.

مرحله ۷

یک سرویس ساختگی روی شبکه خصوصی آزمایشگاه قرار دهید.

مرحله ۸

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

مرحله ۹

رفتار را مستند کنید.

مرحله ۱۰

راهکار دفاعی پیشنهاد دهید.

40. تمرین حرفه‌ای‌تر

دو سرویس آزمایشگاهی ایجاد کنید:

Web App
192.168.56.20

و:

Internal Test Service
192.168.56.30

سپس بررسی کنید:

External Resource
       ↓
Allowed?

Local Resource
       ↓
Allowed?

Internal Resource
       ↓
Allowed?

نتیجه را در یک جدول ثبت کنید:

Destination	Expected	Actual	Result
External Test Service	Allowed	؟	؟
Local Test Service	Denied	؟	؟
Internal Test Service	Denied	؟	؟

41. چیزی که یک Pentester حرفه‌ای باید بفهمد

در SSRF هدف فقط این نیست که:

«من توانستم URL را تغییر بدهم.»

هدف اصلی این است که مشخص کنیم:

User Input
     ↓
Server-Side Request
     ↓
Unexpected Destination
     ↓
Unauthorized Network Reachability

اگر این زنجیره اثبات شود، می‌توانیم Impact واقعی را بهتر ارزیابی کنیم.

42. تفاوت SSRF با RCE

SSRF و RCE یکی نیستند.

SSRF

Server
 ↓
Unintended Request

RCE

Attacker
 ↓
Code Execution
 ↓
Server

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

43. زنجیره آسیب‌پذیری

در تست نفوذ ممکن است چند ضعف کنار هم قرار بگیرند:

SSRF
 ↓
Internal Service Access
 ↓
Another Vulnerability
 ↓
Higher Impact

به همین دلیل یک Pentester نباید فقط یک Finding را جدا از معماری کلی سیستم بررسی کند.

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

44. جمع‌بندی قسمت ۱۳

در این قسمت با یکی از جذاب‌ترین آسیب‌پذیری‌های Web Security آشنا شدیم:

💀 Server-Side Request Forgery

یاد گرفتیم:

🔴 SSRF چیست
🔴 چرا Server در این حمله نقش مهمی دارد
🔴 SSRF مستقیم و Blind SSRF چیست
🔴 URL Fetcherها و Webhookها چرا مهم هستند
🔴 چگونه Request را با Burp Suite تحلیل کنیم
🔴 نقش 127.0.0.1 و شبکه‌های خصوصی چیست
🔴 چرا Redirectها باید بررسی شوند
🔴 SSRF در APIها چگونه ممکن است ایجاد شود
🔴 چرا Allowlist بهتر از Blocklist است
🔴 چگونه Egress Filtering به دفاع کمک می‌کند
🔴 چگونه SSRF را در گزارش Pentest ثبت کنیم

و مهم‌تر از همه:

گاهی مهاجم مستقیماً به Server دسترسی ندارد؛ فقط کاری می‌کند که خود Server به جای او درخواست بفرستد.