Path Traversal چیست؟ بررسی حمله Directory Traversal و روش‌های جلوگیری

Path Traversal یا Directory Traversal نوعی آسیب‌پذیری امنیتی در وب‌سایت‌ها و نرم‌افزارهاست که زمانی ایجاد می‌شود که برنامه از ورودی قابل‌کنترل توسط کاربر برای ساخت مسیر فایل یا پوشه استفاده کند، اما مسیر نهایی را به‌درستی محدود نکند. در چنین شرایطی ممکن است برنامه به فایل یا دایرکتوری‌ای خارج از محدوده مجاز دسترسی پیدا کند. مهم‌ترین راهکارهای جلوگیری از Path Traversal شامل حذف مسیرهای مستقیم از ورودی کاربر، استفاده از شناسه‌های ثابت و Allowlist، Canonicalization مسیر، کنترل قرار گرفتن مسیر نهایی در دایرکتوری مجاز، محدود کردن دسترسی سیستم‌عامل و طراحی صحیح قابلیت‌های خواندن، نوشتن، آپلود و استخراج فایل هستند.

Path Traversal چیست؟

Path Traversal که با نام Directory Traversal نیز شناخته می‌شود، یکی از آسیب‌پذیری‌های مرتبط با مدیریت فایل و کنترل دسترسی در برنامه‌های تحت وب است.

یک برنامه وب ممکن است برای انجام کارهای کاملاً عادی به فایل‌های مختلف دسترسی داشته باشد؛ برای مثال:

نمایش تصویر، دانلود فاکتور، دریافت فایل راهنما، بارگذاری Template، خواندن فایل زبان، تولید گزارش، مدیریت فایل‌های کاربران، پردازش Backup یا ذخیره فایل‌های آپلودشده.

وجود چنین قابلیت‌هایی به خودی خود مشکل امنیتی محسوب نمی‌شود.

خطر زمانی ایجاد می‌شود که برنامه اجازه دهد یک مقدار غیرقابل‌اعتماد مستقیماً یا غیرمستقیم تعیین کند کدام فایل در File System باز، خوانده، نوشته، حذف یا پردازش شود و در عین حال مرز دایرکتوری مجاز به‌درستی کنترل نشود.

MITRE این ضعف را با شناسه CWE-22 و عنوان «Improper Limitation of a Pathname to a Restricted Directory» ثبت کرده است. در تعریف CWE-22، محصول از ورودی خارجی برای ساخت یک Pathname استفاده می‌کند که قرار است به فایلی زیر یک دایرکتوری محدود اشاره کند، اما عناصر ویژه مسیر به‌اندازه کافی کنترل نمی‌شوند و مسیر می‌تواند در نهایت به محلی خارج از محدوده تعیین‌شده Resolve شود.

OWASP نیز Path Traversal را حمله‌ای می‌داند که هدف آن دسترسی به فایل‌ها یا پوشه‌هایی خارج از Web Root یا محدوده مورد انتظار برنامه است.

بنابراین تعریف ساده Path Traversal این است:

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

Directory Traversal و Path Traversal چه تفاوتی دارند؟

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

Directory Traversal نام بسیار رایجی برای این حمله است، اما CWE عبارت Path Traversal را ترجیح می‌دهد؛ زیرا مسئله همیشه صرفاً «حرکت بین پوشه‌ها» نیست.

ممکن است مشکل از یک مسیر نسبی ایجاد شود یا برنامه یک Absolute Path غیرمنتظره را بپذیرد.

به همین دلیل Path Traversal اصطلاح جامع‌تری است.

با این حال زمانی که کاربران درباره Directory Traversal، Directory Climbing یا Path Traversal صحبت می‌کنند، اغلب منظور آنها خانواده یکسانی از ضعف‌های کنترل مسیر فایل است.

برای درک Path Traversal ابتدا باید مسیر فایل را بشناسیم

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

یک برنامه معمولاً دارای یک Base Directory یا دایرکتوری پایه است که فایل‌های مشخصی باید فقط از همان محدوده دریافت شوند.

برای مثال فرض کنید یک وب‌سایت فایل‌های راهنمای قابل دانلود خود را در چنین ساختار مفهومی نگه می‌دارد:

/application
    /public-documents
        guide.pdf
        rules.pdf
        faq.pdf

هدف برنامه این است که Endpoint دانلود فقط فایل‌های موجود در public-documents را ارائه کند.

از دید امنیتی، کاربر نباید قادر باشد تعیین کند برنامه به یک فایل تنظیمات، Source Code، Log یا فایل سیستمی در محل دیگری مراجعه کند.

طراحی امن باید مرز روشنی داشته باشد:

دایرکتوری مجاز
      ↓
فایل‌های از پیش تعیین‌شده
      ↓
برنامه
      ↓
کاربر

نه اینکه:

User Input
      ↓
مسیر دلخواه File System
      ↓
عملیات فایل

هرچه کنترل کاربر روی بخش بزرگ‌تری از Path باشد، اهمیت Validation و معماری امن افزایش پیدا می‌کند.

آسیب‌پذیری Path Traversal چگونه ایجاد می‌شود؟

رایج‌ترین علت ایجاد Directory Traversal آن است که توسعه‌دهنده یک مقدار دریافت‌شده از Request را مستقیماً وارد عملیات File System می‌کند.

برای مثال برنامه ممکن است یک پارامتر به نام file دریافت کند و سپس تصور کند مقدار آن همیشه یکی از فایل‌های مجاز است.

در طراحی ضعیف، مسیر نهایی از ترکیب Base Directory و مقدار کاربر ساخته می‌شود.

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

Base Directory + User Input → File Operation

توسعه‌دهنده ممکن است تصور کند چون Base Directory در ابتدای مسیر قرار دارد، کاربر نمی‌تواند از آن خارج شود.

اما سیستم‌عامل و File System مسیر را براساس قواعد خودش Resolve می‌کنند.

اگر برنامه قبل از انجام عملیات، مسیر واقعی را Normalize و محدود نکند، مقدار ورودی ممکن است معنای دیگری پیدا کند.

