امنیت آپلود فایل در سایت؛ چگونه از آپلود فایل مخرب جلوگیری کنیم؟

امنیت آپلود فایل در سایت یعنی اطمینان از اینکه کاربران فقط فایل‌هایی را بارگذاری می‌کنند که از نظر نوع، محتوا، اندازه، نام، سطح دسترسی و محل ذخیره‌سازی با سیاست امنیتی سایت سازگار هستند. برای جلوگیری از آپلود فایل مخرب نباید فقط به پسوند فایل اعتماد کرد؛ بلکه باید Allowlist نوع فایل، بررسی MIME و File Signature، تغییر نام فایل، محدودیت حجم، ذخیره خارج از Web Root، کنترل دسترسی، اسکن بدافزار و اعتبارسنجی سمت سرور را به‌صورت هم‌زمان اجرا کرد. OWASP نیز تأکید می‌کند که هیچ کنترل واحدی برای امن‌سازی File Upload کافی نیست و باید از رویکرد Defense in Depth استفاده شود.

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

اما همین قابلیت ظاهراً ساده می‌تواند یکی از حساس‌ترین ورودی‌های یک وب‌سایت باشد.

تفاوت Upload با بسیاری از Inputهای معمولی این است که در اینجا کاربر می‌تواند یک فایل کامل را وارد زیرساخت شما کند. این فایل ممکن است روی Disk ذخیره شود، توسط Image Processor پردازش شود، برای کاربران دیگر نمایش داده شود، توسط Antivirus بررسی شود، به Object Storage منتقل شود یا حتی توسط یک سرویس Backend باز و Parse شود.

در نتیجه، اگر فرایند Upload به‌درستی طراحی نشده باشد، مهاجم ممکن است تلاش کند فایلی وارد سیستم کند که اصلاً نباید پذیرفته شود.

ریسک فقط به «آپلود یک فایل اجرایی» محدود نیست.

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

• باعث مصرف بیش از حد فضای ذخیره‌سازی شود؛
• Parser یک کتابخانه را درگیر کند؛
• حاوی محتوای فعال سمت مرورگر باشد؛
• نام فایل مخربی داشته باشد؛
• باعث Overwrite یک فایل دیگر شود؛
• در اختیار کاربران دیگر قرار بگیرد؛
• برای Phishing یا انتشار محتوای غیرمجاز استفاده شود؛
• یا بخشی از حمله Denial of Service باشد.

بنابراین سؤال صحیح این نیست که «چطور یک پسوند خاص را Block کنیم؟»

سؤال صحیح این است:

چطور معماری Upload را به شکلی طراحی کنیم که فایل ورودی حتی در صورت مخرب بودن نتواند به‌سادگی به Application، Server یا کاربران دیگر آسیب بزند؟

در این مقاله از رخنه‌کاو، امنیت آپلود فایل در سایت را از همین زاویه بررسی می‌کنیم.

چرا آپلود فایل یکی از ورودی‌های پرریسک سایت است؟

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

هر چیزی که از سمت Client دریافت می‌شود باید Untrusted یا غیرقابل اعتماد در نظر گرفته شود.

این اصل درباره:

• Form Input
• Header
• Cookie
• URL Parameter
• JSON Body
• API Request
• Filename
• MIME Type
• File Content

صدق می‌کند.

فایل Upload شده نیز کاملاً تحت کنترل کاربر است.

مدیر سایت ممکن است در ظاهر فرم نوشته باشد:

«فقط تصویر JPG انتخاب کنید.»

اما این نوشته هیچ ضمانت امنیتی ایجاد نمی‌کند.

حتی اگر در HTML از ویژگی accept استفاده شود، این ویژگی بیشتر برای هدایت User Experience طراحی شده است. MDN صراحتاً توضیح می‌دهد که accept اعتبارسنجی واقعی نوع فایل نیست و باید کنترل مناسب در سمت Server نیز انجام شود.

یعنی چیزی شبیه:

accept="image/*"

نباید کنترل امنیتی اصلی شما باشد.

مهاجم الزاماً از همان فرم سایت استفاده نمی‌کند.

او می‌تواند Request را مستقیماً به Endpoint ارسال کند.

به همین دلیل اعتبارسنجی Client-Side برای تجربه کاربر مفید است، اما Security Validation باید سمت سرور انجام شود.

MDN نیز در راهنمای Input Validation تأکید می‌کند که مهاجم می‌تواند Frontend را دور بزند و داده دلخواه خود را مستقیماً برای سرور ارسال کند.

مهم‌ترین خطرات آپلود فایل مخرب چیست؟

برای طراحی یک سیستم امن ابتدا باید Threat Model داشته باشیم.

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

اجرای محتوای غیرمجاز

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

این اتفاق به نوع فناوری، تنظیمات Server، Framework و محل ذخیره فایل بستگی دارد.

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

Stored XSS از طریق فایل

برخی File Typeها می‌توانند Active Content داشته باشند.

اگر Application فایلی را بدون سیاست مناسب دریافت و سپس مستقیماً در اختیار Browser کاربران قرار دهد، ممکن است خطرات Client-Side مانند Cross-Site Scripting مطرح شوند.

بنابراین «فایل قابل دانلود بودن» لزوماً به معنی «فایل بی‌خطر بودن» نیست.

سوءاستفاده از Parserها

Application ممکن است فایل Upload شده را Process کند.

برای مثال:

• Image Resizing
• PDF Parsing
• Document Preview
• Metadata Extraction
• Archive Extraction
• Thumbnail Generation

در این حالت فایل وارد یک Library یا Parser می‌شود.

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

OWASP نیز سوءاستفاده از آسیب‌پذیری‌های File Parserها و Processing Moduleها را در میان تهدیدات File Upload ذکر می‌کند.

پر کردن فضای ذخیره‌سازی

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

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

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

• Disk پر شود؛
• Backupها بزرگ شوند؛
• هزینه Object Storage افزایش پیدا کند؛
• پردازش Server سنگین شود؛
• Application از دسترس خارج شود.

بنابراین File Size Limit فقط یک مسئله UX نیست؛ یک کنترل امنیتی و عملیاتی است.

Archive Bomb و فایل‌های فشرده

فایل فشرده ممکن است روی Disk کوچک باشد اما پس از Extract شدن حجم بسیار زیادی تولید کند.

