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

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

قانون آزمایشگاه: تمام تست‌های عملی این مقاله را فقط روی برنامه‌ای که خودتان راه‌اندازی کرده‌اید یا مجوز کتبی آزمون آن را دارید اجرا کنید. برای تمرین، از فایل‌های بی‌خطر و نشانه‌های آزمایشی استفاده می‌کنیم؛ نیازی به آپلود شِل مخرب یا اجرای کد روی سرور واقعی نیست.

۱. آپلود فایل چگونه کار می‌کند؟

در یک برنامه وب، کاربر فایلی را انتخاب می‌کند و مرورگر معمولاً آن را در قالب درخواست multipart/form-data به سرور می‌فرستد.

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

اصطلاحات کلیدی

نکته مهم: هیچ‌کدام از پسوند، MIME Type یا Magic Bytes به‌تنهایی تضمین امنیت نیستند. اعتبارسنجی باید چندلایه باشد.

۲. انواع آسیب‌پذیری‌های آپلود فایل

۲.۱. اعتبارسنجی ناقص پسوند

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

۲.۲. اعتماد بیش از حد به MIME Type

مقدار Content-Type در درخواست می‌تواند توسط کاربر تغییر کند. این مقدار صرفاً یک ادعاست و نباید تنها معیار پذیرش فایل باشد.

۲.۳. ذخیره فایل در مسیر اجرایی

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

۲.۴. نام فایل و مسیر ذخیره‌سازی ناامن

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

۲.۵. فایل‌های چندقالبی و پردازش ناامن

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

۲.۶. دسترسی غیرمجاز به فایل آپلودشده

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

۳. آماده‌سازی آزمایشگاه تست نفوذ

برای این آموزش دو مسیر تمرین پیشنهاد می‌شود.

مسیر اول: آزمایشگاه آنلاین آموزشی

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

از آزمایشگاه File Upload در PortSwigger Web Security Academy استفاده کنید. درس‌ها و لاب‌های این مجموعه از اعتبارسنجی ناقص تا بررسی نحوه ارائه فایل را پوشش می‌دهند.

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

مناسب برای تحلیل درخواست‌ها و بررسی تنظیمات سرور

به Kali Linux یا یک سیستم معمولی، مرورگر، Burp Suite Community و یک برنامه آزمایشی آسیب‌پذیر نیاز دارید. ماشین مجازی را از شبکه‌های حساس جدا کنید و سرویس آزمایشی را فقط روی سیستم محلی در دسترس قرار دهید.

ابزارهای موردنیاز

نصب ابزارهای پایه در Kali Linux:

sudo apt update
sudo apt install -y curl file xxd

برای نصب Burp Suite از وب‌سایت رسمی PortSwigger استفاده کنید.

۴. شناسایی نقطه آپلود و ساخت خط مبنا

پیش از هر آزمایش، باید رفتار عادی برنامه را بشناسید.

فرض کنید برنامه آزمایشگاهی شما در نشانی http://127.0.0.1:8080 اجرا شده و صفحه‌ای برای آپلود تصویر دارد.

مرحله اول: بررسی درخواست عادی

یک تصویر معمولی با پسوند .png آپلود کنید و موارد زیر را ثبت کنید:

• آدرس و متد درخواست، مانند POST.

• نام پارامتر فایل، مثلاً avatar.

• مقدار Content-Type درخواست و بخش فایل.

• کد وضعیت HTTP، مانند 200، 302 یا 400.

• پیام موفقیت یا خطای برنامه.

• نام و مسیر عمومی فایل ذخیره‌شده، اگر قابل مشاهده باشد.

• اینکه آیا کاربر دیگری می‌تواند فایل را دریافت کند یا خیر.

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

مرحله دوم: ایجاد فایل‌های بی‌خطر

در سیستم آزمایشگاهی، یک فایل متنی و یک تصویر معتبر بسازید:

mkdir -p ~/file-upload-lab
cd ~/file-upload-lab

printf 'ZeroOne Cyber Lab - harmless test\n' > note.txt
file note.txt
xxd -l 32 note.txt

برای تصویر، از یک فایل PNG واقعی استفاده کنید؛ تغییر نام یک فایل متنی به .png تصویر معتبر ایجاد نمی‌کند.

حالا یک درخواست پایه با curl ارسال کنید. نام avatar و مسیر /upload نمونه هستند و باید با فرم واقعی آزمایشگاه خودتان تطبیق داده شوند:

curl -i \
  -F "avatar=@note.txt;type=text/plain" \
  http://127.0.0.1:8080/upload

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

مرحله سوم: تحلیل ترافیک با Burp Suite

نمونه ساختار یک درخواست آپلود:

POST /upload HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: multipart/form-data; boundary=LabBoundary

--LabBoundary
Content-Disposition: form-data; name="avatar"; filename="note.txt"
Content-Type: text/plain