CWE-22 این موضوع را دقیقاً به همین شکل توضیح می‌دهد: ورودی خارجی در ساخت Pathname دخالت می‌کند و برنامه قادر نیست اطمینان حاصل کند مسیر Resolveشده همچنان زیر Parent Directory موردنظر باقی مانده است.

مرز اعتماد کجا شکسته می‌شود؟

مهم‌ترین سؤال در Code Review این است:

«آیا کاربر نام یک Resource منطقی را انتخاب می‌کند یا بخشی از مسیر واقعی File System را؟»

این دو طراحی تفاوت زیادی دارند.

در مدل امن‌تر، کاربر ممکن است فقط شناسه‌ای مانند:

document=guide

ارسال کند.

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

در مدل پرخطر، User Input مستقیماً به‌عنوان Path یا Filename در عملیات File System استفاده می‌شود.

هرچه فاصله میان User Input و File API کمتر باشد، احتمال بروز مشکل بیشتر است.

Relative Path Traversal چیست؟

Relative Path Traversal زمانی مطرح می‌شود که عناصر مسیر نسبی بتوانند باعث حرکت از موقعیت مورد انتظار به بخش دیگری از ساختار فایل شوند.

سیستم‌عامل‌ها معمولاً مفهوم Parent Directory را پشتیبانی می‌کنند.

اگر برنامه رشته خام ورودی را بدون کنترل وارد Path کند، ممکن است File System در هنگام Resolve کردن مسیر، بخش‌هایی از آن را به‌عنوان دستور حرکت در ساختار پوشه‌ها تفسیر کند.

نکته مهم این است که نباید امنیت را براساس جست‌وجوی یک String خاص طراحی کرد.

سیستم‌عامل‌ها، Frameworkها، URL Decoderها و File APIها ممکن است اشکال مختلف یک مسیر را Normalize کنند.

به همین دلیل رویکرد دفاعی صحیح، ایجاد یک مسیر Canonical و سپس اعتبارسنجی محل نهایی آن است؛ نه صرفاً حذف چند Character مشخص.

Absolute Path Traversal چیست؟

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

اگر برنامه اجازه دهد کاربر یک Absolute Path را مستقیماً تعیین کند، ممکن است فایل موردنظر کاملاً خارج از Application Directory قرار داشته باشد.

CWE-22 بین Relative Path Traversal و Absolute Path Traversal تمایز قائل می‌شود و برای حالت Absolute Path نیز دسته‌بندی‌های مرتبط در نظر گرفته است.

این موضوع نشان می‌دهد که جلوگیری از Directory Traversal صرفاً با مسدود کردن Patternهای شناخته‌شده کافی نیست.

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

مسیر مجاز دقیقاً کجاست؟

چه فایل‌هایی باید قابل دسترسی باشند؟

چه نوع مسیرهایی پذیرفته می‌شوند؟

و Path Resolveشده واقعاً در همان محدوده قرار گرفته است یا خیر؟

Path Traversal در چه بخش‌هایی از وب‌سایت ممکن است ایجاد شود؟

هر قابلیتی که با File System تعامل دارد باید در Scope بررسی قرار گیرد.

بعضی Endpointها واضح هستند؛ مثلاً بخش دانلود فایل.

اما برخی نقاط کمتر به چشم می‌آیند.

سیستم دانلود فایل

یکی از رایج‌ترین محل‌های بروز Path Traversal، Endpointهایی هستند که بر اساس Parameter درخواست یک فایل را برای Download برمی‌گردانند.

برای مثال یک سیستم ممکن است فاکتور، قرارداد یا سند کاربر را از روی نام فایل دریافت کند.

اگر Authorization و Path Validation به‌درستی اجرا نشوند، خطر Directory Traversal یا حتی ترکیب آن با ضعف‌های کنترل دسترسی مطرح می‌شود.

راه امن‌تر این است که Client شناسه Resource را ارسال کند و Server براساس Database یا Mapping داخلی مسیر واقعی را تعیین کند.

نمایش تصاویر و فایل‌های Media

بعضی برنامه‌ها تصویر را مستقیماً از File System می‌خوانند و به مرورگر ارسال می‌کنند.

این معماری به‌ویژه زمانی حساس می‌شود که User Input بتواند Filename یا Folder را کنترل کند.

بهتر است فایل‌های عمومی از Storage مشخص یا Static File Handler امن سرو شوند و مسیرهای دلخواه به File API ارسال نشوند.

Templateها و Themeها

سیستم‌هایی که امکان انتخاب Template، Theme یا فایل Layout دارند نیز باید بررسی شوند.

اگر نام Template از Query Parameter دریافت و سپس مستقیماً تبدیل به Path شود، امکان بروز Path Traversal وجود دارد.

Allowlist در چنین مواردی بسیار مؤثر است.

به‌جای پذیرش نام فایل دلخواه، می‌توان گزینه‌های مشخصی مانند:

default
dark
minimal

را پذیرفت و در Server آنها را به فایل‌های ثابت Mapping کرد.

فایل‌های زبان

برنامه‌های چندزبانه معمولاً Translation File دارند.

اگر Language Parameter مستقیماً بخشی از مسیر فایل شود، ممکن است Attack Surface ایجاد شود.

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

سیستم‌های گزارش‌گیری

Report Generatorها ممکن است فایل CSV، PDF یا سایر خروجی‌ها را از Disk دریافت کنند.

نام گزارش، مسیر Export یا محل Temporary File باید از دید Path Traversal بررسی شود.

Backup و Restore

قابلیت‌های Backup حساسیت بسیار بالایی دارند.

فایل Backup ممکن است حاوی Database، تنظیمات Application و سایر اطلاعات حساس باشد.

هم مسیر فایل Backup و هم محل Restore باید کاملاً کنترل شوند.

File Manager

یک File Manager به‌طور طبیعی دسترسی گسترده‌تری به File System دارد.

در این سیستم‌ها فقط Input Validation کافی نیست.

Authorization، Root Directory مجازی، Canonicalization، ACL و Permission سیستم‌عامل باید هم‌زمان طراحی شوند.

APIهای فایل

گاهی رابط وب امن به نظر می‌رسد ولی API پشت آن Parameter مسیر دریافت می‌کند.

