تصور کنید وارد یک سایت می‌شوید و فقط برای تغییر عکس پروفایل، یک فایل آپلود می‌کنید.

همه‌چیز عادی به نظر می‌رسد…

اما اگر برنامه هیچ بررسی درستی روی فایل انجام ندهد، همین قابلیت ساده می‌تواند به یک نقطه ضعف امنیتی جدی تبدیل شود. 😳

آسیب‌پذیری Unrestricted File Upload یکی از مباحث مهم در امنیت برنامه‌های وب است؛ زیرا یک سیستم آپلود ناامن ممکن است اجازه دهد فایل‌هایی با نوع، محتوا یا نام نامناسب وارد سرور شوند.

در این قسمت، داخل یک آزمایشگاه کاملاً قانونی با Kali Linux و DVWA بررسی می‌کنیم:

• File Upload چیست؟
• چرا آپلود فایل خطرناک می‌شود؟
• یک سیستم آپلود امن چه کنترل‌هایی دارد؟
• چگونه در DVWA رفتار Upload را بررسی کنیم؟
• چگونه Request آپلود را با Burp Suite تحلیل کنیم؟
• MIME Type، Extension و Content Validation چه تفاوتی دارند؟
• چگونه از Upload Vulnerability جلوگیری کنیم؟

⚠️ هشدار: تمام آزمایش‌های این مقاله فقط روی DVWA یا سیستم‌هایی انجام شود که مالک آن هستید یا مجوز تست آن را دارید. هرگز فایل اجرایی یا Shell را روی سرور واقعی بدون مجوز آپلود نکنید.

File Upload چیست؟

File Upload قابلیتی است که به کاربر اجازه می‌دهد یک فایل را از سیستم خود انتخاب و به سرور ارسال کند.

مثلاً:

User
  ↓
Select File
  ↓
Browser
  ↓
HTTP Request
  ↓
Web Server
  ↓
Storage

نمونه‌های رایج File Upload:

• تصویر پروفایل
• مدارک
• فایل PDF
• فایل رزومه
• فایل‌های آموزشی
• تصاویر محصولات
• فایل‌های پیوست

خود قابلیت Upload یک آسیب‌پذیری نیست.

مشکل زمانی ایجاد می‌شود که برنامه فایل دریافت‌شده را بدون کنترل‌های امنیتی مناسب ذخیره یا پردازش کند.

چرا File Upload می‌تواند خطرناک باشد؟

فرض کنید برنامه فقط این موضوع را بررسی کند:

Filename ends with .jpg

این کنترل به‌تنهایی کافی نیست.

چون امنیت فایل فقط به نام آن وابسته نیست.

یک فایل می‌تواند:

• Extension نامناسب داشته باشد
• MIME Type غیرمنتظره داشته باشد
• محتوای غیرعادی داشته باشد
• نام خطرناک داشته باشد
• حجم بسیار زیادی داشته باشد
• شامل محتوای فعال باشد
• در مسیر قابل اجرای Server ذخیره شود

بنابراین باید چند لایه کنترل در کنار یکدیگر قرار بگیرند.

ساختار یک Upload ناامن

یک طراحی ضعیف ممکن است تقریباً چنین مسیری داشته باشد:

User File
    ↓
Upload
    ↓
Check Filename
    ↓
Save Directly
    ↓
Web Root

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

ساختار Upload امن

یک معماری بهتر:

User File
    ↓
Authentication
    ↓
Authorization
    ↓
Size Validation
    ↓
Extension Validation
    ↓
MIME Validation
    ↓
Content Validation
    ↓
Random Filename
    ↓
Non-Executable Storage
    ↓
Access Control

هر مرحله یک لایه دفاعی ایجاد می‌کند.

آزمایشگاه مورد نیاز

برای این آموزش:

┌──────────────────────────┐
│       Kali Linux         │
│                          │
│ Browser                  │
│ Burp Suite               │
│ Nmap                     │
└────────────┬─────────────┘
             │
       Host-Only Network
             │