به همین دلیل اگر Application واقعاً نیازمند دریافت ZIP یا Archive است، فقط محدودیت حجم فایل فشرده کافی نیست.

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

• Uncompressed Size
• تعداد فایل‌ها
• Compression Ratio
• عمق Directory
• مسیرهای استخراج

نیز کنترل شوند.

OWASP نیز توصیه می‌کند پیش از Extract کردن ZIP، حجم تخمینی خروجی، مسیر و ویژگی‌های مرتبط بررسی شوند.

Overwrite فایل‌های موجود

اگر Filename مستقیماً توسط کاربر مشخص شود، خطر Collision یا Overwrite مطرح می‌شود.

مثلاً دو کاربر فایل‌هایی با نام یکسان ارسال کنند.

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

به همین دلیل استفاده از Filename تولیدشده توسط Application اهمیت زیادی دارد.

Directory Traversal از طریق نام فایل

Filename نیز Input کاربر است.

اگر Application نام فایل را بدون Normalization و Validation در Path قرار دهد، ممکن است تلاش‌هایی برای دست‌کاری مسیر ذخیره‌سازی صورت گیرد.

بنابراین Client نباید مسیر نهایی File Storage را مشخص کند.

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

میزبانی محتوای مخرب یا غیرقانونی

Upload Endpoint می‌تواند به یک File Hosting رایگان تبدیل شود.

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

• صفحات جعلی
• محتوای Phishing
• بدافزار
• محتوای غیرقانونی
• فایل‌های دارای Copyright
• محتوای نامناسب

استفاده کند.

به‌خصوص زمانی که File URL عمومی و قابل اشتراک‌گذاری باشد، این موضوع اهمیت بیشتری دارد.

OWASP این تهدید را نیز برای سیستم‌هایی که فایل Upload شده را Publicly Retrievable می‌کنند مطرح می‌کند.

اصل اول؛ فقط فایل‌های موردنیاز را Allow کنید

یکی از مهم‌ترین اصول امنیت Application استفاده از Allowlist است.

Allowlist یعنی به‌جای اینکه ده‌ها نوع فایل خطرناک را لیست کرده و Block کنیم، فقط File Typeهایی را قبول کنیم که واقعاً Application به آن‌ها نیاز دارد.

فرض کنید یک سایت فقط امکان آپلود تصویر پروفایل دارد.

آیا منطقی است:

• PDF
• ZIP
• HTML
• SVG
• Document
• Video
• Script

را هم بپذیرد؟

خیر.

اگر نیاز کسب‌وکار فقط تصویر است، سطح دسترسی Upload باید متناسب با همین نیاز باشد.

OWASP نیز Allowlist کردن Extensionهای موردنیاز کسب‌وکار را به‌عنوان یکی از اولین کنترل‌های File Upload توصیه می‌کند.

چرا Blocklist به‌تنهایی کافی نیست؟

Blocklist یعنی بگوییم:

«این پسوندها ممنوع‌اند و بقیه مجاز هستند.»

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

• File Typeهای بسیار زیادی وجود دارند؛
• تنظیم Server ممکن است تغییر کند؛
• Parserها متفاوت هستند؛
• انواع ترکیبی و کمتر شناخته‌شده وجود دارند؛
• احتمال فراموش کردن یک Extension زیاد است.

در نتیجه Blocklist می‌تواند یک کنترل ثانویه باشد، اما نباید کنترل اصلی File Upload باشد.

مدل بهتر:

فقط فرمت‌های موردنیاز را Accept کن و هر چیز دیگری را Reject کن.

آیا بررسی پسوند فایل کافی است؟

خیر.

Extension Validation ضروری است، اما کافی نیست.

برای مثال نام یک فایل ممکن است نشان دهد تصویر است، ولی محتوای داخلی با انتظارات Application سازگار نباشد.

بنابراین تصمیم امنیتی نباید فقط بر مبنای:

filename.jpg

گرفته شود.

حداقل چند لایه باید با یکدیگر مقایسه شوند:

1. Extension
2. MIME Type
3. File Signature
4. Parser Validation
5. Business Rules

بررسی پسوند چگونه انجام شود؟

Extension باید پس از Normalization و پردازش صحیح Filename بررسی شود.

در سیستم‌های حساس بهتر است:

• Filename Decode شود؛
• Case Normalize شود؛
• تعداد Extensionها بررسی شود؛
• فقط Extensionهای Allowlist شده پذیرفته شوند؛
• نام‌های غیرعادی Reject شوند.

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

هدف مقاله رخنه‌کاو آموزش Bypass نیست، اما نکته دفاعی روشن است:

از Regular Expressionهای ساده و Validationهای سطحی برای تشخیص File Type استفاده نکنید.

MIME Type چیست و آیا می‌توان به آن اعتماد کرد؟

MIME Type نشان می‌دهد محتوای فایل از چه نوعی است.

برای مثال یک فایل ممکن است با MIME زیر ارسال شود:

image/jpeg

یا:

application/pdf

اما یک مسئله مهم وجود دارد:

Content-Type موجود در Upload Request از سمت Client می‌آید.

بنابراین قابل اعتماد نیست.

OWASP صراحتاً توصیه می‌کند از Content-Type برای بررسی اولیه استفاده شود، اما نباید به آن به‌عنوان کنترل امنیتی مستقل اعتماد کرد، زیرا قابل جعل است.

پس یک Architecture صحیح نباید چنین منطقی داشته باشد:

اگر Content-Type == image/jpeg
فایل امن است

بلکه باید بگوید:

Extension مورد انتظار است؟
MIME تشخیص‌داده‌شده سمت سرور درست است؟
File Signature معتبر است؟
Parser فایل را واقعاً به‌عنوان تصویر می‌شناسد؟
ابعاد و حجم منطقی است؟

File Signature یا Magic Bytes چیست؟

بسیاری از File Formatها در ابتدای Data خود Signature مشخصی دارند.

این امضا به Application کمک می‌کند بفهمد Content واقعاً با فرمت ادعاشده سازگار است یا خیر.

بررسی File Signature از اعتماد صرف به Filename بهتر است.

با این حال OWASP تأکید می‌کند که Signature Validation نیز نباید به‌تنهایی استفاده شود.

چرا؟

چون ممکن است File ساختار پیچیده‌ای داشته باشد یا بخشی از آن همچنان محتوای دیگری را حمل کند.

