File Upload Quarantine و Promotion

خروجی محدود درس

آپلود فایل یک «دریافت داده» ساده نیست؛ ورود یک شیء باینری یا متنی از مرز اعتماد به سامانه است. در این درس هدف این است که یک خط لوله محدود و قابل‌اثبات بسازیم که فایل تازه‌وارد را غیرقابل اعتماد بداند، آن را در Quarantine نگه دارد، شواهد هر کنترل را مستقل ثبت کند و فقط زمانی به حالت Promotion ببرد که مجموعه کنترل‌های لازم کامل شده باشد.

مقصد شواهد این درس File Intake Quarantine Promotion Record v1 است. این رکورد ادعا نمی‌کند که یک فایل «کاملاً امن» شده، یک اسکنر همه تهدیدها را می‌بیند، یا نتیجه محیط محلی اثبات امنیت Production است. فقط برای fixture محدود SEC009-LAB1 ثبت می‌کند: Authorized Uploader، Declared Type، Observed Type Evidence، Size Policy، Scan/CDR Status، Quarantine Location، Generated Storage Name، Promotion Decision، Public Representation و Residual Risk.

آزمایشگاه کاملاً local و synthetic است. هیچ فایل واقعی از اینترنت دریافت نمی‌شود، هیچ سرویس اسکن عمومی فراخوانی نمی‌شود، هیچ payload مخرب ساخته یا اجرا نمی‌شود و هیچ مسیر production یا webroot واقعی لمس نمی‌شود. فایل‌ها فقط رکوردهای ثابت و benign هستند.

1. Intake با Trust فرق دارد

ورود موفق فایل فقط می‌گوید بایت‌ها به مرز Intake رسیده‌اند. این رخداد به‌تنهایی درباره مجاز بودن نوع فایل، سلامت محتوا، اجازه کاربر، محل ذخیره یا امکان انتشار چیزی ثابت نمی‌کند. اولین state در fixture QUARANTINED است، نه PROMOTED.

در مدل این درس، intake boundary یعنی نقطه‌ای که فایل هنوز untrusted است و فقط metadata اولیه و identifier داخلی دریافت می‌کند. هیچ‌کدام از headerها یا نام فایل ارسال‌شده توسط client authority نهایی نیستند.

2. Extension، Content-Type و Signature سه نقش متفاوت دارند

Extension allowlist باید از نیاز کسب‌وکار بیاید. اگر محصول فقط تصویر PNG و JPEG لازم دارد، باز کردن انواع اضافی بدون دلیل دامنه حمله را زیاد می‌کند. با این حال پسوند به‌تنهایی اثبات نوع واقعی نیست.

Content-Type ارسالی توسط client یک hint است و قابل جعل است. بنابراین در fixture، declared MIME با Observed Type Evidence جدا نگهداری می‌شود. برای نمونه‌های benign، signature ثابت محلی با نوع مجاز مقایسه می‌شود. حتی signature نیز به‌تنهایی «امن بودن کامل» را ثابت نمی‌کند؛ فقط یکی از gateهای تصمیم است.

Negative Evidence: اگر extension مجاز باشد اما signature با policy همان نوع هم‌خوانی نداشته باشد، فایل باید در quarantine بماند و Promotion رد شود. این failure نباید با تغییر filename یا نادیده گرفتن mismatch پاک شود.

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

نامی که کاربر می‌فرستد برای نمایش یا audit می‌تواند حفظ شود، اما نباید مستقیماً به storage identity یا public path تبدیل شود. fixture برای هر intake یک generated_storage_name ثابت و application-controlled می‌خواهد.

تغییر نام یک کنترل storage است؛ جایگزین type validation، authorization یا scanning نیست. اگر generated name حذف شود، gate Promotion باید fail شود حتی اگر بقیه شواهد سبز باشند.

4. Quarantine باید از مسیر عمومی جدا بماند

فایل raw تا قبل از تصمیم Promotion نباید «به‌طور مستقیم قابل سرو» فرض شود. در fixture، quarantine://... فقط یک namespace محلی است و هیچ فایل سیستم واقعی یا webroot را نشان نمی‌دهد. Promotion نیز raw upload را مستقیماً expose نمی‌کند؛ خروجی فقط یک public_representation_id مصنوعی است.

این separation باعث می‌شود «فایل دریافت شد» با «فایل قابل مصرف عمومی است» یکی نشود.

5. Authorization و Size gate مستقل‌اند

حتی اگر type درست باشد، uploader باید برای آن کلاس فایل مجاز باشد. همین‌طور size limit باید مستقل از type evidence ثبت شود. یک authorization PASS نمی‌تواند size failure را جبران کند و برعکس.

در control record هر gate evidence خودش را دارد تا تصمیم نهایی قابل trace باشد.

6. Scan/CDR یک gate اختیاری و وابسته به policy است

OWASP استفاده از antivirus/sandbox و در صورت کاربرد CDR را به‌عنوان لایه‌های دفاعی توصیه می‌کند، اما این درس هیچ محصول خاصی را authority نمی‌کند. fixture فقط status مصنوعی مانند NOT_REQUIRED_FOR_FIXTURE یا PASS_SYNTHETIC دارد.

