Directory Listing چیست؟ چرا نمایش فایل‌های سرور می‌تواند خطرناک باشد؟

Directory Listing یا فهرست‌کردن محتوای دایرکتوری زمانی رخ می‌دهد که وب‌سرور به‌جای نمایش یک صفحه مشخص مانند index.html یا index.php، فهرست فایل‌ها و پوشه‌های موجود در یک مسیر را به کاربر نشان دهد. اگر این قابلیت بدون نیاز واقعی روی مسیرهای عمومی فعال باشد، ممکن است نام فایل‌های پشتیبان، فایل‌های تنظیمات، سورس‌کد، Logها، Uploadها یا ساختار داخلی برنامه را آشکار کند و اطلاعات ارزشمندی در اختیار مهاجم قرار دهد.

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

مشاهده نام‌هایی مانند:

backup/
old/
logs/
uploads/
private/
database.sql
config-backup.php
website-old.zip

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

به همین دلیل Directory Listing بیشتر از اینکه یک «ظاهر ناخوشایند برای پوشه» باشد، نوعی Information Disclosure یا افشای اطلاعات محسوب می‌شود.

MITRE این ضعف را با شناسه CWE-548: Exposure of Information Through Directory Listing ثبت کرده است و توضیح می‌دهد که نمایش Index کامل یک دایرکتوری می‌تواند اطلاعات لازم برای دسترسی به فایل‌های محرمانه یا شناخت بهتر ساختار سیستم را افشا کند.

در این مقاله از رخنه‌کاو بررسی می‌کنیم Directory Listing چیست، چگونه فعال می‌شود، چه اطلاعاتی می‌تواند افشا کند، تفاوت آن با Path Traversal یا Forced Browsing چیست و چگونه می‌توان آن را در Apache، Nginx، IIS، وردپرس و سایر محیط‌های میزبانی به‌صورت اصولی مدیریت کرد.

Directory Listing چیست؟

Directory Listing یا Directory Indexing قابلیتی در وب‌سرور است که محتوای یک Directory را به شکل یک صفحه قابل مشاهده در مرورگر نمایش می‌دهد.

فرض کنید روی سرور مسیری مانند زیر وجود داشته باشد:

/var/www/example.com/public/downloads/

و داخل آن فایل‌های زیر ذخیره شده باشند:

manual.pdf
application.zip
archive/
images/
backup-old.zip

اگر کاربر درخواست زیر را ارسال کند:

https://example.com/downloads/

معمولاً وب‌سرور ابتدا بررسی می‌کند آیا فایل پیش‌فرضی مانند موارد زیر وجود دارد یا خیر:

index.html
index.htm
index.php
default.aspx

اگر Index File وجود داشته باشد، همان فایل نمایش داده می‌شود.

اما اگر فایل Index وجود نداشته باشد و Directory Listing نیز فعال باشد، ممکن است وب‌سرور صفحه‌ای شبیه این نمایش دهد:

Index of /downloads/

Name                 Last modified       Size
------------------------------------------------
archive/             2026-09-10          -
images/              2026-09-15          -
application.zip      2026-09-17          25 MB
backup-old.zip       2026-08-20          180 MB
manual.pdf           2026-09-18          4 MB

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

خود وب‌سرور آن‌ها را فهرست کرده است.

Directory Index چگونه کار می‌کند؟

رفتار دقیق به Web Server بستگی دارد، اما منطق معمول تقریباً یکسان است.

وقتی یک درخواست به یک Directory ارسال می‌شود، وب‌سرور معمولاً مراحل زیر را طی می‌کند:

Request:
https://example.com/files/
        ↓
آیا مسیر وجود دارد؟
        ↓
آیا Index File وجود دارد؟
        ↓
بله → نمایش Index File
خیر
        ↓
آیا Directory Listing فعال است؟
        ↓
بله → نمایش فهرست فایل‌ها
خیر → پاسخ Forbidden / Not Found / رفتار تعریف‌شده سرور

در Apache، مستندات رسمی توضیح می‌دهند که اگر هیچ DirectoryIndex مناسبی پیدا نشود و گزینه Indexes فعال باشد، mod_autoindex می‌تواند فهرست Directory را ایجاد کند.

در Nginx نیز ماژول ngx_http_autoindex_module برای تولید Directory Listing وجود دارد و معمولاً زمانی وارد عمل می‌شود که درخواست به Directory ختم شود و Index File پیدا نشود. تنظیم autoindex در Nginx به‌صورت پیش‌فرض off است.

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

کنترل اصلی باید روی تنظیمات خود Directory Browsing انجام شود.

یک نمونه ساده از Directory Listing

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

Index of /assets/

و سپس:

../
css/
js/
images/
backup/
release-v2.zip
release-v3.zip

ظاهر صفحه می‌تواند بسیار ساده باشد.

بعضی Web Serverها اطلاعات بیشتری نیز نمایش می‌دهند:

• نام فایل
• نوع فایل
• پسوند
• حجم
• تاریخ آخرین تغییر
• زیرپوشه‌ها
• توضیحات فایل
• لینک مستقیم Download

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

آیا Directory Listing همیشه آسیب‌پذیری است؟

خیر.

Directory Listing یک قابلیت است و وجود آن به‌تنهایی الزاماً به معنای آسیب‌پذیری نیست.

برای مثال یک سرور ممکن است عمداً برای ارائه مجموعه‌ای از فایل‌های عمومی طراحی شده باشد:

https://downloads.example.com/releases/

و فقط فایل‌های عمومی Software Release را نمایش دهد.

در این حالت Directory Listing می‌تواند بخشی از طراحی سرویس باشد.