┌────────────▼─────────────┐
│           DVWA           │
│                          │
│ 192.168.56.20            │
└──────────────────────────┘

IP بالا فقط یک مثال است.

IP واقعی DVWA خودتان را جایگزین کنید.

🔒 بهتر است DVWA فقط در شبکه آزمایشگاهی قابل دسترسی باشد و مستقیماً روی اینترنت قرار نگیرد.

مرحله اول: شناسایی سرویس

ابتدا در Kali ارتباط با سیستم آزمایشگاهی را بررسی کنید:

ping 192.168.56.20

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

nmap -sV -p 80,443 192.168.56.20

اگر HTTP فعال باشد، مرورگر را باز کنید:

http://192.168.56.20

مرحله دوم: ورود به File Upload در DVWA

پس از ورود به DVWA، بخش:

File Upload

را باز کنید.

برای شروع:

Security Level = Low

قرار دهید.

هدف این مرحله این نیست که فوراً به سراغ Exploitation برویم.

اول باید بفهمیم:

برنامه هنگام دریافت یک فایل دقیقاً چه کاری انجام می‌دهد؟

مرحله سوم: آپلود یک فایل سالم

ابتدا یک تصویر معمولی انتخاب کنید.

مثلاً:

test.jpg

آن را Upload کنید.

بعد از Upload، موارد زیر را بررسی کنید:

Upload Result
File Name
File Path
Response
Status Code

اگر برنامه اعلام کرد Upload موفق بوده، باید ببینیم فایل کجا ذخیره شده است.

چرا مسیر ذخیره فایل مهم است؟

فرض کنید فایل در چنین مسیری قرار گرفته باشد:

/uploads/test.jpg

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

بنابراین یک سؤال مهم مطرح می‌شود:

آیا فایل آپلودشده در یک محل قابل اجرای Server ذخیره شده یا فقط قابل دانلود/نمایش است؟

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

مرحله چهارم: تحلیل Request با Burp Suite

حالا Burp Suite را فعال کنید.

فایل را مجدداً Upload کنید و Request را مشاهده کنید.

یک Upload معمولاً از:

multipart/form-data

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

ساختار ساده Request:

POST /dvwa/vulnerabilities/upload/ HTTP/1.1
Host: 192.168.56.20
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

و داخل Body ممکن است چیزی شبیه این باشد:

------WebKitFormBoundary
Content-Disposition: form-data; name="uploaded"; filename="test.jpg"
Content-Type: image/jpeg

[FILE DATA]

------WebKitFormBoundary

چه چیزهایی را باید بررسی کنیم؟

در Burp به این قسمت‌ها دقت کنید:

Filename

filename="test.jpg"

Content-Type

Content-Type: image/jpeg

Request Method

معمولاً:

POST

Upload Parameter

نام پارامتری که فایل را ارسال می‌کند.

مثلاً:

uploaded

نکته مهم: Filename قابل اعتماد نیست

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

مثلاً:

test.jpg

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

نام فایل توسط Client ارسال می‌شود و Client قابل اعتماد نیست.

بنابراین:

هر چیزی که از سمت کاربر می‌آید باید غیرقابل اعتماد فرض شود.

Extension Validation چیست؟

Extension همان پسوند فایل است.

مثلاً:

photo.jpg
document.pdf
avatar.png

یک برنامه می‌تواند Extensionهای مجاز را محدود کند.

مثلاً:

.jpg
.jpeg
.png
.webp

اما:

Extension Validation به‌تنهایی کافی نیست.

MIME Type چیست؟

MIME Type مشخص می‌کند داده ارسالی چه نوع محتوایی دارد.

برای تصویر JPEG معمولاً:

image/jpeg

و برای PNG:

image/png

دیده می‌شود.

اما نکته مهم:

MIME Type ارسالی توسط Client هم به‌تنهایی قابل اعتماد نیست.