یک scan PASS اثبات universal safety نیست. مصرف‌کننده downstream، parser، retention policy و business context همچنان residual risk دارند.

7. Promotion یک state transition صریح است

Promotion فقط وقتی مجاز است که:

1. uploader مجاز باشد؛
2. extension در allowlist باشد؛
3. declared type و observed signature با policy هم‌خوان باشند؛
4. size داخل limit باشد؛
5. generated storage identity موجود باشد؛
6. scan/CDR gate اگر policy آن را required کرده PASS باشد؛
7. evidence record کامل باشد.

اگر یکی از این موارد fail یا missing باشد، state باید QUARANTINED یا REJECTED باقی بماند. «تقریباً همه کنترل‌ها پاس شده‌اند» شرط Promotion نیست.

8. آزمایش baseline

در SEC009-LAB1 سه fixture benign داریم: تصویر PNG کوچک، متن ساده و یک رکورد mismatch. هیچ فایل executable یا محتوای مخرب واقعی وجود ندارد.

Baseline مثبت باید یک avatar مجاز را از QUARANTINED به PROMOTED ببرد و فقط representation مصنوعی را expose کند. baseline منفی باید mismatch نوع را با DENY_TYPE_EVIDENCE_MISMATCH رد کند.

9. Failure probe اول: type mismatch

در این probe، client ادعا می‌کند فایل PNG است، اما signature fixture آن را text نشان می‌دهد. انتظار: extension به‌تنهایی اجازه Promotion ندهد، declared Content-Type authority نباشد و decision رد شود.

شاهد مهم خود denial است؛ نه اینکه test فقط exit code سبز بدهد.

10. Failure probe دوم: generated storage identity حذف شده

اگر generated_storage_name خالی شود، raw client filename نباید fallback شود. نتیجه باید DENY_STORAGE_IDENTITY_MISSING باشد و فایل در quarantine بماند.

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

11. Failure probe سوم: یک gate موردنیاز missing است

اگر policy برای fixture خاص scan gate را required کند اما evidence مقدار MISSING داشته باشد، Promotion باید با DENY_REQUIRED_GATE_MISSING متوقف شود. سیستم حق ندارد evidence نبودن را PASS فرض کند.

12. Evidence contract

هر ردیف File Intake Quarantine Promotion Record v1 این فیلدها را نیاز دارد:

• fixture_id
• authorized_uploader
• declared_type
• observed_type_evidence
• size_policy
• scan_cdr_status
• quarantine_location
• generated_storage_name
• promotion_decision
• public_representation
• residual_risk

Observed output باید از inference جدا باشد. عبارت «policy گفته Promotion مجاز است» با «Production امن است» یکی نیست.

13. Positive Evidence و Negative Evidence

Positive Evidence نشان می‌دهد fixture مجاز تحت assumptions اعلام‌شده می‌تواند gateها را کامل کند.

Negative Evidence نشان می‌دهد حداقل یک shortcut واقعاً متوقف می‌شود: type mismatch، storage identity missing یا required gate missing. اگر فقط happy path ثبت شود، competence امنیتی کامل نیست.

14. Transfer مستقل

در changed-context دو workload داریم: avatar upload و contract-document upload. allowed types، downstream consumer و scan/CDR requirement آن‌ها یکسان نیست. learner باید برای هرکدام policy مستقل بسازد و نباید policy avatar را کورکورانه برای document کپی کند.

نتیجه transfer باید توضیح دهد کدام gate مشترک است و کدام gate به context جدید وابسته است.

15. مرز ادعا و Residual Risk

این lab اثبات نمی‌کند فایل واقعی در Production عاری از malware است. اثبات نمی‌کند parser downstream آسیب‌پذیر نیست. درباره retention، privacy، DLP، abuse moderation یا product-specific legal policy نیز تصمیم نهایی نمی‌دهد.

Residual risk باید صریح بماند: «این fixture فقط state machine و evidence gates اعلام‌شده را اثبات می‌کند.»

16. Assessment

پاسخ blocking باید بتواند یک failure را تشخیص دهد، decision را از evidence بسازد و در changed-context بدون scaffold قاطع عمل کند. پاسخ retrieval-only برای S2/S3/S5 کافی نیست.

Owner acceptance نیز یک human gate جداست و machine PASS نباید آن را از قبل پر کند.

17. منبع و تازگی

Authority منجمد این درس فقط OWASP-FILE-UPLOAD است. در authoring امروز، همان منبع رسمی دوباره بررسی شد و claim boundary تغییر نکرد: allowlisted extensions، distrust of client Content-Type، signature/content checks، application-generated filename، authorization/size limits، storage boundary و optional scanning/CDR همچنان با lesson boundary سازگارند.

Review due همچنان 2026-10-02 است. هیچ authority جدیدی اضافه نشده است.

18. جمع‌بندی تصمیمی

قانون فشرده درس این است: upload arrival is not trust; quarantine is the default state; Promotion is an explicit evidence-complete transition. هیچ header، filename یا یک scan منفرد به‌تنهایی authority کافی برای Promotion نیست.