امنیت باید در Backend اعمال شود و نباید به محدودیت UI اعتماد کرد.

کاربر می‌تواند Request را خارج از رابط رسمی برنامه ارسال کند.

Path Traversal در Upload فایل

آپلود فایل نیز می‌تواند با کنترل مسیر ارتباط پیدا کند.

نام فایل معمولاً از سمت Client ارسال می‌شود و نباید بدون Validation به‌عنوان مسیر نهایی Storage استفاده شود.

OWASP در راهنمای File Upload اشاره می‌کند که Metadata فایل از جمله Path و Filename می‌تواند یکی از نقاط خطر باشد و محل ذخیره فایل نقش مهمی در شدت پیامد دارد.

راهکار مناسب معمولاً این است که برنامه نام Storage داخلی را خودش تولید کند.

برای مثال:

Uploaded Filename:
report-final.pdf

Internal Storage Name:
random-generated-id.pdf

نام اصلی کاربر می‌تواند به‌عنوان Metadata در Database ذخیره شود، اما نباید ضرورتاً مسیر واقعی Disk را تعیین کند.

Archive Directory Traversal یا Zip Slip چیست؟

یکی از حالت‌های مهم Path Traversal هنگام Extract کردن Archiveها رخ می‌دهد.

یک Archive مانند ZIP فقط مجموعه‌ای از Byteها نیست؛ هر Entry داخل Archive یک Filename یا Path نیز دارد.

اگر Extractor بدون کنترل مسیر Entryها آنها را روی Disk بنویسد، ممکن است فایل از Destination Directory تعیین‌شده خارج شود.

OWASP Web Security Testing Guide این سناریو را با عنوان Archive Directory Traversal مطرح می‌کند و توصیه می‌کند مسیر فایل‌های داخل Archive قبل از استخراج از نظر خروج از Target Directory بررسی شود.

برای جلوگیری از این مشکل باید برای هر Entry:

مسیر مقصد ساخته شود،

Canonical یا Normalize شود،

بررسی شود داخل Extraction Root قرار دارد،

و فقط پس از تأیید این شرط فایل روی Disk نوشته شود.

این کنترل برای ZIP، TAR و سایر Archive Formatها اهمیت دارد.

Path Traversal چه خطراتی دارد؟

اثر Path Traversal به نوع File Operation بستگی دارد.

یک برنامه ممکن است فقط قابلیت Read داشته باشد.

برنامه دیگری ممکن است File Write، Delete، Rename یا Extract انجام دهد.

به همین دلیل Severity همیشه یکسان نیست.

CWE-22 پیامدهای ممکن را در حوزه Confidentiality، Integrity و Availability طبقه‌بندی می‌کند.

افشای فایل‌های حساس

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

این فایل‌ها ممکن است شامل Configuration، Log، Backup، Source Code یا داده‌های برنامه باشند.

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

افشای تنظیمات برنامه

Configuration Fileها ممکن است اطلاعات مهمی درباره معماری سیستم داشته باشند.

در یک طراحی امنیتی مناسب، Secretها نباید به‌صورت Plaintext و با دسترسی گسترده روی Disk نگهداری شوند.

ولی در عمل ممکن است فایل‌های تنظیمات حاوی Database Connection Information، API Credential یا سایر تنظیمات حساس باشند.

بنابراین Path Traversal فقط یک ضعف «مشاهده فایل» نیست؛ گاهی می‌تواند بخشی از زنجیره بزرگ‌تری باشد.

افشای Source Code

Source Code می‌تواند اطلاعات قابل‌توجهی درباره Application Logic، APIها، ساختار Database، مسیرهای داخلی و کنترل‌های امنیتی در اختیار فرد غیرمجاز قرار دهد.

حتی اگر Credential مستقیمی داخل Source وجود نداشته باشد، افشای Code می‌تواند Attack Surface را بسیار واضح‌تر کند.

تغییر فایل

اگر Endpoint آسیب‌پذیر قابلیت Write داشته باشد، خطر بیشتر می‌شود.

در چنین شرایطی ممکن است File Integrity از بین برود.

CWE-22 امکان Modify یا ایجاد فایل‌های غیرمجاز را یکی از پیامدهای این ضعف می‌داند.

حذف یا خراب شدن فایل

قابلیت Delete یا Overwrite می‌تواند Availability را تحت تأثیر قرار دهد.

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

این دلیل دیگری برای اهمیت Least Privilege است.

دور زدن کنترل دسترسی

گاهی Path Traversal به‌تنهایی باعث عبور از Authentication نمی‌شود اما ممکن است Resourceای را در دسترس قرار دهد که Application قصد محافظت از آن را داشته است.

بنابراین Directory Traversal با Access Control ارتباط نزدیکی دارد.

OWASP WSTG نیز تست Directory Traversal و File Include را در بخش Authorization قرار داده است.

تفاوت Path Traversal با Local File Inclusion چیست؟

Path Traversal و Local File Inclusion یا LFI ممکن است در ظاهر شبیه باشند.

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

اما مفهوم آنها کاملاً یکسان نیست.

هر LFI ممکن است از تکنیک‌های Traversal استفاده کند، اما هر Path Traversal الزاماً LFI نیست.

برای مثال یک Endpoint دانلود که فقط محتویات یک فایل را به کاربر می‌فرستد می‌تواند Path Traversal داشته باشد بدون اینکه آن فایل به‌عنوان Code در برنامه Include شود.

تفاوت Path Traversal با IDOR چیست؟

IDOR یا Insecure Direct Object Reference بیشتر به Authorization مربوط است.

در IDOR، کاربر یک Object Identifier را تغییر می‌دهد و به Resource متعلق به کاربر دیگری دسترسی پیدا می‌کند، چون Server بررسی مجوز مناسبی انجام نمی‌دهد.

در Path Traversal، مسئله اصلی File System Path و خروج از محدوده مجاز است.

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

برای مثال ابتدا کاربر بتواند سند کاربر دیگری را انتخاب کند و سپس از Path محدودشده نیز خارج شود.

بنابراین در File Download باید هم Authorization بررسی شود و هم Path Validation.