بنابراین نباید تنها بر اساس Header تصمیم امنیتی گرفت.

Content Validation

یک سیستم امن‌تر باید خود محتوای فایل را نیز بررسی کند.

برای مثال اگر انتظار داریم فایل یک تصویر باشد، Server می‌تواند ساختار واقعی فایل را بررسی کند.

به زبان ساده:

Extension
      +
MIME
      +
File Content

باید با یکدیگر سازگار باشند.

مرحله پنجم: بررسی محدودیت حجم

یکی دیگر از مشکلات رایج Upload، نبود محدودیت مناسب برای حجم فایل است.

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

5 MB

آپلود کند.

اما Server هیچ محدودیتی نداشته باشد.

در این شرایط یک فایل بسیار بزرگ می‌تواند منابع:

• CPU
• RAM
• Disk
• Bandwidth

را مصرف کند.

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

مثلاً:

Maximum File Size = 5 MB

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

مرحله ششم: نام فایل

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

مثلاً:

profile.jpg

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

مثلاً:

a81f92c7.jpg

یا یک شناسه تصادفی امن.

ساختار بهتر:

User Filename
      ↓
Server Generates Random Name
      ↓
Secure Storage

این کار می‌تواند از برخی مشکلات مربوط به نام فایل و برخورد نام‌ها جلوگیری کند.

مرحله هفتم: Path Traversal و نام فایل

یکی از موارد مهم در File Handling، نحوه استفاده از نام فایل و مسیر آن است.

برنامه نباید اجازه دهد ورودی کاربر مستقیماً به مسیر فایل تبدیل شود.

به‌عنوان یک مفهوم دفاعی:

User Input
      ↓
Filename
      ↓
Path Construction

این قسمت باید کاملاً کنترل شود.

بهترین روش این است که Server خودش نام و مسیر نهایی را تولید کند و ورودی کاربر را مستقیماً به Path تبدیل نکند.

مرحله هشتم: محل ذخیره فایل

یکی از مهم‌ترین نکات امنیتی این است که فایل‌های Upload شده کجا ذخیره شوند.

اگر فایل‌های غیرقابل اعتماد در یک مسیر قابل اجرای Web Server قرار بگیرند، ریسک افزایش پیدا می‌کند.

معماری امن‌تر:

Application
     ↓
Upload
     ↓
Non-Executable Storage
     ↓
Controlled Download

یعنی فایل به‌عنوان داده ذخیره شود، نه چیزی که Server بتواند آن را به‌عنوان برنامه اجرا کند.

چرا اجرای فایل مهم است؟

فرض کنید Server فایل‌های آپلودشده را در مسیر Web Root قرار دهد.

اگر تنظیمات Server به‌گونه‌ای باشد که برخی فایل‌ها را اجرا کند، یک Upload آسیب‌پذیر می‌تواند از یک مشکل ساده File Upload به یک مشکل بسیار جدی‌تر تبدیل شود.

به همین دلیل:

آپلود فایل و اجرای فایل باید از یکدیگر جدا باشند.

مرحله نهم: بررسی File Upload با Repeater

حالا Request آپلود را به:

Repeater

ارسال کنید.

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

به‌خصوص:

filename
Content-Type
Content-Length
multipart boundary
Response

را بررسی کنید.

هدف این مرحله شناخت منطق Upload است.

مرحله دهم: بررسی سطح امنیتی DVWA

سطح DVWA را تغییر دهید:

Low

سپس:

Medium

و در صورت امکان:

High

را بررسی کنید.

حالا یک فایل سالم را در هر سطح Upload کنید و ببینید:

• چه Extensionهایی قبول می‌شوند؟
• آیا MIME بررسی می‌شود؟
• آیا محدودیت حجم وجود دارد؟
• پیام خطا چگونه تغییر می‌کند؟
• مسیر ذخیره فایل تغییر می‌کند؟