مشکل زمانی ایجاد می‌شود که:

• قابلیت بدون نیاز واقعی فعال باشد.
• Directory شامل فایل‌هایی باشد که نباید عمومی باشند.
• ساختار داخلی برنامه را آشکار کند.
• فایل‌های Backup یا Log در همان مسیر قرار گرفته باشند.
• Access Control وجود نداشته باشد.
• Directory حاوی داده کاربران باشد.
• نام فایل‌ها اطلاعات حساس منتقل کنند.

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

آیا Directory Listing فعال است؟

بلکه باید پرسید:

کدام Directory فهرست می‌شود، چه اطلاعاتی داخل آن وجود دارد و چه کسی اجازه مشاهده آن را دارد؟

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

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

Directory Listing می‌تواند همین اطلاعات را فراهم کند.

OWASP Web Security Testing Guide نیز Directory Listing ناشی از پیکربندی نامناسب وب‌سرور را یکی از روش‌هایی می‌داند که می‌تواند صفحات و منابع بدون لینک مستقیم را آشکار کند.

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

گاهی خود نام فایل تقریباً تمام چیزی است که برای شناسایی یک Resource مهم لازم است.

برای مثال:

database-backup.sql
users-export.csv
config.old.php
site-backup.zip
debug.log
access.log
private-key.pem

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

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

افشای ساختار Directoryها

یک Listing ممکن است ساختار Application را آشکار کند:

/admin/
/api/
/backup/
/config/
/logs/
/private/
/storage/
/uploads/
/vendor/

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

• برنامه از چه معماری‌ای استفاده می‌کند.
• کدام Directoryها احتمالاً حساس‌تر هستند.
• فایل‌های کاربر کجا ذخیره می‌شوند.
• Backupها در چه مسیری قرار گرفته‌اند.
• چه Componentهایی در پروژه استفاده شده‌اند.

افشای فایل‌های Backup

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

برای مثال:

index.php.bak
config.php.old
website-backup.zip
db-2026-09-01.sql
public_html.tar.gz

مشکل Backup این است که Web Server ممکن است دیگر آن را به‌عنوان Script پردازش نکند.

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

config.php

ممکن است توسط PHP اجرا شود و Source Code آن نمایش داده نشود.

اما:

config.php.bak

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

در این حالت Credential، Connection String یا سایر اطلاعات داخلی ممکن است قابل مشاهده شوند.

افشای فایل‌های تنظیمات

بعضی پروژه‌ها فایل‌های Configuration را در Directoryهایی نگه می‌دارند که نباید مستقیماً از Web قابل دسترسی باشند.

نمونه‌ها:

.env
config.json
settings.yml
application.properties
web.config.backup
database.ini

Directory Listing ممکن است وجود چنین فایل‌هایی را آشکار کند.

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

این اصل بسیار مهم است:

مخفی بودن نام فایل ≠ Access Control

افشای Logها

گاهی Directoryهای Log به‌اشتباه زیر Document Root قرار می‌گیرند.

برای مثال:

/logs/
    access.log
    error.log
    app-debug.log
    payment.log

Logها ممکن است شامل اطلاعاتی مانند:

• مسیرهای داخلی
• Exceptionها
• Stack Trace
• IP Address
• شناسه کاربران
• URLهای داخلی
• Queryها
• Tokenهای اشتباهی Log‌شده
• نام Serviceها

باشند.

Directory Listing کشف این فایل‌ها را بسیار ساده‌تر می‌کند.

افشای فایل‌های Upload کاربران

فرض کنید Application فایل‌های کاربران را در مسیر زیر ذخیره کند:

/uploads/

اگر Directory Listing فعال باشد، ممکن است کاربر بتواند فهرست فایل‌های سایر کاربران را مشاهده کند.

حتی اگر نام فایل‌ها Random باشند، Listing آن‌ها را آشکار می‌کند.

برای مثال:

contract-ali.pdf
national-card-user-182.jpg
invoice-company-x.pdf
resume-person-y.docx

در این وضعیت مشکل فقط Directory Listing نیست؛ معماری Access Control فایل‌ها نیز باید اصلاح شود.

فایل خصوصی نباید صرفاً به‌دلیل داشتن URL غیرقابل حدس «خصوصی» محسوب شود.

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

گاهی هیچ Password یا Tokenی وجود ندارد، اما نام فایل‌ها اطلاعات مهمی منتقل می‌کنند.

برای مثال:

new-pricing-2027.xlsx
acquisition-plan.pdf
employees-list.csv
customer-export-september.csv
new-product-prototype.zip

پس Information Disclosure فقط به Credential محدود نیست.

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

تاریخ آخرین تغییر فایل چه خطری دارد؟

بعضی Listingها Modified Time را نمایش می‌دهند.

برای مثال:

backup.zip        2026-09-21 03:10
release.zip       2026-09-21 03:15

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

• Deployment چه زمانی انجام شده است.
• Backupها با چه الگویی ساخته می‌شوند.
• کدام نسخه جدیدتر است.
• کدام فایل هنوز در حال استفاده است.

این داده‌ها معمولاً به‌تنهایی بحرانی نیستند، اما در کنار سایر اطلاعات ارزش بیشتری پیدا می‌کنند.

حجم فایل نیز می‌تواند اطلاعات بدهد

برای مثال:

database.sql       4.7 GB
users.csv          820 MB
backup.zip         12 GB

حتی بدون Download، وجود و اندازه فایل می‌تواند ماهیت آن را مشخص‌تر کند.

امنیت اطلاعات فقط درباره محتوای File نیست.

Metadata نیز ممکن است ارزش امنیتی داشته باشد.

تفاوت Directory Listing با دسترسی مستقیم به فایل چیست؟