تفاوت Path Traversal با Unrestricted File Upload چیست؟

Unrestricted File Upload به این معناست که برنامه کنترل کافی روی فایل‌های دریافتی ندارد.

Path Traversal مربوط به مسیر است.

اما این دو ضعف می‌توانند به یکدیگر متصل شوند.

برای مثال Filename آپلودشده ممکن است روی Destination Path اثر بگذارد.

به همین دلیل طراحی Upload امن باید هم Content را کنترل کند و هم Filename و مسیر Storage را.

Path Traversal چگونه به‌صورت امن شناسایی می‌شود؟

در تست امنیتی دفاعی، هدف اصلی باید مشخص کردن این موضوع باشد که User Input روی File System Path تأثیر دارد یا خیر.

نیازی نیست برای اثبات یک ضعف، فایل حساس واقعی خوانده یا تغییر داده شود.

Code Review

بهترین روش برای بسیاری از موارد Directory Traversal بررسی Source Code است.

ابتدا Sourceهای ورودی مشخص می‌شوند:

Request Parameter، Form، JSON Body، Header، Cookie، Database Field قابل‌کنترل، Filename آپلودی و Metadata خارجی.

سپس Sinkها مشخص می‌شوند.

Sink می‌تواند هر تابعی باشد که عملیات File System انجام می‌دهد:

Read، Open، Include، Download، Write، Rename، Delete، Copy، Move یا Extract.

بعد Data Flow بررسی می‌شود:

Untrusted Input
      ↓
Path Construction
      ↓
Normalization / Validation
      ↓
File API

اگر مرحله Validation وجود ندارد یا ضعیف است، مسیر باید دقیق‌تر بررسی شود.

SAST

Static Application Security Testing می‌تواند Source-to-Sink Flow را بررسی کند.

برای مثال Scanner می‌تواند متوجه شود داده Request بدون Validation مناسب وارد File API شده است.

با این حال False Positive و False Negative امکان‌پذیر است.

بنابراین نتیجه SAST باید توسط توسعه‌دهنده یا AppSec Engineer بررسی شود.

DAST

در Dynamic Testing می‌توان در یک محیط مجاز مانند Staging بررسی کرد که آیا Endpoint اجازه دسترسی به Resource خارج از Directory مورد انتظار را می‌دهد.

بهتر است فایل Canary بی‌خطر مخصوص تست در خارج از Root آزمایشی ایجاد شود.

اگر Application برخلاف انتظار قادر به خواندن آن باشد، مشکل بدون دسترسی به داده واقعی Production اثبات شده است.

OWASP WSTG برای ارزیابی Directory Traversal بر شناسایی Systematic Input Vectorها و بررسی روش پردازش آنها تأکید می‌کند.

بهترین روش جلوگیری از Path Traversal چیست؟

بهترین دفاع این است که اصلاً اجازه ندهیم کاربر Path واقعی File System را کنترل کند.

این اصل از هر Filter پیچیده‌ای مؤثرتر است.

OWASP نیز توصیه می‌کند در صورت امکان File System Callها بدون ورودی مستقیم کاربر طراحی شوند و به‌جای دریافت بخش‌های واقعی Filename از Index یا شناسه استفاده شود.

از شناسه به‌جای مسیر استفاده کنید

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

به‌جای اینکه Client نام فایل را ارسال کند، می‌توان Mapping داخلی ساخت:

guide   → public-documents/guide.pdf
rules   → public-documents/rules.pdf
faq     → public-documents/faq.pdf

کاربر فقط guide را انتخاب می‌کند.

او هیچ اطلاعاتی درباره ساختار واقعی File System ارسال نمی‌کند.

این روش Attack Surface را به‌شدت کاهش می‌دهد.

Allowlist؛ یکی از مؤثرترین کنترل‌ها

اگر تعداد فایل‌ها، زبان‌ها، Templateها یا Themeهای ممکن محدود است، Allowlist انتخاب مناسبی است.

یعنی برنامه به‌صورت پیش‌فرض همه مقادیر را رد کند و فقط گزینه‌های مشخص را بپذیرد.

برای مثال:

این طراحی از Blocklist امن‌تر است.

Blocklist تلاش می‌کند ورودی‌های «بد» را پیش‌بینی کند.

Allowlist فقط ورودی‌هایی را می‌پذیرد که دقیقاً با Business Requirement مطابقت دارند.

CWE-22 نیز استفاده از رویکرد Accept Known Good را یکی از Mitigationهای اصلی معرفی می‌کند.

Canonicalization چیست و چرا اهمیت دارد؟

یک Path می‌تواند از نظر ظاهری با Path دیگر متفاوت باشد ولی در نهایت به همان Location اشاره کند.

Canonicalization یعنی تبدیل Path به نمایش استاندارد و نهایی آن قبل از تصمیم‌گیری امنیتی.

در PHP تابع realpath() برای این کار استفاده می‌شود و براساس مستندات رسمی PHP، Symbolic Linkها و اجزای نسبی مسیر را Resolve کرده و یک Absolute Canonical Path برمی‌گرداند.

اما Canonicalization به‌تنهایی کافی نیست.

پس از Canonicalization باید بررسی شود Path نهایی واقعاً داخل Base Directory مجاز قرار گرفته است.

مدل مفهومی صحیح چنین است:

User-selected resource
        ↓
Construct candidate path
        ↓
Canonicalize
        ↓
Verify path is inside allowed base directory
        ↓
Perform file operation

اگر مسیر نهایی خارج از Base Directory باشد، Request باید رد شود.

چرا ابتدا Normalize و سپس Validate؟

اعتبارسنجی یک Path خام ممکن است گمراه‌کننده باشد.

Application یک String می‌بیند، اما File System آن را ممکن است بعداً به شکل دیگری Resolve کند.

اگر Validation قبل از Normalization انجام شود، برنامه ممکن است درباره رشته‌ای تصمیم بگیرد که با Path واقعی روی Disk یکسان نیست.

به همین دلیل باید تصمیم امنیتی روی Representation نهایی و Canonical گرفته شود.

البته ترتیب دقیق به API و زبان بستگی دارد و تیم توسعه باید Documentation همان Platform را بررسی کند.