ZeroOne Cyber Lab - harmless test
--LabBoundary--

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

۵. آزمون‌های پیشرفته آپلود فایل

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

آزمون ۱: بررسی اعتبارسنجی پسوند

هدف این است که مشخص شود برنامه چگونه پسوند فایل را تفسیر می‌کند.

در آزمایشگاه، فایل‌های بی‌خطر زیر را بررسی کنید:

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

1. آیا درخواست به سرور رسید؟

2. آیا سرور فایل را پذیرفت یا رد کرد؟

3. آیا نام فایل در پاسخ تغییر کرد؟

4. آیا فایل واقعاً ذخیره شد؟

5. آیا نتیجه با سیاست اعلام‌شده برنامه مطابقت داشت؟

نکته تخصصی: پذیرفته‌شدن یک نام غیرمنتظره لزوماً به معنی آسیب‌پذیری بحرانی نیست. باید مشخص کنید چه نوع محتوایی پذیرفته شده و چه پیامدی در سیستم دارد.

آزمون ۲: اعتبارسنجی MIME Type

درخواست آپلود معمولاً یک هدر Content-Type برای بخش فایل دارد. این هدر ممکن است با قالب واقعی فایل سازگار نباشد.

در Burp Repeater، فقط روی فایل‌های آزمایشی خودتان، نوع اعلام‌شده را تغییر دهید و رفتار سرور را مقایسه کنید.

مثلاً:

Content-Disposition: form-data; name="avatar"; filename="note.txt"
Content-Type: image/png

محتوای فایل همچنان متن ساده است؛ صرفاً هدر آن را به PNG تبدیل کرده‌ایم.

نتیجه مورد انتظار از یک پیاده‌سازی امن: برنامه نباید تنها بر اساس این هدر تصمیم بگیرد که فایل واقعاً یک تصویر معتبر است. نوع محتوا باید در سمت سرور و متناسب با کاربرد فایل بررسی شود.

آزمون ۳: مقایسه پسوند با محتوای واقعی

این آزمایش را با سه فایل انجام دهید:

• یک PNG معتبر.

• یک فایل متنی با پسوند .txt.

• همان فایل متنی که فقط نام آن به .png تغییر کرده است.

برای مشاهده نوع فایل در لینوکس:

file valid-image.png
file note.txt
file renamed-image.png

نام renamed-image.png در مثال آخر باید به فایل متنی تغییرنام‌یافته اشاره کند.

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

آزمون ۴: بررسی نام فایل و مسیر ذخیره‌سازی

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

موارد قابل بررسی:

• نام‌های بسیار طولانی.

• نام‌های دارای فاصله و کاراکترهای Unicode.

• نام‌های دارای کاراکترهای کنترلی یا جداکننده‌های مسیر.

• نام تکراری برای دو آپلود متوالی.

• نام‌های دارای چند پسوند.

• تفاوت رفتار سیستم در نام‌گذاری و ذخیره‌سازی.

برای آزمایش، از نام‌های بی‌خطر استفاده کنید و رفتار رد یا پاک‌سازی نام‌ها را ثبت کنید. هدف این نیست که روی فایل‌های واقعی سیستم چیزی بازنویسی شود؛ هدف بررسی کنترل‌های ورودی و اثبات ایمن نقص است.

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

آزمون ۵: بررسی اجرای فایل در سرور

این آزمون از مهم‌ترین بخش‌های ارزیابی است.

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

بررسی کنید:

• فایل در مسیر عمومی وب ذخیره می‌شود یا خارج از آن؟

• آیا مسیر ذخیره‌سازی تحت کنترل مفسر PHP، ASP.NET یا فناوری مشابه قرار دارد؟

• پاسخ سرور فایل را دانلود می‌کند یا آن را به‌صورت محتوا نمایش می‌دهد؟

• آیا فایل آپلودشده از مبدأی جداگانه ارائه می‌شود؟

• آیا تنظیمات وب‌سرور اجرای کد را در مسیر آپلود غیرفعال کرده‌اند؟

در آزمایشگاه امن، این موضوع را از طریق تنظیمات سرور و یک فایل نشانگر بی‌خطر بررسی کنید؛ برای اثبات نقص نیازی به ساخت web shell یا اجرای دستور سیستم‌عامل نیست.

آزمون ۶: کنترل دسترسی به فایل‌ها

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

با دو حساب آزمایشی، A و B، بررسی کنید:

1. حساب A یک فایل خصوصی آپلود کند.

2. حساب A فایل را از طریق قابلیت مجاز برنامه دریافت کند.

3. حساب B همان شناسه یا URL را امتحان کند.

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

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

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

آزمون ۷: محدودیت اندازه و مصرف منابع

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

موارد بررسی:

• حداکثر اندازه فایل در برنامه.