به همین دلیل دوباره به Defense in Depth می‌رسیم.

بهترین روش بررسی تصاویر Upload شده چیست؟

تصویر یکی از رایج‌ترین انواع Upload است.

کاربران معمولاً می‌توانند:

• Avatar
• تصویر محصول
• Banner
• Screenshot
• تصویر مقاله

را Upload کنند.

در این شرایط یک روش دفاعی مناسب این است که فایل واقعاً با Library پردازش تصویر Decode شود.

اگر Application فقط به JPG و PNG نیاز دارد:

1. Extension بررسی شود.
2. MIME واقعی تشخیص داده شود.
3. تصویر Decode شود.
4. Width و Height بررسی شود.
5. Metadata غیرضروری حذف شود.
6. تصویر دوباره Encode شود.
7. خروجی جدید با Filename تصادفی ذخیره شود.

OWASP نیز Image Rewriting را به‌عنوان روشی برای بررسی تصویر و حذف محتوای اضافی پیشنهاد می‌کند.

چرا Re-encoding تصویر مفید است؟

در Re-encoding شما فایل اولیه را مستقیماً Publish نمی‌کنید.

Application محتوای تصویری را Decode کرده و یک فایل جدید تولید می‌کند.

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

• Metadata اضافه را حذف کند؛
• ساختار فایل را Normalize کند؛
• برخی Payloadهای غیرمرتبط با تصویر را کنار بگذارد؛
• خروجی استانداردتری ایجاد کند.

البته Image Processing Library خود نیز باید:

• به‌روز باشد؛
• Secure Configuration داشته باشد؛
• در محیط محدود اجرا شود.

SVG چرا نیازمند توجه بیشتری است؟

SVG با JPEG یا PNG متفاوت است.

SVG مبتنی بر XML است و می‌تواند قابلیت‌های بسیار بیشتری نسبت به یک Bitmap ساده داشته باشد.

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

اگر SVG برای پروژه ضروری است باید:

• از Sanitizer تخصصی استفاده شود؛
• Featureهای غیرضروری حذف شوند؛
• Script و External Referenceها محدود شوند؛
• MIME صحیح ارسال شود؛
• CSP مناسب وجود داشته باشد.

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

اگر یک File Type به امکانات فعال نیاز ندارد، نسخه ساده‌تر و کم‌ریسک‌تر آن را انتخاب کنید.

نام فایل کاربر را مستقیماً ذخیره نکنید

فرض کنید کاربر فایل زیر را Upload می‌کند:

my-photo.jpg

Application می‌تواند نام اصلی را برای Display نگه دارد، اما لازم نیست همین نام روی File System استفاده شود.

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

برای مثال مفهومی:

UUID + .jpg

این Identifier می‌تواند Random یا بر مبنای UUID باشد.

OWASP توصیه می‌کند Filename نهایی توسط Application تولید شود.

مزایای تغییر Filename چیست؟

این کار:

• احتمال Collision را کاهش می‌دهد؛
• Direct Guessing را سخت‌تر می‌کند؛
• خطر Filename Manipulation را کم می‌کند؛
• مدیریت Storage را ساده‌تر می‌کند؛
• User Input را از File System جدا می‌کند.

اگر مجبور باشیم Filename اصلی را نگه داریم چه کنیم؟

نام اصلی بهتر است فقط به‌عنوان Metadata در Database نگه داشته شود.

اگر استفاده از آن در File System اجتناب‌ناپذیر است:

• Maximum Length تعریف کنید؛
• Character Allowlist داشته باشید؛
• Control Characterها را حذف کنید؛
• Path Separatorها را نپذیرید؛
• نام‌های رزروشده سیستم‌عامل را مدیریت کنید؛
• Whitespace و Dotهای غیرعادی را Normalize کنید.

Filename یک رشته ساده نیست؛ Input امنیتی است.

فایل‌ها را کجا ذخیره کنیم؟

یکی از مهم‌ترین تصمیم‌ها در امنیت آپلود فایل در سایت محل ذخیره فایل است.

OWASP اولویت‌های زیر را مطرح می‌کند:

1. ذخیره روی Host جداگانه؛
2. اگر ممکن نیست، خارج از Web Root؛
3. اگر داخل Web Root است، کنترل‌های بسیار محدودکننده اعمال شود.

Web Root چیست؟

Web Root مسیری است که Web Server فایل‌های آن را مستقیماً از طریق HTTP ارائه می‌کند.

مثلاً اگر فایلی در Directory عمومی سایت قرار گیرد، احتمالاً URL مستقیمی برای آن ایجاد می‌شود.

مشکل زمانی رخ می‌دهد که فایل Upload شده در همان فضای Application قرار گیرد.

تفکیک Storage از Application باعث می‌شود فایل Upload شده نتواند به‌راحتی نقش Application Code را پیدا کند.

معماری بهتر Upload

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

User
↓
Upload Endpoint
↓
Authentication / Authorization
↓
Size & Type Validation
↓
Temporary Quarantine
↓
File Inspection
↓
Malware Scan
↓
Optional Re-encoding / CDR
↓
Generate Safe Filename
↓
Private/Object Storage
↓
Database Mapping
↓
Controlled Download Handler

در این مدل فایل مستقیماً از Request وارد Public Directory نمی‌شود.

استفاده از Object Storage امن‌تر است؟

Object Storage مانند سرویس‌های سازگار با S3 می‌تواند از نظر تفکیک Application و Storage مفید باشد.

اما خود Object Storage باید به‌درستی تنظیم شود.

اشتباه رایج این است که Bucket به‌صورت Public تنظیم شود.

در سیستم‌های دارای فایل خصوصی بهتر است:

• Bucket Private باشد؛
• Application دسترسی را کنترل کند؛
• Signed URL کوتاه‌مدت ایجاد شود؛
• Permissionها مبتنی بر Least Privilege باشند؛
• Logging فعال باشد.

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

امنیت همچنان به Access Control وابسته است.

اصل Least Privilege در File Upload

Least Privilege یعنی هر Component فقط حداقل Permission لازم را داشته باشد.

برای مثال Process مربوط به Upload نباید:

• امکان تغییر فایل‌های Application را داشته باشد؛
• به Configurationهای حساس دسترسی Write داشته باشد؛
• بتواند Binary اجرا کند؛
• به Secrets غیرضروری دسترسی داشته باشد.

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