فقط نام فایل را بپذیرید، نه مسیر کامل

اگر Business Requirement فقط انتخاب Filename است، نیازی نیست کاربر Directory Separator یا Path کامل ارسال کند.

در چنین حالتی ورودی را به یک Filename یا Identifier محدود کنید.

حتی بهتر است Server خودش Filename واقعی را تولید کند.

در Upload نیز Client Filename نباید Destination Path را تعیین کند.

تفاوت Sanitization نام فایل با Validation مسیر

این نکته به‌خصوص در WordPress اهمیت دارد.

WordPress تابع sanitize_file_name() را برای پاک‌سازی Filename ارائه می‌کند. این تابع Characterهای مختلف را از نام فایل حذف یا تبدیل می‌کند؛ اما Documentation رسمی WordPress صراحتاً می‌گوید خروجی آن حتی تضمین نمی‌کند فایل نهایی برای Upload مجاز باشد.

پس:

Sanitize Filename ≠ Path Authorization

ممکن است Filename تمیز شده باشد ولی Application همچنان Path را به شکل ناامن بسازد.

برای کنترل Path باید قواعد Directory و Allowlist جداگانه بررسی شوند.

Path Traversal در وردپرس

WordPress Core دارای APIهای مختلفی برای کار با فایل‌هاست.

در توسعه Plugin و Theme بهتر است تا حد امکان از APIهای Core به‌جای پیاده‌سازی دستی عملیات امنیتی استفاده شود.

WordPress تابع validate_file() را در اختیار دارد که نام و مسیر فایل را براساس قواعد تعریف‌شده بررسی می‌کند و در Documentation رسمی آن Path Traversal یکی از شرایط نامعتبر محسوب می‌شود. این تابع همچنین می‌تواند فایل را در برابر فهرست Allowed Files بررسی کند.

این موضوع برای توسعه‌دهندگان Plugin بسیار مهم است.

اگر Plugin دارای قابلیت‌هایی مانند:

File Download، Backup، Import/Export، Log Viewer، Template Editor، Theme Import، Translation Loader یا File Manager

باشد، ورودی‌های مرتبط با Filename و Path باید با دقت بررسی شوند.

از APIهای استاندارد آپلود وردپرس استفاده کنید

WordPress برای Upload نیز API اختصاصی دارد.

مستندات wp_handle_upload() و تابع داخلی آن نشان می‌دهد WordPress هنگام Upload فرآیندهایی مانند Sanitization نام فایل، بررسی Extension و MIME و انتقال به Upload Directory را مدیریت می‌کند.

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

محدود کردن Permissionهای سیستم‌عامل

Secure Coding باید اولین دفاع باشد.

اما اگر Application دچار خطا شد، Permissionهای سیستم‌عامل می‌توانند Blast Radius را کاهش دهند.

Process وب نباید بیش از نیاز واقعی به File System دسترسی داشته باشد.

اگر Application فقط باید فایل‌های Upload را بخواند و بنویسد، دلیلی ندارد بتواند همه دایرکتوری‌های سیستم را Modify کند.

اصل Least Privilege در اینجا اهمیت زیادی دارد.

Service Account باید فقط به دایرکتوری‌های موردنیاز دسترسی داشته باشد.

فایل‌های حساس باید Permission محدود داشته باشند.

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

فایل‌های حساس را داخل Web Root قرار ندهید

OWASP توصیه می‌کند فایل‌های Configuration حساس در Web Root نگهداری نشوند.

این راهکار دو مزیت دارد.

اول، خطای Web Server یا Static File Serving کمتر احتمال دارد فایل حساس را مستقیماً منتشر کند.

دوم، Attack Surface مرتبط با مسیرهای عمومی کاهش پیدا می‌کند.

این کنترل به‌تنهایی Path Traversal را حل نمی‌کند، اما بخشی از Defense in Depth است.

Symbolic Linkها را فراموش نکنید

بررسی امنیتی Path فقط بررسی Text نیست.

Symbolic Link می‌تواند Path ظاهراً مجاز را به Location دیگری هدایت کند.

به همین دلیل Canonicalization باید قبل از تصمیم امنیتی انجام شود.

اگر Application اجازه ایجاد یا تغییر Symlink دارد، Threat Model پیچیده‌تر می‌شود.

در سیستم‌های حساس باید مشخص شود چه Processی اجازه ایجاد Symbolic Link دارد و آیا مسیر Resolveشده پس از دنبال کردن Link همچنان داخل Root مجاز است یا خیر.

عملیات Write نیازمند احتیاط بیشتری است

در Read Operation معمولاً Path موجود است و Canonicalization ساده‌تر انجام می‌شود.

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

برای مثال realpath() در PHP در صورت نبودن Path ممکن است false برگرداند.

بنابراین در عملیات Write نباید صرفاً تابعی که برای Existing Path طراحی شده است کورکورانه استفاده شود.

معمولاً باید Parent Directory نهایی Canonical شود، محل مقصد بررسی شود و از APIهای امن Platform استفاده شود.

این مسئله باید براساس زبان و Framework مورد استفاده پیاده‌سازی شود.

مراقب Race Condition باشید

در سیستم‌های حساس ممکن است بین لحظه Validate کردن Path و لحظه Open کردن فایل، وضعیت File System تغییر کند.

این مسئله با مفهوم Time-of-Check to Time-of-Use یا TOCTOU ارتباط دارد.

در محیط‌هایی که User یا Process دیگری قادر به تغییر Symlink یا Directory Structure است، بهتر است از APIهایی استفاده شود که Validation و File Operation را تا حد امکان به‌صورت Atomic یا Handle-Based انجام می‌دهند.

این سطح از Hardening معمولاً در Applicationهای چندکاربره، Shared Hosting، Container Platformها یا سرویس‌های پردازش فایل حساس‌تر اهمیت بیشتری پیدا می‌کند.

مدیریت صحیح Error Messageها

Error نباید اطلاعات اضافی درباره File System افشا کند.

نمایش Full Path، Stack Trace یا Internal Directory Structure به کاربر می‌تواند اطلاعات مفیدی برای شناسایی معماری سیستم فراهم کند.