این دو موضوع مرتبط‌اند اما یکسان نیستند.

فرض کنید:

https://example.com/private/config.txt

قابل دسترسی باشد.

حتی اگر Listing غیرفعال باشد، اگر فرد نام دقیق File را بداند می‌تواند آن را دریافت کند.

پس:

Directory Listing Disabled

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

Files Protected

Directory Listing فقط مانع نمایش خودکار فهرست Resourceها می‌شود.

Access Control هر فایل باید مستقل بررسی شود.

تفاوت Directory Listing با Forced Browsing چیست؟

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

برای مثال:

/admin-old/
/backup/
/reports/2025/

Directory Listing می‌تواند Forced Browsing را ساده‌تر کند، زیرا Resourceها را مستقیماً فهرست می‌کند.

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

ممکن است Directory Listing خاموش باشد ولی فایل یا Directory مخفی همچنان بدون Authorization در دسترس باشد.

تفاوت Directory Listing با Path Traversal چیست؟

Path Traversal آسیب‌پذیری متفاوتی است.

در Path Traversal، برنامه ممکن است اجازه دهد کاربر از مسیر مجاز خارج شود و به Fileهای دیگری در File System دسترسی پیدا کند.

برای مثال مشکل مفهومی آن چنین است:

Application Controlled Directory
              ↓
User manipulates path
              ↓
Access outside intended directory

در Directory Listing، Web Server خودش فهرست فایل‌های Directory موجود در محدوده قابل دسترسی را نمایش می‌دهد.

بنابراین:

Directory Listing → افشای Index Directory
Path Traversal     → عبور غیرمجاز از محدوده مسیر

ممکن است یک سیستم هر دو مشکل را داشته باشد، اما Root Cause متفاوت است.

تفاوت Directory Listing با Local File Inclusion چیست؟

LFI نیز یک موضوع متفاوت است.

Local File Inclusion معمولاً زمانی ایجاد می‌شود که Application نام File یا Path را از ورودی کاربر دریافت کرده و آن را به شکل ناامن Include یا Load کند.

Directory Listing بیشتر Server Configuration است.

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

شدت Directory Listing چگونه تعیین می‌شود؟

هر Directory Listing شدت یکسانی ندارد.

حالت کم‌خطر

برای مثال:

/public-icons/

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

ریسک معمولاً پایین است.

حالت متوسط

Directory شامل:

old-assets/
internal-filenames/
previous-release/

باشد.

ممکن است اطلاعات معماری را آشکار کند.

حالت پرخطر

اگر Listing شامل:

backup.sql
source.zip
.env.backup
config.old
customers.csv
logs/
private/

باشد، خطر بسیار بالاتر است.

پس Severity باید براساس محتوای Directory و قابلیت دسترسی واقعی تعیین شود.

رایج‌ترین علت‌های فعال‌شدن Directory Listing

Directory Listing معمولاً به‌دلیل یک خطای ساده Deployment یا Configuration فعال می‌شود.

فعال‌کردن موقت و فراموش‌کردن آن

گاهی Administrator برای Troubleshooting Directory Browsing را فعال می‌کند و پس از پایان کار آن را خاموش نمی‌کند.

حذف Index File

ممکن است Directory سال‌ها دارای:

index.html

بوده باشد.

پس از تغییر Deployment فایل Index حذف می‌شود و ناگهان Listing ظاهر می‌شود.

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

تنظیمات اشتباه Apache

وجود:

Options +Indexes

می‌تواند Directory Indexing را فعال کند.

در Apache، گزینه Indexes اجازه می‌دهد اگر DirectoryIndex موجود نباشد، mod_autoindex Listing تولید کند.

تنظیمات اشتباه Nginx

در Nginx فعال‌کردن:

autoindex on;

در یک location می‌تواند Listing را فعال کند. مستندات رسمی Nginx مقدار پیش‌فرض autoindex را off اعلام می‌کنند.

فعال‌شدن Directory Browsing در IIS

IIS نیز قابلیت Directory Browsing دارد.

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

Configuration ارث‌بری‌شده

گاهی تنظیمات یک Directory والد به Child Directory منتقل می‌شوند.

در نتیجه Developer ممکن است فکر کند Listing برای یک مسیر خاص خاموش است درحالی‌که Rule دیگری روی آن اثر گذاشته است.

Shared Hosting

در Shared Hosting ممکن است تنظیمات:

• Apache
• .htaccess
• File Manager
• Control Panel

با یکدیگر تعامل داشته باشند.

یک تغییر ساده در .htaccess می‌تواند رفتار Directory را عوض کند.

جلوگیری از Directory Listing در Apache

در Apache یکی از رایج‌ترین تنظیمات دفاعی این است:

Options -Indexes

این Directive در Context مناسب باعث می‌شود قابلیت Indexing از Directory حذف شود.

برای مثال:

<Directory "/var/www/example/public">
    Options -Indexes
</Directory>

در محیط‌هایی که .htaccess مجاز است نیز ممکن است از:

Options -Indexes

استفاده شود.

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

Apache در مستندات خود توضیح می‌دهد که + و - برای اضافه یا حذف‌کردن Option نسبت به Context موجود استفاده می‌شوند.

آیا ساختن index.html کافی است؟

خیر.

بعضی مدیران برای جلوگیری از Listing فقط یک فایل خالی می‌سازند:

index.html

این کار می‌تواند نمایش فهرست را مخفی کند، اما Directory Indexing همچنان ممکن است فعال باشد.

اگر فایل Index بعداً حذف یا Rename شود، مشکل دوباره ظاهر می‌شود.

روش دفاعی بهتر:

Disable Directory Listing
+
Proper Access Control
+
Correct Document Root

است.

جلوگیری از Directory Listing در Nginx

در Nginx می‌توان مطمئن شد Autoindex غیرفعال است:

location / {
    autoindex off;
}

یا برای یک مسیر خاص:

location /uploads/ {
    autoindex off;
}

طبق مستندات Nginx، مقدار پیش‌فرض autoindex off است.

اگر روی سروری Listing مشاهده می‌شود، باید Configuration واقعی و تمام includeها بررسی شوند.

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

autoindex on;

اعمال شده باشد.

پس فقط بررسی یک فایل nginx.conf کافی نیست.

جلوگیری از Directory Listing در IIS

در IIS می‌توان Directory Browsing را از IIS Manager غیرفعال کرد.

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

<configuration>
    <system.webServer>
        <directoryBrowse enabled="false" />
    </system.webServer>
</configuration>

مایکروسافت مقدار پیش‌فرض enabled را false اعلام می‌کند.

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

Directory Listing در وردپرس

در سایت‌های وردپرسی نیز Directory Listing می‌تواند رخ دهد.

مسیرهای مهمی مانند:

/wp-content/
/wp-content/uploads/
/wp-content/plugins/
/wp-content/themes/

ممکن است در صورت Configuration نامناسب وب‌سرور Listing شوند.

خود مشاهده نام Plugin یا Theme همیشه به معنی آسیب‌پذیری مستقیم نیست، اما اطلاعات اضافی درباره ساختار سایت فراهم می‌کند.

برای مثال Directory زیر:

/wp-content/uploads/

اگر فایل‌های خصوصی یا اسناد کاربران را نگهداری کند، Directory Listing می‌تواند مشکل مهم‌تری ایجاد کند.

آیا مخفی‌کردن نسخه وردپرس با Directory Listing مرتبط است؟

مستقیم نه.

اما هر دو در دسته Information Exposure قابل بررسی هستند.

Directory Listing ممکن است نام Plugin، Theme یا فایل‌هایی را نشان دهد که اطلاعات بیشتری درباره Technology Stack می‌دهند.

هدف Hardening این نیست که تمام Technologyها کاملاً مخفی شوند.

هدف این است که اطلاعات غیرضروری در اختیار Client قرار نگیرند.

Directory Listing در WooCommerce

سایت‌های WooCommerce ممکن است فایل‌هایی مانند:

• Invoice
• Export
• Product File
• Report
• Customer Upload
• Backup

تولید کنند.

اگر این فایل‌ها در Directory عمومی ذخیره شوند و Listing نیز فعال باشد، خطر افزایش پیدا می‌کند.

به‌خصوص فایل‌های Downloadable Product یا Exportهای مدیریتی نباید صرفاً به ناشناخته‌بودن URL متکی باشند.

Authorization باید در Server اجرا شود.

Directory Listing در پوشه uploads

uploads یکی از مسیرهایی است که باید با دقت بررسی شود.

فرض کنید فایل‌ها با نام‌های Random ذخیره شوند:

93ad08f-file.pdf
9fc129b-image.jpg
0dd820a-contract.docx

اگر Directory Listing فعال باشد، مزیت نام Random از بین می‌رود.

وب‌سرور خودش همه نام‌ها را نمایش می‌دهد.

به همین دلیل برای داده خصوصی، معماری مناسب معمولاً یکی از این موارد است:

Private Storage خارج از Web Root

یا:

Application-controlled download
+
Authorization

یا:

Signed / Expiring URLs

بسته به نوع سیستم.

Directory Listing و فایل‌های Backup سایت

یکی از بدترین مکان‌ها برای Backup، همان Public Web Root است.

مثلاً:

/public_html/backup.zip
/public_html/db.sql
/public_html/site-old.tar.gz

حتی اگر Listing خاموش باشد، این فایل‌ها ممکن است با URL دقیق قابل دریافت باشند.

Listing فقط کشف آن‌ها را ساده‌تر می‌کند.

Backup بهتر است در Storage جداگانه و با Access Control مناسب نگهداری شود.

Directory Listing و فایل‌های Git

Directoryهایی مانند:

.git/
.svn/

نباید از طریق Web قابل دسترسی باشند.

این موضوع مستقل از Directory Listing است.

اگر Web Server امکان دریافت محتوای Repository Metadata را بدهد، Source Code و اطلاعات History می‌توانند در معرض خطر قرار گیرند.

پس Hardening باید شامل Deny Rule برای فایل‌ها و Directoryهای توسعه‌ای نیز باشد.

Directory Listing در محیط Development

فعال‌بودن Listing در یک Environment کاملاً Local ممکن است ریسک زیادی ایجاد نکند.

اما مشکلات زمانی رخ می‌دهند که Development Configuration بدون Hardening وارد Production شود.

برای مثال:

Development:
autoindex on

        ↓ Deployment

Production:
autoindex on

Pipeline باید تنظیمات Environmentها را جدا کند.

Directory Listing در Docker

Container بودن وب‌سرور چیزی از اصل موضوع تغییر نمی‌دهد.

اگر Nginx یا Apache داخل Container با Listing فعال اجرا شود، همان رفتار از بیرون مشاهده خواهد شد.

همچنین ممکن است Image حاوی Directoryهایی باشد که Developer انتظار نداشته Public شوند.

بنابراین باید:

• Document Root دقیق باشد.
• Build Context کنترل شود.
• فایل‌های Development وارد Image نشوند.
• Autoindex غیرفعال باشد.
• Mountها بررسی شوند.

Volume Mount و خطر Listing

فرض کنید Container مسیر زیر را Serve کند:

/usr/share/nginx/html

و Administrator اشتباهاً Volume بزرگی را روی آن Mount کند:

/data:/usr/share/nginx/html

در این شرایط فایل‌هایی که برای وب طراحی نشده‌اند ممکن است زیر Document Root ظاهر شوند.

اگر Autoindex نیز فعال باشد، محتوا مستقیماً فهرست می‌شود.

این مثال نشان می‌دهد Directory Listing فقط Configuration خود Web Server نیست؛ طراحی Deployment نیز مهم است.

CDN و Object Storage

Bucket Listing در Object Storage مفهومی شبیه Directory Listing دارد اما از نظر فنی همان ویژگی وب‌سرور نیست.

برای مثال یک Storage Bucket ممکن است اجازه Enumeration Objectها را بدهد.

اصل امنیتی مشترک است:

کاربری که فقط باید یک Object خاص را دریافت کند، نباید الزاماً فهرست همه Objectها را نیز ببیند.

در Cloud Storage باید Public Access، Bucket Policy، ACL و Signed URLها بررسی شوند.

Directory Listing و Search Engine

اگر Directory Listing عمومی باشد، در برخی شرایط ممکن است Crawlerها URLهای داخل آن را دنبال کنند.

بنابراین اطلاعاتی که تصور می‌شد «کسی لینک آن را ندارد» ممکن است وارد Search Index یا Cacheهای دیگر شود.

نباید از:

robots.txt

به‌عنوان Access Control استفاده کرد.

robots.txt فقط یک دستور برای Crawlerهای همکار است.

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

آیا noindex مشکل را حل می‌کند؟

خیر.

Meta noindex یا Headerهای مرتبط فقط روی Index شدن توسط Search Engine اثر دارند.

آن‌ها مانع دسترسی مستقیم Client به Directory نمی‌شوند.

پس:

SEO Control ≠ Security Access Control

آیا 403 بهتر از 404 است؟

از نظر امنیتی مهم‌ترین نکته این است که Resource غیرمجاز قابل مشاهده نباشد.

اینکه Application در سناریوی خاص:

403 Forbidden

یا:

404 Not Found

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

گاهی 404 برای کاهش Information Disclosure انتخاب می‌شود.

اما Security اصلی نباید صرفاً به Status Code وابسته باشد.

چگونه Directory Listing را روی سایت خودمان بررسی کنیم؟

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

بررسی Directoryهای شناخته‌شده

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

مثلاً:

https://example.com/uploads/
https://example.com/assets/
https://example.com/downloads/

اگر به‌جای صفحه برنامه، صفحه‌ای شامل نام Fileها نمایش داده شود، Listing فعال است.

نشانه‌های رایج

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

Index of /
Index of /uploads/
Directory Listing
Parent Directory

از نشانه‌های رایج هستند.

البته ظاهر دقیق به Web Server بستگی دارد.

بررسی با curl

روی سامانه خودتان می‌توانید Request ساده‌ای ارسال کنید:

curl -i https://example.com/uploads/

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

هدف از این تست فقط بررسی مسیرهای شناخته‌شده خودتان است، نه Enumeration بدون مجوز روی سامانه دیگر.

تست Negative پس از اصلاح

پس از Hardening باید بررسی شود:

Directory Request
        ↓
No Index File
        ↓
Directory Listing نمایش داده نمی‌شود

سپس مطمئن شوید Fileهای حساس نیز با URL مستقیم قابل دریافت نیستند.

این مرحله بسیار مهم است.

ممکن است Listing حذف شده باشد اما:

backup.zip

هنوز با URL مستقیم Download شود.

آیا Vulnerability Scanner می‌تواند Directory Listing را پیدا کند؟

بسیاری از ابزارهای Security Scanner می‌توانند برخی نمونه‌های Directory Indexing را شناسایی کنند.

اما Scanner جایگزین Review معماری نیست.

ابزار ممکن است:

• مسیر را نشناسد.
• فقط Directoryهای خاصی را بررسی کند.
• Listing سفارشی را تشخیص ندهد.
• Context حساسیت فایل‌ها را درک نکند.

به همین دلیل ترکیب:

Configuration Review
+
Manual Verification
+
Automated Testing

بهتر است.

راهکار اصلی جلوگیری از Directory Listing چیست؟

بهترین راهکار فقط یک Directive نیست.

باید چند لایه دفاعی وجود داشته باشد.

Directory Listing را به‌صورت پیش‌فرض خاموش کنید

اصل مناسب:

Default Deny

اگر Directory Listing واقعاً لازم است، فقط برای مسیر مشخص فعال شود.

Document Root را محدود کنید

تنها فایل‌هایی که باید از Web قابل دسترسی باشند داخل Public Root قرار گیرند.

ساختار مناسب:

/app/
    config/
    storage/
    logs/
    backups/
    source/

    public/
        index.php
        css/
        js/
        images/

Web Server باید فقط:

/app/public/

را Serve کند.

فایل‌های حساس را خارج از Public Root نگه دارید

مانند:

.env
database backup
logs
private uploads
source archives
private keys

Backup را خارج از Web Root ذخیره کنید

Public Web Server محل مناسبی برای آرشیو Backup نیست.

Access Control واقعی اعمال کنید

اگر Directory باید قابل مشاهده باشد اما فقط برای کاربران خاص:

Authentication
+
Authorization

باید اعمال شود.

Least Privilege را روی File Permission رعایت کنید

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

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

.htaccess می‌تواند در برخی Hostingها مفید باشد، اما بهتر است امنیت تا حد امکان در Server Configuration اصلی اعمال شود.