اگر سرویس فقط Upload می‌کند، Permissionهای Admin اضافی منطقی نیستند.

محدودیت حجم فایل را جدی بگیرید

Upload Limit باید در چند Layer اعمال شود.

برای مثال:

• Reverse Proxy
• Web Server
• Framework
• Application
• Object Storage Policy

چرا چند لایه؟

فرض کنید فقط Application Limit داشته باشد.

Server ممکن است قبل از رسیدن Request به Application مجبور شود کل Body را دریافت کند.

بنابراین Resource Consumption همچنان اتفاق افتاده است.

حجم مناسب چقدر است؟

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

برای Avatar شاید چند MB کافی باشد.

برای Video Platform ممکن است چند GB منطقی باشد.

قاعده:

کوچک‌ترین Limitی را انتخاب کنید که Business Requirement را پوشش دهد.

تعداد Upload نیز باید Rate Limit شود

محدودیت حجم به‌تنهایی کافی نیست.

مثلاً اگر هر فایل حداکثر 5 MB باشد، مهاجم ممکن است هزاران File Request ارسال کند.

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

• Upload Per Minute
• Upload Per User
• Upload Per IP
• Daily Storage Quota
• Concurrent Upload
• Total Account Storage

Rate Limiting می‌تواند به کاهش Abuse و DoS کمک کند.

فقط کاربران مجاز باید بتوانند Upload کنند

اگر Upload نیازی به Anonymous User ندارد، آن را Public نگذارید.

OWASP نیز توصیه می‌کند فقط کاربران مجاز امکان Upload داشته باشند.

اما Authentication تنها قدم اول است.

Authorization نیز اهمیت دارد.

مثلاً:

• User معمولی فقط Avatar خودش را تغییر دهد.
• Vendor فقط تصاویر Product خودش را Upload کند.
• Editor فقط Media مربوط به Workspace خودش را ببیند.
• Support User نتواند Admin File را جایگزین کند.

آپلود فایل باید در برابر CSRF نیز محافظت شود

اگر Upload Endpoint با Session Cookie کار می‌کند، یک Request ناخواسته می‌تواند مشکل ایجاد کند.

OWASP در File Upload Cheat Sheet توصیه می‌کند Upload Endpointها در برابر CSRF نیز محافظت شوند.

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

• CSRF Token
• SameSite Cookie
• Origin Verification
• Framework Native Protection

باشد.

باز هم یک Layer به‌تنهایی جایگزین بقیه نیست.

Antivirus در امنیت آپلود فایل چه نقشی دارد؟

Antivirus یا Malware Scanner می‌تواند Layer مفیدی باشد.

ولی نباید منطق امنیتی چنین باشد:

Antivirus چیزی پیدا نکرد → فایل 100٪ امن است

هیچ Scannerی تمام Threatها را شناسایی نمی‌کند.

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

• Type Validation
• Signature Validation
• Storage Isolation
• Size Limit
• Access Control

استفاده شود.

OWASP نیز استفاده از Antivirus یا Sandbox را در صورت امکان پیشنهاد می‌کند.

فایل قبل از Scan کجا باشد؟

مدل مناسب استفاده از Quarantine است.

یعنی:

1. فایل دریافت شود.
2. به Temporary Private Storage برود.
3. هنوز Public نباشد.
4. Scan انجام شود.
5. نتیجه ثبت شود.
6. در صورت تأیید به Storage نهایی منتقل شود.

به این ترتیب فایل قبل از Scan در اختیار کاربران دیگر قرار نمی‌گیرد.

CDR چیست؟

CDR مخفف Content Disarm and Reconstruction است.

این روش برای File Typeهایی مانند:

• PDF
• DOCX
• Office Documents

می‌تواند مفید باشد.

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

OWASP استفاده از CDR را در File Typeهای مناسب پیشنهاد می‌کند.

CDR به‌خصوص در سازمان‌هایی که Document Upload بخش اصلی Workflow است اهمیت دارد.

Sandbox چه کاربردی دارد؟

در Applicationهای حساس فایل می‌تواند پیش از پذیرش نهایی در محیط Isolated بررسی شود.

Sandbox مانع آن می‌شود که Parser یا Process بررسی فایل مستقیماً روی Application Server اصلی اجرا شود.

بهتر است Processing Service:

• Containerized یا Isolated باشد؛
• Resource Limit داشته باشد؛
• Network Access محدود داشته باشد؛
• File System محدود داشته باشد؛
• Timeout داشته باشد.

اصل مهم:

حتی ابزار بررسی فایل نیز ممکن است آسیب‌پذیر باشد.

فایل ZIP را چگونه امن‌تر پردازش کنیم؟

اگر Business Requirement نیازی به ZIP ندارد، ساده‌ترین تصمیم امنیتی عدم پذیرش آن است.

اگر نیاز وجود دارد:

• تعداد Entryها محدود شود؛
• Total Uncompressed Size محدود باشد؛
• Compression Ratio بررسی شود؛
• Directory Traversal کنترل شود؛
• Extract Path توسط Server تعیین شود؛
• Symbolic Linkها مدیریت شوند؛
• Nested Archive محدود شود.

OWASP نیز به بررسی حجم، مسیر و ویژگی‌های Archive پیش از Extraction اشاره می‌کند.

Headerهای دانلود فایل نیز اهمیت دارند

امنیت Upload با ذخیره فایل تمام نمی‌شود.

نحوه Serve کردن فایل نیز مهم است.

سرور باید Content-Type صحیح ارسال کند.

OWASP در مورد تصاویر Upload شده نیز توصیه می‌کند فایل با Content-Type صحیح در اختیار Client قرار گیرد.

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

X-Content-Type-Options: nosniff

این Header به Browser می‌گوید MIME Type اعلام‌شده را رعایت کند و از MIME Sniffing خودداری کند.

برای فایل‌هایی که قرار نیست Inline Render شوند، استفاده از Download Behavior مناسب نیز می‌تواند ریسک را کاهش دهد.

فایل خصوصی نباید URL قابل حدس داشته باشد

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

/uploads/user-document-123.pdf

است.

اگر فایل خصوصی است، صرفاً داشتن URL متفاوت Access Control محسوب نمی‌شود.

Download Request باید Authorization داشته باشد.

معماری بهتر:

GET /download/84721

Application:

1. User را Authentication می‌کند؛
2. Permission را بررسی می‌کند؛
3. File ID را به Storage Object نگاشت می‌کند؛
4. سپس File را Stream یا Signed URL تولید می‌کند.

OWASP نیز پیشنهاد می‌کند برای Public Retrieval کنترل‌شده، Mapping بین Application Identifier و Filename Storage استفاده شود.

امنیت آپلود فایل در وردپرس

وردپرس سیستم استانداردی برای مدیریت Upload دارد.

توابع Core هنگام Upload عملیات مختلفی مانند Sanitization نام فایل، بررسی Extension و MIME و انتقال فایل به Upload Directory را انجام می‌دهند.

مستندات WordPress درباره _wp_handle_upload() توضیح می‌دهد که این فرایند شامل Sanitization Filename و بررسی Extension/MIME Type است.

توسعه‌دهندگان Plugin و Theme نباید بدون دلیل مکانیزم Upload مستقل و ناامن ایجاد کنند.

از APIهای رسمی WordPress استفاده کنید

توابع استاندارد مانند:

wp_handle_upload()

و در سناریوهای Media:

media_handle_upload()

برای ادغام با Upload System وردپرس طراحی شده‌اند.

مستندات رسمی WordPress امکان تنظیم MIMEهای مجاز و تست نوع فایل را در Upload Handling نشان می‌دهد.

هر نوع فایلی را در WordPress مجاز نکنید

گاهی مدیر سایت به دلیل خطای:

Sorry, you are not allowed to upload this file type

فیلتر MIME را کاملاً باز می‌کند.

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

اگر یک File Type موردنیاز است:

• دلیل نیاز مشخص شود؛
• Risk بررسی شود؛
• فقط همان Type Allow شود؛
• Handler مناسب برای آن وجود داشته باشد.

نقش wp-content/uploads چیست؟

وردپرس به‌طور معمول Mediaها را در Upload Directory ذخیره می‌کند.

این Directory باید طوری Configure شود که File Upload شده نتواند مانند Application Code رفتار کند.

در Hostingهای مختلف رفتار Server متفاوت است.

بنابراین مدیر سایت باید بررسی کند:

• Script Execution در Upload Directory غیرفعال باشد؛
• Directory Listing غیرضروری فعال نباشد؛
• Permission فایل‌ها مناسب باشد؛
• Sensitive Backupها در Upload Directory قرار نگیرند.

افزونه‌های Upload وردپرس را چگونه بررسی کنیم؟

Pluginهایی که قابلیت‌هایی مثل:

• فرم استخدام
• Ticket
• User Upload
• Frontend Post
• File Manager
• WooCommerce Attachment

اضافه می‌کنند، سطح حمله جدیدی ایجاد می‌کنند.

پیش از استفاده بررسی کنید:

• Plugin به‌روز است؟
• توسعه فعال دارد؟
• Upload Permission را بررسی می‌کند؟
• File Type را محدود می‌کند؟
• Security Patchهای قبلی داشته است؟
• کاربران Guest اجازه Upload دارند؟
• Upload Directory چگونه مدیریت می‌شود؟

در صورت عدم نیاز، قابلیت Upload را غیرفعال کنید.

آیا WAF می‌تواند جلوی File Upload مخرب را بگیرد؟

WAF می‌تواند لایه مفیدی باشد، اما جایگزین Secure Upload Design نیست.

WAF ممکن است:

• Request Size را محدود کند؛
• برخی Patternها را شناسایی کند؛
• Rate Limit اعمال کند؛
• رفتارهای غیرعادی را Block کند.

اما WAF نمی‌داند Business Logic شما دقیقاً چه File Typeهایی را باید بپذیرد.

بنابراین معماری صحیح:

WAF
+
Server Limits
+
Application Validation
+
Storage Isolation
+
Scanning

است.

CDN چه نقشی دارد؟

CDN می‌تواند در Serve فایل‌های Public کمک کند.

اما Upload مستقیم روی CDN یا Storage باید با Authentication مناسب انجام شود.

اگر از Presigned Upload استفاده می‌کنید:

• URL کوتاه‌عمر باشد؛
• Object Key توسط Server مشخص شود؛
• Size محدود شود؛
• Content Type Constraint داشته باشد؛
• Upload نهایی پس از Verification قابل Publish باشد.

مهاجم نباید بتواند صرفاً با داشتن یک Presigned URL هر Object دلخواهی در هر Path ایجاد کند.

Logging در File Upload بسیار مهم است

هر Upload مهم باید Audit Trail داشته باشد.

اطلاعات مناسب می‌تواند شامل:

• User ID
• Upload Time
• File ID
• Original Filename
• Stored Filename
• Detected Type
• Size
• Scan Result
• IP
• Processing Result

باشد.

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

چه Eventهایی باید Alert ایجاد کنند؟

مثلاً:

• تعداد زیاد Upload Reject شده؛
• تلاش مکرر برای File Type غیرمجاز؛
• فایل‌های بسیار بزرگ؛
• Scan Malware Detection؛
• افزایش ناگهانی Storage Usage؛
• خطای زیاد Parser؛
• افزایش Upload از یک User یا IP.

این داده‌ها می‌توانند نشانه Abuse باشند.

فایل Reject شده را نگه داریم یا حذف کنیم؟

در سیستم‌های معمولی بهتر است فایل Reject شده سریع و ایمن حذف شود.

در سازمان‌های Security-sensitive ممکن است برای Forensics نیاز به نگهداری محدود Quarantine وجود داشته باشد.

اگر چنین کاری انجام می‌شود:

• فایل Public نباشد؛
• Access بسیار محدود باشد؛
• Retention Policy وجود داشته باشد؛
• رمزگذاری Storage بررسی شود.

فایل مخرب نباید به دلیل Logging برای همیشه در Production باقی بماند.

بررسی Hash فایل چه کاربردی دارد؟

Hash می‌تواند برای:

• Duplicate Detection
• Integrity
• Malware Reputation
• Forensics

مفید باشد.

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

فایل جدید یا تغییرکرده ممکن است Hash ناشناخته داشته باشد.

همچنین ارسال Hash یا File به سرویس Third-party باید با سیاست Privacy و Confidentiality سازمان سازگار باشد.

OWASP نیز درباره احتمال Data Leakage هنگام استفاده از سرویس‌های عمومی بررسی فایل هشدار می‌دهد.

Content Validation براساس نوع فایل