CWE-22 نیز توصیه می‌کند Error Messageها حداقل اطلاعات لازم را نمایش دهند و جزئیات فنی در Logهای امن نگهداری شوند.

در Production بهتر است کاربر پیام عمومی ببیند:

فایل موردنظر در دسترس نیست.

در حالی که Server Log می‌تواند جزئیات موردنیاز تیم فنی را با رعایت سیاست Logging ثبت کند.

آیا WAF جلوی Path Traversal را می‌گیرد؟

Web Application Firewall می‌تواند برخی Requestهای مشکوک را تشخیص دهد.

CWE نیز WAF را به‌عنوان یک کنترل دفاعی مکمل مطرح می‌کند، ولی اثربخشی آن را محدود می‌داند و اشاره می‌کند تمام Vectorها یا تغییر شکل‌های ورودی الزاماً توسط Firewall پوشش داده نمی‌شوند.

بنابراین:

WAF جایگزین اصلاح Code نیست.

اگر Application مسیر را به شکل ناامن می‌سازد، Ruleهای WAF فقط یک لایه اضافه هستند.

کنترل اصلی باید در خود Application اجرا شود.

Logging و Monitoring برای Directory Traversal

تلاش‌های Path Traversal می‌توانند در Logها قابل‌مشاهده باشند، اما Monitoring نباید فقط بر یک Pattern مشخص تکیه کند.

بهتر است رفتارهای غیرعادی نیز بررسی شوند.

برای مثال:

درخواست مکرر فایل ناموجود، تعداد بالای خطاهای File Access، درخواست Resourceهایی خارج از Pattern معمول، افزایش خطاهای Path Validation و تلاش برای دسترسی به File Endpointهای غیرمعمول.

در صورت امکان Application باید Security Event جداگانه‌ای برای Path Validation Failure ثبت کند.

اما Log نباید Secret یا محتوای کامل فایل حساس را ذخیره کند.

چک‌لیست دفاعی جلوگیری از Path Traversal

• ورودی کاربر را مستقیماً به File System Path تبدیل نکنید؛ از Identifier یا Mapping داخلی استفاده کنید؛ برای Filenameها و Resourceها Allowlist تعریف کنید؛ مسیر را قبل از تصمیم امنیتی Normalize یا Canonicalize کنید؛ پس از Canonicalization بررسی کنید مسیر نهایی داخل Base Directory مجاز باشد؛ Absolute Path ورودی را نپذیرید مگر نیاز بسیار مشخص و کنترل‌شده وجود داشته باشد؛ Filename آپلودی را به‌عنوان Destination Path استفاده نکنید؛ برای فایل‌های ذخیره‌شده نام داخلی تولید کنید؛ Archive Entryها را قبل از Extract بررسی کنید؛ Symbolic Linkها را در Threat Model لحاظ کنید؛ Application را با Least Privilege اجرا کنید؛ فایل‌های حساس و Configuration را در صورت امکان خارج از Web Root نگه دارید؛ Error Messageهای Production نباید Internal Path را افشا کنند؛ از APIها و Frameworkهای استاندارد مدیریت فایل استفاده کنید؛ در WordPress از توابع Core مرتبط مانند validate_file() و APIهای استاندارد Upload استفاده کنید؛ SAST و Code Review برای File APIها انجام دهید؛ DAST را فقط در محیط مجاز و با فایل Canary بی‌خطر اجرا کنید؛ Logging و Monitoring برای Path Validation Failure فعال کنید؛ WAF را تنها به‌عنوان Defense in Depth در نظر بگیرید؛ Permission فایل‌ها و دایرکتوری‌ها را دوره‌ای بازبینی کنید.

اشتباهات رایج در جلوگیری از Directory Traversal

فقط مسدود کردن یک Pattern

یکی از رایج‌ترین اشتباهات این است که توسعه‌دهنده یک String شناخته‌شده مربوط به Parent Directory را جست‌وجو و حذف کند.

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

مسیرها ممکن است قبل و بعد از URL Decoding، Unicode Processing یا Normalization شکل متفاوتی داشته باشند.

همچنین Windows و Unix در بعضی جزئیات Path Handling تفاوت دارند.

امنیت باید براساس Path Canonical و Directory Boundary طراحی شود.

استفاده از Replace

گاهی برنامه Characterهای خاص را با replace() حذف می‌کند.

این یک Blocklist شکننده است.

اگر Business Requirement اجازه می‌دهد، بهتر است اصلاً Path دریافت نشود.

اعتماد به Extension

اینکه فایل با .pdf تمام شود نشان نمی‌دهد Path امن است.

Extension Validation و Path Validation دو موضوع متفاوت هستند.

اعتماد به Filename Sanitization

همان‌طور که در WordPress دیدیم، Sanitization Filename هدف مشخصی دارد اما جایگزین Validation مسیر نیست.

اعتماد به Front-End

Dropdown، JavaScript Validation یا Hidden Input کنترل امنیتی سمت سرور محسوب نمی‌شوند.

Request می‌تواند بدون UI ارسال شود.

Backend باید تمام محدودیت‌ها را دوباره اعمال کند.

بررسی Path قبل از Decode کامل

Application Stack ممکن است چند مرحله Decode یا Normalize داشته باشد.

اگر Security Check روی یک Representation انجام شود ولی File API Representation دیگری دریافت کند، امکان اختلاف ایجاد می‌شود.

باید ترتیب Transformationهای داده مشخص باشد.

اجرای وب‌سرور با Permission زیاد

حتی یک Path Traversal محدود در Process دارای Privilege زیاد می‌تواند پیامد جدی‌تری داشته باشد.

Least Privilege یک کنترل بنیادی است.

استفاده از Filename دیتابیس به‌عنوان داده Trusted

اینکه مقدار از Database خوانده شده لزوماً Trusted بودن آن را ثابت نمی‌کند.

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

اگر User Input بوده، ذخیره شدن Trust Level آن را تغییر نمی‌دهد.

اگر Path Traversal در سایت پیدا شد چه کنیم؟

اول باید Endpoint آسیب‌پذیر محدود یا غیرفعال شود، به‌خصوص اگر بدون Authentication در دسترس باشد.