Apache نیز درباره کنترل دقیق AllowOverride توصیه‌های امنیتی دارد و مشخص می‌کند چه Directiveهایی از طریق .htaccess قابل Override هستند.

در سروری که Administrator کنترل کامل دارد، تنظیمات مرکزی قابل مدیریت‌تر و قابل Auditتر هستند.

اگر Directory Listing عمداً لازم باشد چه کنیم؟

گاهی Listing بخشی از سرویس است.

مثلاً Mirror عمومی یک پروژه.

در این حالت بهتر است Directory کاملاً از Application حساس جدا باشد.

مثلاً:

downloads.example.com

فقط شامل Artifactهای عمومی باشد.

نه اینکه همان Directory شامل:

public release
+
backup
+
logs
+
internal builds

باشد.

فقط فایل عمومی قرار دهید

هر چیزی که در Directory Listed قرار می‌گیرد باید Public فرض شود.

Directory را جدا کنید

از همان Storage محل داده خصوصی استفاده نکنید.

Upload مستقیم محدود باشد

اگر User یا Service می‌تواند فایل اضافه کند، Validation و Access Control لازم است.

فایل‌های اجرایی را کنترل کنید

یک Public File Repository نباید ناخواسته به محل اجرای Script تبدیل شود.

Headerهای امنیتی Directory Listing را حل می‌کنند؟

خیر.

Headerهایی مانند:

Content-Security-Policy
X-Content-Type-Options
Referrer-Policy

برای مشکلات دیگری مفید هستند.

اما اگر سرور خودِ فهرست Directory را نمایش دهد، Security Header مشکل اصلی را حل نمی‌کند.

راه‌حل باید Configuration و Access Control باشد.

WAF می‌تواند Directory Listing را متوقف کند؟

WAF ممکن است برخی Requestها را محدود کند، اما نباید راهکار اصلی باشد.

اگر Server Configuration اجازه Listing می‌دهد، Root Cause همچنان وجود دارد.

WAF ممکن است:

• Bypass شود.
• Rule مناسبی نداشته باشد.
• مسیر جدید را پوشش ندهد.
• درخواست عادی Directory را مخرب تشخیص ندهد.

Hardening باید ابتدا در Origin Server انجام شود.

Monitoring برای Directory Listing

Logهای Web Server می‌توانند برای تشخیص رفتار غیرعادی مفید باشند.

برای مثال Requestهای متعدد به Directoryهایی مانند:

/backup/
/old/
/logs/
/uploads/

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

اما Monitoring جایگزین Prevention نیست.

هدف:

Prevent
+
Detect
+
Respond

است.

اگر Directory Listing مدت زیادی فعال بوده چه کنیم؟

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

محتوای Directory را بررسی کنید

چه Fileهایی قابل مشاهده بوده‌اند؟

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

آیا فقط نام آن‌ها نمایش داده شده یا Download نیز ممکن بوده است؟

Logها را بررسی کنید

آیا درخواست‌هایی برای Fileهای حساس وجود داشته است؟

Credentialهای موجود را ارزیابی کنید

اگر Backup یا Configuration دارای Password و Token بوده است، آن Credential ممکن است نیازمند Rotation باشد.

فایل‌ها را جابه‌جا کنید

Resource حساس را خارج از Public Root قرار دهید.

Root Cause را پیدا کنید

آیا مشکل ناشی از:

Options +Indexes
autoindex on
IIS Directory Browsing
Deployment mistake
Volume mount
Missing index

بوده است؟

رفع Root Cause مانع تکرار Incident می‌شود.

Directory Listing و Incident Response

فرض کنید Directory زیر افشا شده باشد:

/backups/

و فهرست شامل:

site.zip
db.sql
config-backup.php

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

1. جلوگیری فوری از دسترسی
2. بررسی Fileهای موجود
3. بررسی Logها
4. تعیین بازه زمانی Exposure
5. شناسایی Credentialهای احتمالی
6. Rotation در صورت نیاز
7. انتقال Backupها
8. اصلاح Web Server Configuration
9. تست مجدد
10. مستندسازی Incident

حذف صفحه Index به‌تنهایی Incident Response کامل نیست.

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

فقط ساختن index.html

این کار Directory Indexing را واقعاً خاموش نمی‌کند.

مخفی‌کردن لینک Directory

نبودن لینک در سایت Access Control نیست.

اعتماد به robots.txt

Crawler Policy امنیت ایجاد نمی‌کند.

استفاده از نام تصادفی برای Directory

مثلاً:

/backup-x7A29/

نام غیرقابل حدس فقط Obscurity است.

قرار دادن Backup داخل public_html

حتی با Listing خاموش نیز خطر باقی می‌ماند.

غیرفعال کردن Listing ولی باز گذاشتن فایل‌ها

این یکی از مهم‌ترین اشتباهات است.

فعال‌کردن Listing روی Root سایت

اگر نیاز فقط برای یک Directory است، نباید روی Scope بزرگ فعال شود.

اعتماد به WAF

WAF جایگزین Hardening نیست.

استفاده از Permission بسیار باز

File Permission نامناسب می‌تواند مشکلات دیگری ایجاد کند.

فراموش کردن Environmentهای Staging

گاهی Production امن است اما:

staging.example.com
dev.example.com
test.example.com

Directory Listing دارند.

Staging نیز می‌تواند اطلاعات Production-like داشته باشد.

چک‌لیست امنیت Directory Listing

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