هر File Type باید Validator مخصوص خود را داشته باشد.

تصویر

• Decode واقعی
• Dimension Limit
• Pixel Limit
• Re-encode
• Metadata Removal

PDF

• Parser امن
• Malware Scan
• CDR در محیط حساس
• محدودیت Size/Page
• جلوگیری از Featureهای غیرضروری

Office Document

• Malware Scan
• CDR
• Macro Policy
• Preview در محیط جدا

Archive

• Entry Count
• Uncompressed Size
• Path Validation
• Nested Archive Limit

یک Validator عمومی نمی‌تواند تمام این موارد را پوشش دهد.

فایل‌های Upload شده نباید Permission اجرایی داشته باشند

File System Permission بخشی مهم از Defense in Depth است.

دایرکتوری Upload معمولاً باید فقط Permissionهای موردنیاز برای Storage و Read را داشته باشد.

اگر Application نیازی به Execute ندارد، Execute Permission نباید داده شود.

Web Server نیز نباید Upload Directory را به‌عنوان محل اجرای Application Script در نظر بگیرد.

این موضوع مخصوصاً در Shared Hostingها و تنظیمات Legacy اهمیت زیادی دارد.

جداسازی Domain فایل‌ها چه مزیتی دارد؟

برخی Applicationهای بزرگ فایل‌های User Generated Content را از Domain جداگانه Serve می‌کنند.

مثلاً:

static.example-cdn.com

این کار می‌تواند Separation بیشتری ایجاد کند.

مزیت‌های احتمالی:

• Cookieهای Application روی File Domain ارسال نمی‌شوند؛
• CSP متفاوت اعمال می‌شود؛
• Origin Isolation بهتر می‌شود؛
• Storage Architecture مستقل می‌شود.

ولی تنظیم CORS، CSP و Access Control همچنان باید دقیق باشد.

تفاوت Validation سمت Client و Server

Client-Side Validation

برای UX مفید است.

مثلاً:

• نمایش حداکثر حجم
• محدود کردن File Picker
• Preview
• اعلام Extension مجاز

اما قابل اعتماد نیست.

Server-Side Validation

کنترل امنیتی واقعی باید اینجا باشد.

Server باید بدون توجه به اینکه Browser چه گفته:

• Size را بررسی کند؛
• Type را تشخیص دهد؛
• Signature را بررسی کند؛
• Authorization را اعمال کند؛
• Filename تولید کند؛
• Storage را تعیین کند.

MDN نیز تأکید می‌کند که Client-Side Validation را می‌توان دور زد و Server-Side Validation برای امنیت ضروری است.

اشتباهات رایج در امنیت آپلود فایل سایت

۱. اعتماد به accept در HTML

accept برای UX است، نه Security Boundary.

۲. بررسی فقط Extension

پسوند به‌تنهایی File Content را اثبات نمی‌کند.

۳. اعتماد به MIME ارسالی Browser

این مقدار تحت کنترل Client است.

۴. استفاده از Blocklist

ممکن است File Type خطرناکی فراموش شود.

Allowlist امن‌تر است.

۵. نگه داشتن Filename کاربر

Filename باید به‌عنوان Untrusted Input دیده شود.

۶. ذخیره فایل در Web Root

فایل‌های User باید تا حد امکان از Application جدا باشند.

۷. Publish قبل از Scan

فایل باید ابتدا در Quarantine بررسی شود.

۸. نداشتن Limit

هم Size و هم Number of Uploads باید محدود شوند.

۹. باز کردن تمام MIMEها در وردپرس

برای رفع یک خطای Upload نباید کل Policy را حذف کرد.

۱۰. عدم بررسی Parserها

Image Library، PDF Library و Archive Tool نیز باید Patch شوند.

۱۱. اعتماد کامل به Antivirus

Antivirus تنها یک Layer است.

۱۲. نداشتن Authorization برای Download

Private File با URL مخفی واقعاً Private نمی‌شود.

۱۳. بی‌توجهی به CSRF

Upload Endpoint نیز باید در Threat Model مربوط به CSRF قرار گیرد.

۱۴. نداشتن Monitoring

بدون Logging، Abuse ممکن است مدت زیادی کشف نشود.

چک‌لیست امنیت آپلود فایل در سایت

برای Audit اولیه می‌توانید این چک‌لیست را استفاده کنید.

File Type

• آیا فقط File Typeهای ضروری Allow شده‌اند؟
• آیا Extension بررسی می‌شود؟
• آیا MIME سمت Server تشخیص داده می‌شود؟
• آیا Signature بررسی می‌شود؟
• آیا Parser واقعی File Type را تأیید می‌کند؟

Filename

• آیا Filename توسط Server تولید می‌شود؟
• آیا نام اصلی فقط Metadata است؟
• آیا Length محدود است؟
• آیا Character Validation وجود دارد؟

File Size

• آیا Maximum Size وجود دارد؟
• آیا Web Server نیز Limit دارد؟
• آیا User Quota تعریف شده؟
• آیا Rate Limit فعال است؟

Storage

• آیا File خارج از Web Root قرار دارد؟
• آیا Storage از Application جداست؟
• آیا Execute Permission وجود ندارد؟
• آیا Object Storage خصوصی است؟

Scanning

• آیا Malware Scan انجام می‌شود؟
• آیا File قبل از Scan Public نیست؟
• آیا برای Documentها CDR بررسی شده؟
• آیا Processing در Sandbox انجام می‌شود؟

Authentication

• آیا فقط کاربران مجاز Upload می‌کنند؟
• آیا Roleها محدود شده‌اند؟
• آیا Ownership فایل بررسی می‌شود؟

Download

• آیا فایل خصوصی Authorization دارد؟
• آیا MIME صحیح ارسال می‌شود؟
• آیا Content-Disposition مناسب است؟
• آیا nosniff بررسی شده؟

Operations

• آیا Upload Logging وجود دارد؟
• آیا Alerting وجود دارد؟
• آیا Storage Monitoring فعال است؟
• آیا Dependencyها به‌روز هستند؟

معماری پیشنهادی برای File Upload امن

یک Workflow حرفه‌ای می‌تواند چنین باشد:

مرحله ۱: Authentication

User باید شناسایی شود، مگر اینکه Business Requirement واقعاً Upload ناشناس بخواهد.

مرحله ۲: Authorization

بررسی شود کاربر اجازه این نوع Upload را دارد.