سپس مسیر Data Flow مشخص شود.

باید بدانیم:

ورودی از کجا وارد شده است؟

آیا Path فقط برای Read استفاده می‌شود یا Write/Delete نیز ممکن است؟

Application Process به چه دایرکتوری‌هایی Permission دارد؟

آیا فایل‌های حساس در محدوده قابل دسترسی قرار دارند؟

آیا Logها شواهدی از سوءاستفاده نشان می‌دهند؟

پس از آن Code باید اصلاح شود.

ترجیحاً معماری از دریافت Path مستقیم به Identifier-based Access تغییر کند.

اگر این تغییر ممکن نیست، Canonicalization، Root Boundary Check و Allowlist باید پیاده‌سازی شود.

بعد از Patch نیز Regression Test ضروری است.

فقط رفع یک Endpoint کافی نیست؛ باید سایر File Operationهای Codebase بررسی شوند زیرا Anti-Pattern مشابه ممکن است در چند بخش تکرار شده باشد.

Incident Response پس از Path Traversal

اگر شواهدی وجود دارد که ضعف در Production قابل سوءاستفاده بوده، فقط Patch کردن Code کافی نیست.

باید بررسی شود چه فایل‌هایی در دسترس Process قرار داشته‌اند.

Application Log، Reverse Proxy Log، WAF Log و Audit Logهای سیستم می‌توانند کمک‌کننده باشند.

اگر احتمال افشای Credential یا Secret وجود دارد، Rotation آنها باید بررسی شود.

اگر Vulnerability قابلیت Write داشته است، File Integrity نیز باید ارزیابی شود.

Timestamp فایل‌ها، تغییر Configuration، فایل‌های جدید غیرمنتظره و رفتار Processها باید براساس Incident Response Procedure سازمان بررسی شوند.

هدف فقط این نیست که «باگ بسته شود».

باید مشخص شود آیا قبل از Patch اتفاق امنیتی رخ داده است یا خیر.

Path Traversal در معماری Cloud و Container

در Cloud نیز File System همچنان می‌تواند Attack Surface باشد.

Container ممکن است Volume Mount داشته باشد.

یک Microservice ممکن است به Shared Storage متصل باشد.

یک Function ممکن است Temporary Storage داشته باشد.

در این محیط‌ها علاوه بر Secure Coding باید Isolation معماری را نیز در نظر گرفت.

Container نباید Volumeهای غیرضروری Mount کند.

Mountها در صورت امکان Read-Only باشند.

Secretها فقط در اختیار سرویس‌هایی قرار گیرند که واقعاً به آنها نیاز دارند.

Service Account و IAM Policy حداقلی باشند.

اگر یک File Processing Service نیاز به دسترسی به /uploads دارد، دلیلی ندارد Volume مربوط به Backup یا Configuration سایر Serviceها نیز در اختیار آن قرار گیرد.

این رویکرد Blast Radius یک ضعف احتمالی را کاهش می‌دهد.

Path Traversal و معماری Multi-Tenant

در SaaSهای چندمستاجری، فقط Directory Boundary کافی نیست.

Tenant Boundary نیز باید وجود داشته باشد.

فرض کنید فایل‌ها در چنین ساختاری ذخیره شوند:

/storage
    /tenant-a
    /tenant-b
    /tenant-c

حتی اگر کاربر نتواند از /storage خارج شود، نباید بتواند به Directory Tenant دیگر دسترسی پیدا کند.

بنابراین مسیر مجاز باید براساس Tenant فعلی ساخته شود.

Authorization باید قبل از File Operation انجام شود.

بهتر است Client حتی نام Tenant Directory را کنترل نکند.

روش امن طراحی Download Endpoint

یک الگوی مناسب برای Download می‌تواند چنین باشد:

Client sends:
document_id

Server:
1. document_id را اعتبارسنجی می‌کند.
2. رکورد سند را از Database دریافت می‌کند.
3. بررسی می‌کند کاربر مجوز دسترسی به سند را دارد.
4. مسیر داخلی را از داده Trusted دریافت می‌کند.
5. مسیر را Canonicalize می‌کند.
6. قرار گرفتن مسیر در Storage Root را تأیید می‌کند.
7. فایل را با API امن ارسال می‌کند.

در این طراحی کاربر هرگز File System Path ارسال نمی‌کند.

همچنین Authorization از Path Validation جدا باقی می‌ماند.

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

روش امن طراحی فایل‌های زبان و Template

اگر Application پنج زبان را پشتیبانی می‌کند، فقط همین پنج مقدار باید معتبر باشند.

نیازی نیست User Input مستقیماً نام فایل Translation باشد.

می‌توان Mapping ثابت داشت:

fa → language-fa
en → language-en
de → language-de

همین اصل برای Theme، Report Template و Export Format نیز کاربرد دارد.

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

چرا Path Traversal هنوز مهم است؟

ممکن است Directory Traversal یک آسیب‌پذیری قدیمی به نظر برسد، اما علت بروز آن هنوز در نرم‌افزارهای مدرن وجود دارد:

Applicationها همچنان فایل می‌خوانند.

Upload دارند.

Archive استخراج می‌کنند.

Backup می‌سازند.

Template و Translation File استفاده می‌کنند.

و Microserviceها با Shared Storage تعامل دارند.

به همین دلیل CWE-22 همچنان یک Weakness پایه و مستقل از زبان محسوب می‌شود. نسخه جاری صفحه CWE نیز آن را Language-Agnostic طبقه‌بندی می‌کند.

بنابراین مسئله به PHP یا یک CMS خاص محدود نیست.

هر برنامه‌ای که ورودی غیرقابل‌اعتماد را وارد Path Construction کند می‌تواند در معرض این ضعف قرار بگیرد.

سؤالات متداول درباره Path Traversal

Path Traversal چیست؟

Path Traversal آسیب‌پذیری‌ای است که در آن ورودی غیرقابل‌اعتماد روی مسیر فایل اثر می‌گذارد و Application به‌درستی اطمینان حاصل نمی‌کند که Path نهایی داخل Directory مجاز باقی مانده است.