این مقایسه برای درک Security Controls بسیار ارزشمند است.

چرا فقط یک کنترل کافی نیست؟

فرض کنید برنامه فقط Extension را بررسی کند:

Extension Check

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

اگر فقط MIME بررسی شود:

MIME Check

باز هم کافی نیست.

اگر فقط Content بررسی شود:

Content Check

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

امنیت مناسب یعنی:

Authentication
        +
Authorization
        +
Extension Validation
        +
MIME Validation
        +
Content Validation
        +
Size Limit
        +
Random Filename
        +
Safe Storage
        +
Non-Execution

🛡️ چگونه File Upload را امن کنیم؟

۱. فقط Extensionهای مورد نیاز را مجاز کنید

مثلاً اگر سایت فقط عکس نیاز دارد:

.jpg
.jpeg
.png
.webp

را مجاز کنید.

هر Extension اضافی را نپذیرید.

۲. MIME Type را بررسی کنید

نوع فایل را بررسی کنید.

اما به یاد داشته باشید:

MIME ارسالی از Client به‌تنهایی معیار امنیتی قابل اعتمادی نیست.

۳. محتوای واقعی فایل را بررسی کنید

برای تصاویر، از ابزارها و کتابخانه‌های معتبر Server-Side برای تشخیص و پردازش تصویر استفاده کنید.

۴. نام فایل را خود Server تولید کند

از نام کاربر مستقیماً به‌عنوان نام نهایی فایل استفاده نکنید.

۵. فایل را خارج از Web Root ذخیره کنید

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

۶. اجرای Script را در Upload Directory غیرفعال کنید

اگر Upload Directory وجود دارد، باید طوری پیکربندی شود که فایل‌های آپلودشده به‌عنوان Script اجرا نشوند.

این موضوع به Web Server و معماری برنامه بستگی دارد.

۷. محدودیت حجم اعمال کنید

مثلاً:

Maximum = 5 MB

اما مقدار مناسب را بر اساس نیاز واقعی سیستم تعیین کنید.

۸. دسترسی کاربر را بررسی کنید

قبل از Upload باید مشخص شود:

Who can upload?
What can they upload?
Where can it be stored?
Who can access it?

این موضوع به Authorization مربوط است.

۹. فایل را مجدداً پردازش کنید

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

مثلاً:

Original Image
      ↓
Image Processing
      ↓
New Image
      ↓
Safe Storage

این روش می‌تواند بخشی از محتوای غیرضروری فایل اصلی را حذف کند.

۱۰. خطاهای حساس را نمایش ندهید

پیام‌هایی مثل مسیر داخلی Server یا جزئیات Exception نباید به کاربر نمایش داده شوند.

به جای:

/var/www/html/uploads/...

یک پیام عمومی نمایش دهید:

Upload failed.

و جزئیات را در لاگ مناسب ثبت کنید.

File Upload و XSS

یک نکته جالب این است که File Upload می‌تواند در بعضی سناریوها با XSS نیز ارتباط داشته باشد.

مثلاً اگر برنامه:

• فایل HTML را قبول کند
• محتوای SVG را بدون کنترل مناسب نمایش دهد
• نام فایل را ناامن در صفحه قرار دهد
• Metadata فایل را بدون Encoding نمایش دهد

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

بنابراین File Upload فقط مسئله «نوع فایل» نیست.

بلکه باید به:

Upload
Storage
Rendering
Download
Execution

هم توجه کرد.

File Upload و Denial of Service

آپلود فایل‌های بسیار بزرگ یا تعداد زیادی فایل می‌تواند منابع سرور را مصرف کند.

به همین دلیل باید مواردی مانند:

File Size Limit
Rate Limit
Storage Quota
Authentication
Upload Frequency

در نظر گرفته شوند.

File Upload و Access Control

فرض کنید کاربر A یک فایل آپلود کرده است.

آیا کاربر B می‌تواند آن را مشاهده یا حذف کند؟