مرحله ۳: Request Limit

قبل از ورود File به Application حجم Request محدود شود.

مرحله ۴: Temporary Storage

فایل در Quarantine خصوصی ذخیره شود.

مرحله ۵: Filename Normalization

Filename اصلی برای Metadata Sanitized شود.

مرحله ۶: Extension Allowlist

فقط Extensionهای موردنیاز قبول شوند.

مرحله ۷: MIME Detection

MIME سمت Server بررسی شود.

مرحله ۸: Signature Validation

ساختار ابتدایی فایل بررسی شود.

مرحله ۹: Deep Validation

Parser مخصوص File Type اجرا شود.

مرحله ۱۰: Malware Scan

Scanner یا Sandbox بررسی انجام دهد.

مرحله ۱۱: Transformation

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

• Image Re-encode
• Document CDR
• Metadata Strip

انجام شود.

مرحله ۱۲: Safe Filename

Identifier تصادفی تولید شود.

مرحله ۱۳: Final Storage

فایل به Private Storage یا Storage کنترل‌شده منتقل شود.

مرحله ۱۴: Database Record

مالک، نوع، Size و Storage Key ثبت شود.

مرحله ۱۵: Controlled Access

Download Handler یا Signed URL کنترل‌شده استفاده شود.

مرحله ۱۶: Monitoring

رویدادها ثبت و رفتار غیرعادی Alert شود.

این فرایند نمونه خوبی از Defense in Depth است.

اگر یکی از Layerها خطا کند، Layerهای بعدی همچنان ریسک را کاهش می‌دهند.

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

در WooCommerce و فروشگاه‌های اختصاصی Upload ممکن است برای:

• Product Customization
• Prescription
• Invoice
• Return Evidence
• Vendor Product
• Support Attachment

استفاده شود.

این فایل‌ها ممکن است حاوی اطلاعات شخصی باشند.

بنابراین علاوه بر Malware Security باید Privacy نیز رعایت شود.

تصویر مدرک مشتری نباید در یک Upload Directory عمومی قرار گیرد.

برای چنین فایل‌هایی:

• Storage Private
• Authorization
• Encryption at Rest
• Retention Policy
• Secure Deletion

اهمیت بالایی دارد.

امنیت Upload در فرم استخدام

Career Formها هدف جذابی برای سوءاستفاده هستند، چون معمولاً Document Upload دارند.

برای رزومه بهتر است:

• فقط فرمت‌های ضروری Allow شوند؛
• Document Scan انجام شود؛
• فایل‌ها Public URL نداشته باشند؛
• Recruiter فایل را از پنل Authenticated دریافت کند؛
• Retention Policy تعریف شود.

OWASP نیز File Upload در سناریوهایی مانند CV را یکی از مثال‌های رایج مطرح کرده است.

آیا HTTPS برای Upload کافی است؟

خیر.

HTTPS فقط Data in Transit را رمزگذاری می‌کند.

اگر فایل مخرب باشد، HTTPS آن را سالم نمی‌کند.

HTTPS باید وجود داشته باشد، اما مسئله File Upload به:

• Validation
• Processing
• Storage
• Access
• Monitoring

مربوط است.

آیا CSP می‌تواند از Upload مخرب جلوگیری کند؟

CSP مستقیماً File Upload را Validate نمی‌کند.

اما اگر فایل User Generated Content در Browser نمایش داده شود، CSP می‌تواند بخشی از Defense in Depth سمت Client باشد.

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

• Script Sourceها را محدود کند؛
• Frame Policy اعمال کند؛
• Objectها را محدود کند.

اما CSP جایگزین Upload Validation نیست.

آیا حذف Upload بهترین راه امنیتی است؟

اگر Feature موردنیاز نیست، بله.

یکی از قوی‌ترین اصول امنیت:

کاهش Attack Surface است.

هر Feature اضافه نیازمند:

• Code
• Dependency
• Permission
• Endpoint
• Monitoring
• Maintenance

است.

اگر سایت هیچ نیازی به File Upload از User ندارد، این قابلیت نباید فقط «برای آینده» فعال بماند.

تست امنیت File Upload چگونه انجام می‌شود؟

Security Test باید کنترل‌های دفاعی را بررسی کند، نه اینکه صرفاً تلاش برای Upload یک File خاص انجام شود.

موارد Test می‌تواند شامل:

• File Type غیرمجاز Reject می‌شود؟
• MIME ناسازگار Reject می‌شود؟
• Filename غیرعادی Normalize می‌شود؟
• Oversized File Reject می‌شود؟
• User بدون Permission Block می‌شود؟
• فایل Quarantine Public نیست؟
• Download Authorization کار می‌کند؟
• Rate Limit وجود دارد؟
• Storage Permission امن است؟
• Parser Failure مدیریت می‌شود؟

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

Security Review فقط یک‌بار انجام نمی‌شود

Upload System ممکن است امروز امن باشد ولی چند ماه بعد تغییر کند.

مثلاً:

• Plugin جدید نصب شود؛
• MIME جدید اضافه شود؛
• Storage به Cloud منتقل شود؛
• CDN اضافه شود؛
• Image Processor تغییر کند؛
• User Role جدید ایجاد شود.

هرکدام می‌تواند Threat Model را تغییر دهد.

بنابراین File Upload باید بخشی از:

• Code Review
• Dependency Management
• Vulnerability Management
• Penetration Testing
• Monitoring

باشد.

سؤالات متداول درباره امنیت آپلود فایل

امنیت آپلود فایل در سایت چیست؟

امنیت آپلود فایل مجموعه کنترل‌هایی است که تضمین می‌کنند Fileهای دریافتی از کاربران از نظر Type، Content، Size، Filename، Permission و Storage مطابق سیاست Application باشند و نتوانند به Server یا کاربران دیگر آسیب برسانند.

بهترین روش جلوگیری از آپلود فایل مخرب چیست؟

یک روش واحد کافی نیست. بهترین راه استفاده از Allowlist Extension، MIME Detection، File Signature، Parser Validation، تغییر Filename، محدودیت Size، Storage جداگانه، Malware Scan و Authorization به‌صورت هم‌زمان است.

آیا بررسی پسوند فایل کافی است؟

خیر. Extension فقط یکی از Signalهاست و باید همراه MIME، Signature و Validation واقعی Content بررسی شود.