Directory Traversal با Path Traversal فرق دارد؟

در استفاده عمومی تقریباً به یک خانواده مشکل اشاره می‌کنند. Path Traversal اصطلاح جامع‌تر و نام مورد استفاده CWE-22 است.

شناسه CWE آسیب‌پذیری Path Traversal چیست؟

MITRE آن را عمدتاً با CWE-22 یعنی Improper Limitation of a Pathname to a Restricted Directory ثبت کرده است.

Path Traversal فقط برای خواندن فایل است؟

خیر. بسته به File API، آسیب‌پذیری می‌تواند Read، Write، Create، Delete یا سایر عملیات فایل را تحت تأثیر قرار دهد. CWE-22 پیامدهایی برای Confidentiality، Integrity و Availability ذکر می‌کند.

آیا Path Traversal می‌تواند خطرناک باشد؟

بله. شدت آن به Permission برنامه و نوع عملیات بستگی دارد. افشای Source Code، Configuration و اطلاعات حساس یا در برخی شرایط تغییر فایل‌ها از پیامدهای ممکن هستند.

آیا WAF جلوی Directory Traversal را می‌گیرد؟

WAF می‌تواند لایه دفاعی مکمل باشد، اما نباید کنترل اصلی باشد. CWE نیز Firewall را کنترل با اثربخشی محدود معرفی می‌کند، زیرا همه Input Vectorها و شکل‌های پردازش مسیر لزوماً قابل شناسایی نیستند.

بهترین روش جلوگیری از Path Traversal چیست؟

بهترین روش این است که User Input اصلاً File System Path را تعیین نکند. از Identifier و Mapping داخلی استفاده کنید. اگر Path دینامیک ضروری است، Allowlist، Canonicalization و Directory Boundary Check باید اعمال شوند.

Canonicalization چیست؟

Canonicalization فرآیند تبدیل یک Path به شکل نهایی و استاندارد است تا اجزای نسبی، Linkها و تفاوت‌های Representation قبل از Validation امنیتی Resolve شوند.

آیا realpath در PHP برای جلوگیری از Path Traversal کافی است؟

خیر. realpath() مسیر Canonical را به دست می‌دهد، اما Application همچنان باید بررسی کند مسیر نهایی در Base Directory مجاز قرار گرفته است. همچنین این تابع در برخی شرایط مانند Pathهای موجود نباشند رفتار متفاوتی دارد و Documentation آن باید در طراحی لحاظ شود.

آیا sanitize_file_name وردپرس از Path Traversal جلوگیری می‌کند؟

نباید به‌تنهایی به آن تکیه کرد. sanitize_file_name() برای Sanitization Filename طراحی شده است. WordPress توابع و کنترل‌های دیگری مانند validate_file() نیز برای اعتبارسنجی Path ارائه می‌کند.

Path Traversal در افزونه وردپرس ممکن است رخ دهد؟

بله، اگر Plugin یا Theme عملیات فایل انجام دهد و Path را از User Input به شکل ناامن بسازد، امکان بروز این ضعف وجود دارد. قابلیت‌های Backup، Import، Export، Log Viewer، Template و Download از نقاطی هستند که باید بررسی شوند.

آیا تغییر نام فایل آپلودشده اهمیت دارد؟

بله. بهتر است Application برای Storage نام داخلی ایجاد کند و نام اصلی فایل فقط به‌عنوان Metadata نگهداری شود. این کار کنترل مسیر و Collision فایل‌ها را ساده‌تر می‌کند.

Zip Slip چه ارتباطی با Path Traversal دارد؟

Zip Slip یا Archive Directory Traversal زمانی رخ می‌دهد که Pathهای داخل Archive هنگام استخراج کنترل نشوند و یک Entry بتواند خارج از Destination Directory نوشته شود. OWASP این سناریو را در راهنمای تست Upload پوشش داده است.

جمع‌بندی

Path Traversal یا Directory Traversal یکی از آسیب‌پذیری‌های مهم مدیریت فایل در وب‌سایت‌ها و نرم‌افزارهاست که ریشه آن در شکسته شدن مرز میان «Resource موردنظر کاربر» و «Path واقعی File System» قرار دارد.

اگر Application ورودی غیرقابل‌اعتماد را مستقیماً وارد عملیات فایل کند و بررسی نکند مسیر نهایی در Directory مجاز قرار دارد، امکان دسترسی به Locationهای غیرمنتظره ایجاد می‌شود.

شدت آسیب‌پذیری به نوع عملیات بستگی دارد.

در یک Endpoint ممکن است فقط Confidentiality و افشای فایل مطرح باشد.

در Endpoint دیگری که Write، Delete یا Extract انجام می‌دهد، Integrity و Availability نیز می‌توانند تحت تأثیر قرار بگیرند.

بهترین راهکار جلوگیری از Path Traversal این است که Client اساساً Path واقعی ارسال نکند.

شناسه‌ها، Mappingهای داخلی و Allowlist باید جایگزین مسیرهای دلخواه شوند.

اگر مسیر دینامیک واقعاً ضروری است، Application باید آن را Normalize یا Canonicalize کند، محل نهایی را نسبت به Base Directory معتبر بررسی کند و سپس عملیات فایل را انجام دهد.

در کنار Secure Coding، کنترل‌هایی مانند Least Privilege، محدود کردن Permissionهای File System، نگهداری فایل‌های حساس خارج از Web Root، مدیریت امن Upload و Archive، کنترل Symbolic Link، Logging، Monitoring، SAST، DAST و Code Review می‌توانند Defense in Depth را ایجاد کنند.

در WordPress نیز توسعه‌دهندگان Plugin و Theme بهتر است از APIهای Core برای عملیات فایل استفاده کنند و بین Sanitization Filename و Validation Path تفاوت قائل شوند.

مهم‌ترین سؤال هنگام بررسی هر قابلیت File-Based این است:

«آیا کاربر فقط یک Resource مجاز را انتخاب می‌کند، یا می‌تواند روی مسیر واقعی File System تأثیر بگذارد؟»

اگر پاسخ قسمت دوم مثبت باشد، آن بخش باید از نظر Path Traversal با دقت بررسی و Hardening شود.