• آیا Directory Listing در Production غیرفعال است؟
• آیا Apache دارای Options +Indexes ناخواسته نیست؟
• آیا در Nginx autoindex on غیرضروری وجود ندارد؟
• آیا Directory Browsing در IIS فقط در صورت نیاز فعال است؟
• آیا Document Root فقط شامل فایل‌های عمومی است؟
• آیا .env خارج از Public Root است؟
• آیا Backupها خارج از Public Root هستند؟
• آیا Database Dump روی Web Server عمومی نگهداری نمی‌شود؟
• آیا Logها از HTTP قابل دسترسی نیستند؟
• آیا Repository Metadata مانند .git محافظت شده است؟
• آیا فایل‌های Private کاربران Authorization دارند؟
• آیا Directoryهای Upload قابل Listing نیستند؟
• آیا Staging و Development بررسی شده‌اند؟
• آیا Docker Volumeها Directory اضافی را Public نکرده‌اند؟
• آیا Configurationهای Container بررسی شده‌اند؟
• آیا Shared Hosting و .htaccess بررسی شده‌اند؟
• آیا Search Engine نباید به داده حساس دسترسی داشته باشد؟
• آیا robots.txt به‌عنوان Security Control استفاده نشده است؟
• آیا URL مستقیم فایل‌های حساس مسدود است؟
• آیا Backupهای قدیمی حذف شده‌اند؟
• آیا Permissionها براساس Least Privilege هستند؟
• آیا Log درخواست‌های مشکوک بررسی می‌شود؟
• آیا تغییرات Server Configuration در Code Review قرار می‌گیرند؟
• آیا تست Security بعد از Deployment اجرا می‌شود؟
• آیا برای Exposure احتمالی Incident Response تعریف شده است؟

معماری پیشنهادی برای فایل‌های عمومی و خصوصی

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

فایل‌های عمومی

/public/
    css/
    js/
    images/
    public-downloads/

فایل‌های خصوصی

/private-storage/
    invoices/
    documents/
    backups/
    logs/

دسترسی به Private File باید از Application عبور کند:

User
  ↓
Authentication
  ↓
Authorization
  ↓
Application
  ↓
Private Storage

نه:

User
  ↓
Direct URL
  ↓
Private Directory

چرا معماری بهتر از پنهان‌سازی است؟

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

مثلاً:

/secret-backup-3927/

در نگاه اول دشوار برای حدس‌زدن است.

اما ممکن است نام Directory از طریق:

• Log
• Source Code
• Error
• Referer
• Backup
• Search Index
• Directory Listing دیگری

آشکار شود.

Access Control نباید به محرمانه‌بودن URL وابسته باشد.

Directory Listing و اصل Defense in Depth

راهکار حرفه‌ای چندلایه است:

Directory Listing Disabled
        +
Minimal Public Web Root
        +
Access Control
        +
Secure File Permissions
        +
No Backups in Web Root
        +
Monitoring
        +
Security Testing

اگر یک لایه دچار اشتباه شود، لایه دیگر می‌تواند خطر را کاهش دهد.

Directory Listing در Secure Development Lifecycle

این ضعف را می‌توان قبل از Production نیز کنترل کرد.

Design

مشخص کنید Public و Private Storage کجا هستند.

Development

فایل حساس را داخل Web Root ذخیره نکنید.

Deployment

Autoindex و Directory Browsing را بررسی کنید.

Testing

مسیرهای شناخته‌شده را Negative Test کنید.

Monitoring

Requestهای غیرعادی را بررسی کنید.

Maintenance

Backup و Fileهای قدیمی را حذف کنید.

این رویکرد بهتر از آن است که Directory Listing فقط هنگام Pentest کشف شود.

نقش Configuration as Code

در زیرساخت‌های مدرن بهتر است تنظیمات Nginx، Apache، IIS یا Reverse Proxy تا حد امکان Version Controlled و قابل Review باشند.

برای مثال تغییر زیر:

autoindex off;

به:

autoindex on;

باید در Code Review قابل مشاهده باشد.

مزیت Configuration as Code این است که تغییرات امنیتی قابل Audit می‌شوند.

البته Repository Configuration نباید Secretهای واقعی داشته باشد.

تست Regression برای Directory Listing

پس از رفع مشکل بهتر است Testی وجود داشته باشد که در Deploymentهای آینده آن را دوباره بررسی کند.

برای مثال Test می‌تواند انتظار داشته باشد Request به:

/uploads/

فهرست Fileها را برنگرداند.

این موضوع به‌خصوص زمانی مهم است که Infrastructure چند بار در سال Rebuild می‌شود.

Directory Listing و Zero Trust

اصل Zero Trust درباره File Access نیز کاربرد دارد.

وجود یک Resource روی Server نباید به این معنی باشد که Client اجازه مشاهده آن را دارد.

هر Resource باید براساس نیاز واقعی Exposure داشته باشد.

برای Fileهای حساس:

وجود روی Server
≠
اجازه انتشار روی Web

این جداسازی یکی از اصول پایه Secure Architecture است.

سؤالات متداول درباره Directory Listing

Directory Listing چیست؟

Directory Listing قابلیتی در Web Server است که در صورت درخواست یک Directory، فهرست فایل‌ها و پوشه‌های آن را به Client نمایش می‌دهد. این قابلیت معمولاً زمانی دیده می‌شود که Index File وجود ندارد و Directory Browsing فعال است.

آیا Directory Listing آسیب‌پذیری امنیتی است؟

اگر Directory فقط فایل‌های عمومی موردنظر را نمایش دهد، الزاماً آسیب‌پذیری نیست. اما اگر بدون نیاز فعال شده و اطلاعات داخلی یا فایل‌های حساس را آشکار کند، یک ضعف Information Disclosure محسوب می‌شود.

CWE مربوط به Directory Listing چیست؟

این ضعف در MITRE با شناسه CWE-548: Exposure of Information Through Directory Listing شناخته می‌شود.