آیا MIME Type قابل اعتماد است؟

MIME ارسال‌شده توسط Browser قابل جعل است و نباید کنترل امنیتی مستقل باشد. Type واقعی باید سمت Server تشخیص داده شود.

آیا accept در HTML جلوی فایل غیرمجاز را می‌گیرد؟

خیر. accept بیشتر راهنمای File Picker است. MDN تأکید می‌کند که Server-Side Validation همچنان ضروری است.

فایل Upload شده را کجا ذخیره کنیم؟

در حالت ایده‌آل روی Host یا Storage جداگانه و در غیر این صورت خارج از Web Root نگهداری شود.

آیا فایل باید Rename شود؟

بله. OWASP پیشنهاد می‌کند Filename ذخیره‌شده توسط Application تولید شود و تا حد امکان از Filename کاربر برای Storage استفاده نشود.

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

خیر. Antivirus یکی از لایه‌های دفاعی است و باید کنار Validation، Isolation و Access Control استفاده شود.

برای تصاویر چه کاری انجام دهیم؟

علاوه بر Type Validation، تصویر را با Library معتبر Decode و در صورت امکان Re-encode کنید تا ساختار استاندارد جدیدی تولید شود.

آیا SVG را می‌توان Upload کرد؟

در صورت نیاز تجاری می‌توان، اما به دلیل قابلیت‌های Active Content و ساختار XML باید Sanitization و کنترل‌های بیشتری اعمال شود.

آپلود ZIP خطرناک است؟

ZIP ذاتاً مخرب نیست، اما Archive Processing می‌تواند ریسک‌هایی مانند مصرف زیاد منابع و Path Manipulation داشته باشد؛ بنابراین باید Size، Entry Count و Extract Path محدود شود.

آیا فایل‌های Upload وردپرس امن هستند؟

WordPress Core کنترل‌هایی برای Sanitization، MIME و Extension دارد، اما Pluginها، Server Configuration و MIMEهای اضافی می‌توانند سطح امنیت را تغییر دهند.

آیا باید همه MIMEها را در وردپرس باز کنیم؟

خیر. فقط File Typeهایی را Allow کنید که سایت واقعاً نیاز دارد.

آیا Upload باید Login بخواهد؟

در صورت امکان بله. اگر Upload ناشناس واقعاً موردنیاز نیست، فقط Userهای Authenticated و Authorized اجازه ارسال فایل داشته باشند.

آیا WAF جلوی Upload File مخرب را می‌گیرد؟

WAF می‌تواند بخشی از حملات و Abuse را کاهش دهد، اما جایگزین Application-Level Validation و Storage Isolation نیست.

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

به‌جای Public URL قابل حدس، از Download Endpoint دارای Authorization یا Signed URL کوتاه‌عمر استفاده کنید.

آیا Security Headerها در امنیت فایل Upload مؤثرند؟

Headerهایی مانند CSP و X-Content-Type-Options می‌توانند در نحوه Serve و نمایش فایل نقش دفاعی داشته باشند، اما Upload Validation باید مستقل انجام شود.

آیا نام فایل اصلی کاربر را حذف کنیم؟

می‌توانید نام اصلی را برای نمایش در Database ذخیره کنید، اما Filename واقعی Storage بهتر است توسط Application تولید شود.

فایل مخرب Reject شده را چه کنیم؟

در سایت‌های معمولی پس از ثبت اطلاعات لازم حذف شود. در محیط‌های Security-sensitive ممکن است نسخه Quarantine با Access محدود و Retention مشخص نگه داشته شود.

جمع‌بندی؛ چگونه از آپلود فایل مخرب جلوگیری کنیم؟

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

File Upload یک ورودی پیچیده است؛ زیرا کاربر نه‌فقط یک مقدار متنی، بلکه یک Object کامل را وارد زیرساخت Application می‌کند.

این Object ممکن است ذخیره، Parse، Resize، Extract، Preview، Download یا برای کاربران دیگر نمایش داده شود.

به همین دلیل OWASP تأکید می‌کند که هیچ Silver Bullet یا کنترل واحدی برای File Upload وجود ندارد و Defense in Depth ضروری است.

اولین اصل این است که فقط File Typeهایی را Allow کنید که واقعاً Business Requirement دارند.

پسوند باید بررسی شود، اما نباید تنها معیار باشد.

MIME Type ارسالی Client قابل اعتماد نیست. File Signature نیز به‌تنهایی کافی نیست.

در Applicationهای حرفه‌ای Extension، MIME، Signature و Parser Validation با یکدیگر ترکیب می‌شوند.

Filename اصلی کاربر نباید مستقیماً برای Storage استفاده شود. Server باید Identifier مستقل و غیرقابل پیش‌بینی تولید کند.

فایل‌های Upload شده نیز در حالت ایده‌آل باید روی Storage جداگانه یا حداقل خارج از Web Root نگهداری شوند.

Upload Directory نباید محل اجرای Application Code باشد.

Size Limit، Upload Rate Limit و Storage Quota نیز برای جلوگیری از Resource Abuse ضروری هستند.

در سایت‌هایی که Document، PDF یا Image دریافت می‌کنند، استفاده از Malware Scanner، Sandbox، Re-encoding و در صورت نیاز CDR می‌تواند لایه‌های امنیتی بیشتری ایجاد کند.

اما Scan فایل هیچ‌گاه جایگزین Validation نیست.

برای فایل‌های Private نیز URL مخفی کافی نیست. Download باید Authorization داشته باشد.

در وردپرس نیز بهتر است از APIهای استاندارد Core مانند سیستم Upload خود WordPress استفاده شود و MIMEهای غیرضروری باز نشوند. WordPress Core هنگام Upload کنترل‌هایی برای Filename، Extension و MIME دارد، اما Pluginهای آسیب‌پذیر یا تنظیمات Server نامناسب می‌توانند این مدل امنیتی را تضعیف کنند.

در نهایت یک معماری امن File Upload معمولاً چنین مسیری دارد:

احراز هویت → مجوز دسترسی → محدودیت Request → Quarantine → بررسی Extension → MIME → Signature → Parser Validation → Malware Scan → Transformation → نام‌گذاری امن → Storage جداگانه → Access Control → Logging و Monitoring.

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

این همان مفهوم Defense in Depth است؛ رویکردی که باید اساس طراحی امنیت آپلود فایل در سایت باشد.