• محدودیت درخواست در وب‌سرور و پراکسی.

• محدودیت تعداد آپلود برای هر کاربر.

• فضای ذخیره‌سازی مصرف‌شده.

• اندازه فایل پس از استخراج یا پردازش.

• امکان ارسال هم‌زمان چند درخواست آپلود.

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

آزمون ۸: پردازش تصویر و سند

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

در این مرحله مشخص کنید:

• کدام کتابخانه فایل را پردازش می‌کند؟

• آیا نسخه کتابخانه به‌روز و پشتیبانی‌شده است؟

• آیا پردازش در محیط محدودشده انجام می‌شود؟

• آیا فایل اصلی بدون بررسی مجدد منتشر می‌شود؟

• آیا فایل‌های خروجی نیز اعتبارسنجی می‌شوند؟

• آیا زمان و حافظه مصرفی پردازش محدود است؟

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

۶. ماتریس ارزیابی تست نفوذ

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

۷. سناریوی نهایی: آیا آپلود فایل می‌تواند به اجرای کد منجر شود؟

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

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

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

۸. چگونه آسیب‌پذیری آپلود فایل را رفع کنیم؟

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

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

نمونه پیکربندی دفاعی در PHP

نمونه زیر یک الگوی ساده برای اعتبارسنجی اولیه تصویر است. این کد به‌تنهایی یک سامانه آپلود کامل یا تضمین امنیت نیست؛ کنترل دسترسی، محدودیت درخواست، ذخیره‌سازی خارج از Web Root و مدیریت خطا نیز باید پیاده‌سازی شوند.

<?php
// Example: validate an uploaded PNG or JPEG.

if (!isset($_FILES['avatar'])) {
    http_response_code(400);
    exit('No file received');
}

$file = $_FILES['avatar'];

if ($file['error'] !== UPLOAD_ERR_OK) {
    http_response_code(400);
    exit('Upload failed');
}

$maxBytes = 2 * 1024 * 1024;

if ($file['size'] <= 0 || $file['size'] > $maxBytes) {
    http_response_code(400);
    exit('Invalid file size');
}

$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file($file['tmp_name']);

$allowed = [
    'image/png'  => 'png',
    'image/jpeg' => 'jpg',
];

if (!isset($allowed[$mime])) {
    http_response_code(415);
    exit('Unsupported file type');
}

if (@getimagesize($file['tmp_name']) === false) {
    http_response_code(415);
    exit('Invalid image');
}

// Generate a server-side filename.
// Store outside the web root with restricted permissions.
$filename = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];

echo 'Initial validation passed';

در این نمونه، فایل هنوز ذخیره نشده است؛ این کار عمدی است. مسیر نهایی ذخیره‌سازی باید از قبل تعیین شده، خارج از Web Root باشد و با کنترل دسترسی مناسب مدیریت شود. همچنین در سامانه واقعی بهتر است تصویر با یک کتابخانه معتبر بازخوانی و به خروجی جدید تبدیل شود و فایل موقت پس از پایان پردازش به‌درستی مدیریت شود.

۹. تعیین شدت آسیب‌پذیری و نوشتن گزارش

برای گزارش تست نفوذ، از شدت بر اساس شواهد استفاده کنید، نه صرفاً نام آسیب‌پذیری.

شدت نهایی را با توجه به امکان بهره‌برداری، سطح دسترسی لازم، محرمانگی و یکپارچگی داده‌ها و اثر بر دسترس‌پذیری تعیین کنید.

قالب گزارش برای کاربران صفر و یک سایبر

۱۰. برنامه تمرین هفت‌روزه

۱۱. منابع تکمیلی برای سطح حرفه‌ای

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

مطالعه راهنما

PortSwigger Web Security Academy

برای ادامه تمرین، درس‌های File Upload و لاب‌های تعاملی آن را به ترتیب سطح دشواری انجام دهید.

مشاهده درس و آزمایشگاه‌ها

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

مشاهده راهنمای آزمون امنیت وب

آزمون پایانی دوره

قبل از اینکه خودتان را برای تست نفوذ آپلود فایل آماده بدانید، باید بتوانید به این پنج پرسش پاسخ دهید:

1. چرا تغییر Content-Type در درخواست HTTP نباید برای عبور از اعتبارسنجی کافی باشد؟

2. تفاوت میان آپلود موفق فایل و اجرای موفق کد روی سرور چیست؟

3. چرا ذخیره فایل خارج از Web Root یک کنترل دفاعی مهم است؟

4. چگونه ثابت می‌کنید فایل خصوصی کاربر A برای کاربر B قابل دسترسی نیست؟

5. برای اینکه یک یافته از «رفتار غیرمنتظره» به «آسیب‌پذیری اثبات‌شده» تبدیل شود، چه شواهدی لازم است؟

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