این سؤال به Broken Access Control مربوط می‌شود.

یک سیستم امن باید مشخص کند:

User A
   ↓
Own File

User B
   ↓
Access Denied

پس امنیت Upload فقط به زمان آپلود محدود نمی‌شود.

بعد از Upload نیز کنترل دسترسی اهمیت دارد.

🔍 چک‌لیست تست امنیت File Upload

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

[ ] Authentication
[ ] Authorization
[ ] Allowed Extensions
[ ] MIME Validation
[ ] Content Validation
[ ] Maximum File Size
[ ] Filename Handling
[ ] Random Filename
[ ] Storage Location
[ ] Script Execution Disabled
[ ] Download Access Control
[ ] File Overwrite Protection
[ ] Rate Limiting
[ ] Error Handling
[ ] Logging

🧪 تمرین عملی در DVWA

حالا یک تمرین کامل انجام دهید.

مرحله ۱

DVWA را اجرا کنید.

مرحله ۲

Security Level را روی Low قرار دهید.

مرحله ۳

یک تصویر سالم Upload کنید.

مرحله ۴

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

مرحله ۵

پارامترهای Upload را شناسایی کنید.

مرحله ۶

Response را بررسی کنید.

مرحله ۷

محل ذخیره فایل را مشخص کنید.

مرحله ۸

Security Level را تغییر دهید.

مرحله ۹

رفتار برنامه را مقایسه کنید.

مرحله ۱۰

در نهایت مشخص کنید چه کنترل‌های امنیتی وجود دارند و چه کنترل‌هایی ضعیف یا غایب هستند.

📋 قالب گزارش آسیب‌پذیری File Upload

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

Target:
DVWA

Target IP:
192.168.56.20

Vulnerability:
Unrestricted File Upload

Endpoint:
...

HTTP Method:
POST

Upload Parameter:
...

Allowed Extension:
...

MIME Validation:
Yes / No

Content Validation:
Yes / No

File Size Limit:
Yes / No

Storage Location:
...

Execution Risk:
...

Observed Behavior:
...

Impact:
...

Root Cause:
Insufficient File Validation

Recommended Remediation:
Extension Allowlist
MIME Validation
Content Validation
Random Filename
Safe Storage
Disable Script Execution
Size Limitation
Access Control

🚨 اشتباهات رایج توسعه‌دهندگان

اشتباه اول: اعتماد به Extension

.jpg

به‌تنهایی اثبات نمی‌کند فایل امن است.

اشتباه دوم: اعتماد به MIME Type

Header ارسال‌شده توسط Client معیار کافی نیست.

اشتباه سوم: ذخیره فایل با نام اصلی

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

اشتباه چهارم: ذخیره در مسیر قابل اجرا

فایل Upload شده باید تا حد امکان در محیطی ذخیره شود که قابلیت اجرای Script نداشته باشد.

اشتباه پنجم: نداشتن محدودیت حجم

File Upload بدون Size Limit می‌تواند به مشکل منابع منجر شود.

اشتباه ششم: فراموش کردن Authorization

باید بررسی شود چه کسی اجازه Upload، مشاهده، تغییر یا حذف فایل را دارد.

🎯 جمع‌بندی

File Upload یکی از قابلیت‌های عادی و ضروری بسیاری از سایت‌هاست؛ اما اگر بدون طراحی امنیتی مناسب پیاده‌سازی شود، می‌تواند به یک نقطه ضعف جدی تبدیل شود.

در این قسمت یاد گرفتیم که هنگام بررسی File Upload باید به چندین لایه توجه کنیم:

User
 ↓
Authentication
 ↓
Authorization
 ↓
Extension
 ↓
MIME
 ↓
Content
 ↓
Size
 ↓
Filename
 ↓
Storage
 ↓
Execution
 ↓
Access Control

مهم‌ترین اصل:

هر فایل آپلودشده را غیرقابل اعتماد فرض کنید.

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