Directory Listing چه اطلاعاتی نشان می‌دهد؟

بسته به Web Server ممکن است نام Fileها، Subdirectoryها، حجم، تاریخ تغییر و پسوند فایل‌ها نمایش داده شوند.

آیا Directory Listing به معنی هک‌شدن سایت است؟

خیر. فعال بودن Listing به‌خودی‌خود به معنی Compromise نیست، اما می‌تواند اطلاعاتی را در اختیار افراد غیرمجاز قرار دهد و در برخی شرایط به کشف فایل‌های حساس کمک کند.

چگونه Directory Listing را در Apache خاموش کنیم؟

در Configuration مناسب معمولاً از:

Options -Indexes

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

چگونه Directory Listing را در Nginx خاموش کنیم؟

Directive اصلی:

autoindex off;

است و طبق مستندات Nginx مقدار پیش‌فرض آن نیز off است.

Directory Browsing در IIS به‌صورت پیش‌فرض فعال است؟

طبق مستندات مایکروسافت، مقدار پیش‌فرض Directory Browsing در IIS غیرفعال است.

آیا قرار دادن index.html مشکل را حل می‌کند؟

فقط ممکن است Listing را در همان شرایط مخفی کند. بهتر است Directory Indexing در سطح Server غیرفعال شود و فایل‌های حساس نیز مستقل محافظت شوند.

آیا Directory Listing با Path Traversal یکسان است؟

خیر. Directory Listing فهرست محتوای Directory را نمایش می‌دهد، درحالی‌که Path Traversal معمولاً شامل دسترسی به مسیرهایی خارج از محدوده مجاز از طریق دستکاری Path است.

آیا Directory Listing با IDOR یکسان است؟

خیر. IDOR یا BOLA مشکل Authorization روی Object است، اما Directory Listing معمولاً ناشی از Configuration و Exposure نامناسب File System Resources است.

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

خیر. کنترل اصلی باید در Web Server، Storage Architecture و Access Control انجام شود.

آیا Directory Listing در wp-content/uploads خطرناک است؟

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

آیا robots.txt می‌تواند Directory را امن کند؟

خیر. robots.txt Access Control نیست و فقط به Crawlerهای سازگار پیشنهاد می‌دهد چه مسیرهایی را Index نکنند.

آیا File Permission به‌تنهایی Listing را متوقف می‌کند؟

نه لزوماً. اگر Web Server اجازه Read Directory را داشته باشد و Listing فعال باشد، ممکن است آن را نمایش دهد. Permission باید همراه با Web Server Configuration و معماری صحیح استفاده شود.

اگر Directory Listing قبلاً فعال بوده چه کنیم؟

آن را غیرفعال کنید، فایل‌های موجود را بررسی کنید، Logها را تحلیل کنید، فایل‌های حساس را جابه‌جا کنید و اگر Credential یا اطلاعات محرمانه قابل دسترسی بوده‌اند Incident Response مناسب انجام دهید.

آیا Directory Listing در سرور دانلود عمومی قابل قبول است؟

بله، اگر هدف سرویس دقیقاً نمایش فایل‌های عمومی باشد و هیچ Data خصوصی یا Internal در آن Directory وجود نداشته باشد. بهتر است چنین سرویس‌هایی از Application اصلی جدا شوند.

جمع‌بندی

Directory Listing قابلیتی است که می‌تواند فهرست فایل‌ها و زیرپوشه‌های یک Directory را مستقیماً به کاربر نمایش دهد. این قابلیت در شرایطی مانند Public Download Server می‌تواند کاملاً عمدی و قابل قبول باشد، اما در یک وب‌اپلیکیشن معمولی اغلب نیازی به فعال‌بودن آن وجود ندارد.

خطر اصلی Directory Listing این نیست که خود صفحه Index عملیات مخربی انجام می‌دهد؛ مشکل این است که اطلاعاتی را آشکار می‌کند که در حالت عادی Client نیازی به دانستن آن‌ها ندارد.

نام Backupها، Database Dumpها، Logها، فایل‌های قدیمی، Directoryهای داخلی، User Uploadها، Source Archiveها و Configuration Fileها می‌توانند اطلاعات ارزشمندی درباره ساختار سیستم ارائه دهند و در صورت دسترسی مستقیم، حتی محرمانگی داده‌ها را به خطر بیندازند.

برای جلوگیری از آسیب‌پذیری Directory Listing باید Autoindex یا Directory Browsing در مسیرهای غیرضروری غیرفعال باشد، Document Root تا حد ممکن کوچک نگه داشته شود و هیچ فایل حساس، Backup یا Log در Public Web Root ذخیره نشود.

در Apache می‌توان گزینه Indexes را غیرفعال کرد، در Nginx باید autoindex خاموش باشد و در IIS نیز Directory Browsing فقط در مسیرهایی فعال شود که نیاز مشخصی به آن دارند.

بااین‌حال خاموش‌کردن Listing تنها بخشی از دفاع است. یک File حساس حتی بدون Listing ممکن است با URL مستقیم قابل دسترسی باشد. بنابراین Access Control، File Permission، Private Storage، Secure Deployment، Monitoring و تست دوره‌ای باید در کنار آن قرار گیرند.

در نهایت، رویکرد امن این است که هر چیزی داخل Public Web Root را بالقوه عمومی در نظر بگیریم و فقط فایل‌هایی را در این بخش قرار دهیم که واقعاً باید از طریق HTTP در دسترس باشند. Directory Listing زمانی کم‌خطر می‌شود که معماری فایل‌ها، مجوزها و Server Configuration از ابتدا بر پایه اصل Least Privilege و Defense in Depth طراحی شده باشند.