Information Disclosure چیست؟ چگونه نشت اطلاعات امنیت سایت را تهدید می‌کند؟

Information Disclosure یا «افشای اطلاعات» زمانی رخ می‌دهد که یک وب‌سایت، نرم‌افزار یا زیرساخت اطلاعاتی را در اختیار فردی قرار دهد که مجاز به مشاهده آن نیست. این اطلاعات ممکن است مستقیماً حساس باشند؛ مانند اطلاعات شخصی کاربران، Tokenها، کلیدهای API یا فایل‌های پیکربندی. گاهی نیز اطلاعات افشاشده به‌تنهایی محرمانه به نظر نمی‌رسند، اما اطلاعاتی مانند مسیرهای داخلی سرور، نسخه نرم‌افزارها، ساختار API، Stack Trace، نام دیتابیس یا آدرس سرویس‌های داخلی می‌توانند برای شناسایی سطح حمله و طراحی حملات بعدی استفاده شوند.

جلوگیری از Information Disclosure نیازمند یک کنترل واحد نیست. مدیریت صحیح Errorها، غیرفعال کردن Debug Mode در Production، محدود کردن API Responseها، محافظت از Backup و Logها، جلوگیری از Directory Listing، حذف Secretها از Frontend، کنترل دسترسی، استفاده از Least Privilege و بررسی مستمر فایل‌ها و تنظیمات منتشرشده از مهم‌ترین اقداماتی هستند که خطر نشت اطلاعات را کاهش می‌دهند.

Information Disclosure چیست؟

Information Disclosure اصطلاحی عمومی در امنیت سایبری است که برای توصیف افشای اطلاعات به یک Actor غیرمجاز استفاده می‌شود.

MITRE در CWE-200 این مفهوم را با عنوان «Exposure of Sensitive Information to an Unauthorized Actor» تعریف می‌کند؛ یعنی محصول اطلاعات حساسی را در اختیار فرد یا سیستمی قرار می‌دهد که صراحتاً مجوز دریافت آن اطلاعات را ندارد. MITRE همچنین تأکید می‌کند که شدت این مشکل کاملاً به نوع اطلاعات، محیط Application و ارزشی که اطلاعات افشاشده برای مهاجم ایجاد می‌کنند وابسته است.

ممکن است عبارت Information Disclosure شما را فقط به یاد افشای رمز عبور یا اطلاعات بانکی بیندازد، اما دامنه آن بسیار گسترده‌تر است.

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

• اطلاعات شخصی کاربران
• آدرس ایمیل و شماره تلفن
• داده‌های مالی
• Tokenها و Credentialها
• Session Identifierها
• کلیدهای API
• اطلاعات پیکربندی
• Source Code
• Stack Trace
• مسیر کامل فایل‌های سرور
• نسخه سیستم‌عامل
• نسخه Web Server یا Framework
• Internal IP Address
• ساختار شبکه داخلی
• نام Database و Tableها
• فایل‌های Backup
• Logها
• اطلاعات Metadata
• مسیر Endpointهای مدیریتی
• Featureهای مخفی یا آزمایشی
• داده‌های Business داخلی

بنابراین Information Disclosure الزاماً به معنی انتشار عمومی یک Database کامل نیست.

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

آیا Information Disclosure همیشه یک آسیب‌پذیری مستقل است؟

خیر.

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

Information Disclosure گاهی Root Cause است و گاهی فقط Impact یا پیامد یک ضعف دیگر.

برای مثال اگر Application یک Password را مستقیماً در Response نمایش دهد، خود مدیریت نادرست اطلاعات بخش اصلی مشکل است.

اما اگر مهاجم به دلیل Path Traversal بتواند فایل Configuration را بخواند و Password موجود در آن افشا شود، Root Cause اصلی Path Traversal است و Information Disclosure پیامد آن است.

MITRE به همین دلیل هشدار می‌دهد که CWE-200 یک Class نسبتاً کلی است و استفاده از آن برای نگاشت تمام Vulnerabilityهایی که نهایتاً باعث Loss of Confidentiality می‌شوند مناسب نیست. برای Vulnerabilityهای واقعی بهتر است در صورت امکان CWE دقیق‌تر مربوط به Root Cause انتخاب شود.

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

بهتر است به‌جای نوشتن:

Vulnerability: Information Disclosure

مشخص شود:

Root Cause:
Improper Error Handling

Impact:
Disclosure of internal file paths and framework details

یا:

Root Cause:
Broken Access Control

Impact:
Disclosure of another user's personal information

این نوع گزارش به Developer کمک می‌کند مشکل واقعی را اصلاح کند.

چه اطلاعاتی از نظر امنیتی حساس محسوب می‌شود؟

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

یک داده ممکن است برای یک وب‌سایت عمومی باشد اما برای Application دیگری کاملاً محرمانه محسوب شود.

MITRE چند دسته مهم از اطلاعات حساس را مطرح می‌کند:

اطلاعات خصوصی و شخصی، وضعیت سیستم و Environment، اسرار تجاری و مالکیت فکری، وضعیت و پیکربندی شبکه، Code یا Internal State محصول و حتی Metadataهایی مانند Headerها و Connection Information.

بنابراین هنگام Threat Modeling باید سؤال شود:

«اگر یک User غیرمجاز این اطلاعات را ببیند چه چیزی درباره سیستم یاد می‌گیرد؟»

مثلاً یک Internal IP مانند:

10.10.4.17

ممکن است به‌تنهایی Credential نباشد.

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

یک Backend Service وجود دارد،

ساختار Network چگونه است،

Application به چه Subnetی متصل است،

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

این اطلاعات ممکن است در Attack Chain بعدی اهمیت پیدا کنند.

Information Disclosure چگونه امنیت سایت را تهدید می‌کند؟

مهم‌ترین خطر Information Disclosure این است که عدم قطعیت مهاجم را کاهش می‌دهد.

مهاجمی که هیچ اطلاعاتی درباره Application ندارد باید ابتدا فناوری‌ها، معماری، Endpointها و نقاط حساس سیستم را شناسایی کند.

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

برای مثال یک Error ممکن است بگوید:

Framework: Laravel
Database: MySQL
Internal Path: /var/www/example/app/...

Error دیگری نسخه Library را نمایش دهد.

فایل JavaScript نیز آدرس API داخلی را آشکار کند.

یک Backup قدیمی Source Code را در اختیار کاربر قرار دهد.

در چنین شرایطی مهاجم تصویری بسیار دقیق‌تر از Application به دست می‌آورد.

به همین دلیل Information Disclosure اغلب به‌عنوان Enabler یا تسهیل‌کننده حملات دیگر عمل می‌کند.

یک نشت اطلاعات کوچک چگونه به Attack Chain تبدیل می‌شود؟

فرض کنید Error Message سایت چنین اطلاعاتی نمایش دهد:

/var/www/shop/app/Controllers/PaymentController.php

این خط به مهاجم نشان می‌دهد:

سیستم احتمالاً Linux است،

ساختار Application چه شکلی دارد،

نام Component مربوط به Payment چیست،

و Code در چه Pathی قرار گرفته است.

سپس یک Response Header ممکن است Version یک Framework یا Server را نشان دهد.

یک فایل JavaScript نیز Endpoint زیر را افشا کند:

/api/internal/payment/status

اگر Endpoint مذکور Access Control ضعیفی داشته باشد، اطلاعاتی که در ابتدا کم‌اهمیت به نظر می‌رسیدند به ساخت یک Attack Chain کمک می‌کنند.

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

تفاوت Information Disclosure با Data Breach چیست؟

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

Information Disclosure یک مفهوم فنی گسترده است.

Data Breach معمولاً به Incident واقعی اشاره دارد که در آن داده‌های محافظت‌شده توسط فرد یا نهاد غیرمجاز مشاهده، استخراج یا منتشر شده‌اند.

برای مثال:

نمایش Full Path در Error Page یک Information Disclosure است.

افشای Database مشتریان یک Data Breach محسوب می‌شود.

ممکن است یک Information Disclosure کوچک زمینه وقوع Data Breach بزرگ‌تری را فراهم کند.

بنابراین هر Disclosure مساوی Breach نیست، ولی نباید Disclosureهای کوچک را بدون بررسی Context نادیده گرفت.

تفاوت Information Disclosure با Sensitive Data Exposure چیست؟

عبارت Sensitive Data Exposure در نسخه‌های قدیمی‌تر OWASP بسیار رایج بود.

در نسخه‌های جدید OWASP تمرکز بیشتر روی Root Causeها قرار گرفته است.

برای مثال Cryptographic Failures می‌تواند باعث افشای داده Sensitive شود و Security Misconfiguration نیز می‌تواند Errorها یا Storage عمومی ایجاد کند.

در OWASP Top 10:2025، دسته‌های A01 Broken Access Control، A02 Security Misconfiguration، A04 Cryptographic Failures و A10 Mishandling of Exceptional Conditions همگی بسته به شرایط می‌توانند به Information Disclosure منجر شوند.

بنابراین Information Disclosure را بهتر است یک نتیجه یا خانواده‌ای از Exposureها بدانیم که Root Causeهای متعددی می‌توانند ایجادش کنند.

Error Messageها؛ یکی از رایج‌ترین منابع نشت اطلاعات

یکی از شناخته‌شده‌ترین نمونه‌های Information Disclosure نمایش Errorهای فنی به کاربر است.

Application در محیط Development ممکن است برای Debug کردن اطلاعات بسیار مفیدی نمایش دهد:

Stack Trace،

نام Classها،

Database Error،

SQL Query،

Internal Path،

Variableها،

Request Data،

Library Version،

Configuration.

وجود این اطلاعات برای Developer مفید است.

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

OWASP Web Security Testing Guide توضیح می‌دهد که Error Handling نامناسب می‌تواند اطلاعاتی درباره APIهای داخلی، Frameworkها، Serviceهای متصل، Application Version و معماری سیستم در اختیار مهاجم قرار دهد.

Stack Trace چه چیزی افشا می‌کند؟

یک Stack Trace ممکن است ساختاری شبیه این داشته باشد:

Controller
  ↓
Service
  ↓
Repository
  ↓
Database Driver

حتی اگر هیچ Passwordی در آن نباشد، مهاجم می‌تواند:

نام Classها را ببیند،

Framework را تشخیص دهد،

ساختار Layerهای Application را بفهمد،

Path فایل‌ها را مشاهده کند،

و برخی Libraryها را شناسایی کند.

به همین دلیل Production باید Error عمومی برای User و Log جزئی برای تیم فنی داشته باشد.

مثلاً کاربر ببیند:

خطایی در پردازش درخواست رخ داد.

در حالی که جزئیات Technical Error در Log امن ذخیره شوند.

نشت Full Path چه خطری دارد؟

Full Path Disclosure زمانی رخ می‌دهد که مسیر واقعی فایل روی Server نمایش داده شود.

مانند:

/var/www/example/public/index.php

یا:

/home/example/domains/example.com/public_html/...

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

برای مثال در آسیب‌پذیری‌هایی مانند:

Path Traversal،

LFI،

File Upload،

Template Injection،

یا برخی File Operationها،

دانستن مسیر واقعی File System می‌تواند فرایند Exploitation را ساده‌تر کند.

Severity باید براساس Context تعیین شود.

Full Path Disclosure به‌تنهایی معمولاً با افشای Password قابل مقایسه نیست، اما در یک Attack Chain ممکن است اهمیت پیدا کند.

Debug Mode در Production

Debug Mode باید برای Development استفاده شود، نه به‌عنوان حالت عادی Production.

در بسیاری از Frameworkها Debug Mode اطلاعات بسیار بیشتری از Error معمولی نمایش می‌دهد.

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

Environment Variableها،

Request Parameterها،

SQL Error،

Stack Trace،

Installed Package،

Internal Configuration،

Template Context

باشد.

به همین دلیل یکی از اولین بررسی‌های امنیتی Production باید اطمینان از غیرفعال بودن Debug Output عمومی باشد.

Information Disclosure در وردپرس

WordPress نیز مانند هر Application دیگری ممکن است از طریق Debugging، Pluginها، Themeها، Backupها یا Misconfiguration اطلاعات افشا کند.

خود WordPress ابزارهای Debugging قدرتمندی دارد، اما Documentation رسمی تأکید می‌کند این قابلیت‌ها برای Development طراحی شده‌اند.

WP_DEBUG

WordPress از Constant زیر برای کنترل Debug استفاده می‌کند:

WP_DEBUG

Documentation رسمی WordPress توصیه می‌کند Debugging در محیط Development استفاده شود. هنگام فعال بودن WP_DEBUG، Noticeها و Errorهای PHP و پیام‌های داخلی بیشتری ممکن است تولید شوند.

در Production باید بررسی شود آیا واقعاً نیازی به Debug Mode وجود دارد یا خیر.

WP_DEBUG_DISPLAY

تنظیم WP_DEBUG_DISPLAY مشخص می‌کند Errorهای Debug در Output صفحه نمایش داده شوند یا خیر.

WordPress Site Health نیز هشدار می‌دهد که فعال بودن Debug Information ممکن است باعث افشای اطلاعات به بازدیدکنندگان سایت یا ذخیره اطلاعات در فایل Log قابل دسترس عمومی شود.

بنابراین داشتن Log داخلی برای تیم فنی یک موضوع است و نمایش آن Log به کاربران اینترنت موضوعی کاملاً متفاوت.

display_errors در PHP

WordPress Developer Resources صراحتاً توصیه می‌کند PHP display_errors در Production یا Live Site فعال نباشد، زیرا Errorهای نمایش‌داده‌شده ممکن است اطلاعاتی با پیامد امنیتی در اختیار کاربر قرار دهند.

هدف این نیست که Errorها مخفی شوند و Developer آنها را نبیند.

هدف این است:

Error Details → Secure Log
Generic Error → User

نه:

Internal Error Details → Public Browser

API Responseهای بیش از حد بزرگ

یکی از منابع بسیار مهم Information Disclosure در Applicationهای مدرن، APIها هستند.

فرض کنید Frontend فقط به این اطلاعات نیاز دارد:

{
  "id": 25,
  "name": "Ali"
}

اما Backend تمام User Object را Serialize می‌کند:

{
  "id": 25,
  "name": "Ali",
  "email": "...",
  "phone": "...",
  "internal_role": "...",
  "last_ip": "...",
  "password_reset_state": "...",
  "internal_notes": "..."
}

ممکن است UI فقط id و name را نمایش دهد، اما همه Fieldها در Network Response به Browser رسیده‌اند.

پنهان کردن Field با CSS یا JavaScript امنیت ایجاد نمی‌کند.

هر داده‌ای که به Client ارسال شده باشد باید از نظر Threat Model در اختیار Client فرض شود.

Data Minimization در API

اصل مهم:

Only return what the caller needs.

API نباید Objectهای Domain را بدون کنترل به Response تبدیل کند.

بهتر است Response DTO مشخص داشته باشیم:

Domain User Object
       ↓
Response Mapper
       ↓
PublicUserDTO
       ↓
JSON

این کار احتمال افشای Fieldهای داخلی را کاهش می‌دهد.

Broken Access Control و Information Disclosure

گاهی API فقط اطلاعات بیش از حد نمی‌دهد؛ بلکه اطلاعات Resource متعلق به فرد دیگری را برمی‌گرداند.

مثلاً:

GET /api/orders/500

اگر Server فقط ID را بررسی کند و بررسی نکند Order متعلق به User فعلی است، مشکل اصلی Broken Access Control یا IDOR/BOLA است.

Information Disclosure در اینجا Impact محسوب می‌شود.

بنابراین Remediation نباید فقط حذف چند Field باشد.

Authorization باید اصلاح شود.

JavaScript و اطلاعات حساس

هر JavaScript File که به Browser ارسال می‌شود برای User قابل مشاهده است.

Minification امنیت ایجاد نمی‌کند.

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

OWASP WSTG اشاره می‌کند که Frontend JavaScript ممکن است اطلاعاتی مانند API Key، Internal IP، Endpointهای حساس یا حتی Credentialها را در Variableها یا Bundleهای Client-Side افشا کند.

بنابراین Secret واقعی نباید داخل Frontend Bundle قرار گیرد.

چه چیزهایی نباید در JavaScript باشند؟

برای مثال:

Private API Secret،

Database Password،

Private Signing Key،

Service Credential،

Backend Administrative Token.

البته همه API Keyها الزاماً Secret نیستند.

برخی Public Client Keyها برای استفاده در Browser طراحی شده‌اند.

اما Developer باید مستندات Provider را بررسی کند و Scope، Restriction و Permission Key را محدود کند.

Source Mapها

Source Map برای Debug کردن JavaScript Minified بسیار مفید است.

ولی در Production ممکن است Source Map ساختار Source اصلی، نام فایل‌ها، Componentها، Commentها یا قسمت‌هایی از Code را بسیار راحت‌تر در اختیار تحلیلگر قرار دهد.

داشتن Source Map به‌خودی‌خود همیشه Vulnerability نیست.

اگر Application Open Source باشد، شاید اهمیتی نداشته باشد.

اما اگر Source Map حاوی Source خصوصی، Internal Route یا Comment حساس باشد، باید بررسی شود انتشار آن واقعاً لازم است یا خیر.

در Production بهتر است سیاست انتشار Source Map آگاهانه باشد، نه اتفاقی.

HTML Commentها و Metadata

Developerها معمولاً Commentهایی برای خودشان می‌نویسند:

<!-- TODO: remove old admin route -->

یا:

<!-- temporary API endpoint -->

این Commentها در Source HTML قابل مشاهده‌اند.

OWASP WSTG به‌طور مشخص توصیه می‌کند Comment و Metadata صفحات از نظر Information Leakage بررسی شوند، زیرا ممکن است اطلاعات داخلی، مسیرها یا قابلیت‌هایی را افشا کنند که نباید عمومی باشند.

Comment کد سمت Server که هرگز به Client ارسال نمی‌شود مشکل مشابهی ندارد.

مسئله Commentهایی است که بخشی از Output می‌شوند.

فایل‌های Backup؛ یک خطر جدی و رایج

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

برای مثال Developer ممکن است قبل از تغییر فایل، نسخه‌ای ایجاد کند:

config.php.bak
index.php.old
database.sql
site-backup.zip

اگر این فایل داخل Web Root باقی بماند، Web Server ممکن است آن را به‌عنوان فایل Static برای User ارسال کند.

OWASP WSTG هشدار می‌دهد که فایل‌های قدیمی و Backup ممکن است Source Code، نسخه‌های آسیب‌پذیر قبلی و حتی Archive کامل فایل‌های Web Root یا فراتر از آن را افشا کنند.

این مسئله به‌خصوص برای PHP مهم است.

فایل config.php ممکن است توسط PHP اجرا شود و Source آن نمایش داده نشود.

اما فایل:

config.php.bak

ممکن است به‌عنوان Text ساده Download شود.

نتیجه می‌تواند افشای Source Code یا Credential باشد.

فایل‌های موقت و قدیمی

فایل Backup تنها مثال نیست.

موارد زیر نیز باید بررسی شوند:

.old
.bak
.backup
.tmp
.save
.orig
~
.zip
.tar
.gz
.sql

البته Extension به‌تنهایی خطر را تعیین نمی‌کند.

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

هیچ فایل غیرضروری نباید در Production Public Directory باقی بماند.

Deployment Pipeline باید فقط فایل‌های لازم برای Runtime را منتشر کند.

Directory Listing

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

User ممکن است بتواند لیستی از:

Backupها،

Logها،

Uploadها،

Scriptها،

فایل‌های آزمایشی،

Documentها

را مشاهده کند.

OWASP Top 10:2025 در بخش Security Misconfiguration به Directory Listing به‌عنوان نمونه‌ای از Configuration ناامن اشاره می‌کند.

OWASP WSTG نیز Directory Listing را یکی از راه‌های کشف فایل‌های Unreferenced یا Backup معرفی می‌کند.

اگر Directory Listing برای Business Requirement ضروری نیست، بهتر است غیرفعال باشد.

آیا پنهان کردن Directory Listing امنیت کامل ایجاد می‌کند؟

خیر.

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

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

پس کنترل واقعی:

Access Control،

محل Storage،

Web Server Configuration،

و Deployment Hygiene

است.

Log Fileها

Logها برای امنیت ضروری هستند، اما خودشان می‌توانند اطلاعات حساس داشته باشند.

برای مثال ممکن است شامل:

URL،

IP،

User ID،

Error Detail،

Internal Path،

Request Metadata،

Transaction Identifier

باشند.

اگر Developer اشتباه کند، حتی Password یا Token نیز ممکن است در Log ثبت شود.

بنابراین Logging باید دو اصل را هم‌زمان رعایت کند:

اطلاعات کافی برای Detection و Incident Response،

عدم ثبت اطلاعاتی که ذخیره آنها ضرورت ندارد.

Logها همچنین نباید از طریق Web Root قابل Download باشند.

Session و Token در Logها

ثبت Header کامل Request یا Query String بدون فیلتر می‌تواند خطرناک باشد.

اگر URL حاوی Token باشد:

/reset-password?token=...

و Reverse Proxy URL کامل را Log کند، Reset Token در Log باقی می‌ماند.

بنابراین طراحی Application باید از ابتدا بررسی کند چه Secretهایی ممکن است وارد:

URL،

Header،

Body،

Exception،

Telemetry

شوند.

Masking و Redaction باید قبل از Storage انجام شوند.

Environment Variableها

Applicationهای مدرن معمولاً Configuration را در Environment Variable نگهداری می‌کنند.

این روش می‌تواند بهتر از Hardcode کردن Secret در Source باشد، اما Environment Variable نیز ذاتاً Public نیست.

اگر Debug Page تمام Environment را نمایش دهد یا Error Dump آن را Log کند، Secretها افشا می‌شوند.

OWASP Top 10:2025 در Security Misconfiguration، CWE-526 یعنی Exposure of Sensitive Information Through Environmental Variables را در میان ضعف‌های مرتبط فهرست می‌کند.

پس استفاده از Environment Variable جایگزین Access Control و Secret Management نیست.

Configuration Fileها

فایل Configuration معمولاً اطلاعات حساس زیادی دارد:

Database Host،

Database Username،

Secret Key،

API Credential،

Environment Setting.

این فایل‌ها باید:

Permission محدود داشته باشند،

خارج از Public Download قرار گیرند،

در Backup عمومی قرار نگیرند،

و محتوای آنها در Error یا Debug Output نمایش داده نشود.

در WordPress، حفاظت از wp-config.php و Backupهای آن بسیار مهم است.

مشکل اصلی اغلب خود فایل اصلی نیست، بلکه Copyهای قدیمی یا Archiveهایی هستند که به‌صورت Public باقی می‌مانند.

Version Disclosure

Server ممکن است Headerهایی شبیه این بفرستد:

Server: ...
X-Powered-By: ...

یا Error Page نسخه Framework را نشان دهد.

Version Disclosure به‌تنهایی همیشه Vulnerability با Severity بالا نیست.

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

همچنین «Security through Obscurity» نباید جای Update و Patch Management را بگیرد.

اما حذف Version و Banner غیرضروری می‌تواند Reconnaissance را دشوارتر کند و Information Exposure غیرضروری را کاهش دهد.

اصل درست این است:

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

Server Headerها

به همین شکل، حذف Headerهایی که فناوری Backend را بدون نیاز اعلام می‌کنند می‌تواند Hardening خوبی باشد.

ولی این اقدام باید Priority صحیح داشته باشد.

اگر Application دارای SQL Injection باشد، حذف Server Header اولویت اصلی نیست.

Risk Management باید مشکلات را براساس Impact واقعی مرتب کند.

robots.txt و Information Disclosure

robots.txt مکانیزم Access Control نیست.

این فایل به Crawler می‌گوید چه URLهایی را Crawl نکند.

اگر داخل آن بنویسید:

Disallow: /secret-admin/

در واقع نام مسیر را به هر فردی که robots.txt را می‌خواند اعلام کرده‌اید.

OWASP WSTG توضیح می‌دهد اطلاعات منتشرشده از طریق Search Engine، Sitemap و robots می‌توانند بخشی از Reconnaissance و Information Leakage باشند.

اگر یک Endpoint حساس است باید Authentication و Authorization داشته باشد.

پنهان کردن آن در robots.txt کافی نیست.

Sitemap

Sitemap نیز ماهیت Public دارد.

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

البته وجود URL مدیریت به‌تنهایی Vulnerability نیست؛ Admin Panel باید در هر صورت Access Control مناسب داشته باشد.

اما Data Minimization در Sitemap هم منطقی است.

فایل .git و Repository Metadata

یکی از Misconfigurationهای خطرناک این است که Metadata سیستم Version Control داخل Web Root منتشر شود.

در چنین شرایطی ممکن است بخش‌هایی از Repository History یا Source Code در معرض Access قرار گیرد.

Deployment باید Build Artifact لازم را منتشر کند، نه کل Working Directory Developer.

همین اصل برای سایر فایل‌های Tooling نیز صدق می‌کند.

اطلاعات حساس در Git History

حذف Secret از آخرین Commit همیشه به معنی حذف آن از Repository History نیست.

اگر Password، Token یا Private Key قبلاً Commit شده باشد، باید فرض شود Secret افشا شده است.

صرفاً حذف فایل کافی نیست.

Credential باید Rotate شود.

در صورت نیاز History نیز باید طبق Procedure سازمان پاک‌سازی شود.

Metadata فایل‌ها

Documentها نیز می‌توانند Metadata داشته باشند.

برای مثال یک فایل Office، PDF یا Image ممکن است اطلاعاتی مانند:

نام Author،

Software مورد استفاده،

زمان ایجاد،

Location Metadata،

نام Organization

داشته باشد.

همه Metadataها حساس نیستند.

اما Organizationهایی که Document عمومی منتشر می‌کنند بهتر است Metadata Policy داشته باشند.

این موضوع مخصوصاً برای Documentهایی که از محیط داخلی یا افراد مشخص تولید شده‌اند اهمیت دارد.

Exif در تصاویر

تصویر گرفته‌شده توسط بعضی Deviceها ممکن است EXIF Metadata داشته باشد.

اگر Location Information یا Device Information در آن وجود داشته باشد، انتشار مستقیم تصویر می‌تواند داده اضافی منتشر کند.

سیستم Upload و Media Processing باید براساس نوع Application تصمیم بگیرد Metadata حفظ یا حذف شود.

برای سایت عمومی، حذف Metadata غیرضروری اغلب تصمیم مناسبی است.

Cloud Storage و Information Disclosure

یکی از نمونه‌های مهم Information Disclosure در معماری Cloud، Storage عمومی ناخواسته است.

Bucket یا Object Storage ممکن است شامل:

Backup،

Export،

Invoice،

User Upload،

Log

باشد.

اگر Policy اشتباه تنظیم شود، Objectهایی که باید خصوصی باشند از اینترنت قابل دریافت می‌شوند.

OWASP Top 10:2025 در Security Misconfiguration به Cloud Storage با Sharing Permission عمومی به‌عنوان نمونه Exposure اطلاعات اشاره می‌کند.

Cloud Security نیازمند Default Deny و بررسی مداوم Permissionهاست.

CDN و Cache

Cache نیز می‌تواند باعث نشت اطلاعات شود.

فرض کنید Response مخصوص User A توسط CDN Cache شود و بعد برای User B ارسال شود.

مشکل ممکن است از:

Cache-Control اشتباه،

Cache Key ناقص،

یا Cache کردن Endpoint خصوصی

ناشی شود.

بنابراین Responseهای حساس باید Cache Policy صحیح داشته باشند.

این موضوع مخصوصاً برای:

Dashboard،

Profile،

Invoice،

Account API

اهمیت دارد.

اطلاعات حساس در URL

URLها معمولاً در مکان‌های زیادی ذخیره می‌شوند:

Browser History،

Proxy Log،

Server Log،

Analytics،

Referer.

به همین دلیل Password، Session Token یا Secret نباید در Query String قرار گیرد مگر پروتکل خاصی به‌طور دقیق برای آن طراحی شده باشد.

مثلاً:

?password=...

طراحی نامناسبی است.

حتی اگر ارتباط HTTPS باشد، URL ممکن است در Logهای داخلی ذخیره شود.

Referer و نشت اطلاعات

اگر URL صفحه حاوی داده Sensitive باشد و User از آن صفحه به Domain دیگری برود، بسته به Referrer Policy ممکن است بخشی از URL در Referer Header منتقل شود.

راهکار اصلی همچنان عدم قرار دادن Secret در URL است.

Referrer Policy یک کنترل مکمل محسوب می‌شود.

CORS و Information Disclosure

CORS Misconfiguration می‌تواند باعث شود یک Origin غیرمجاز Responseهای حساس API را از Browser User بخواند.

اما CORS را نباید Authentication تصور کرد.

CORS Policy باید دقیق و براساس Originهای موردنیاز تنظیم شود.

استفاده بی‌دلیل از Policyهای بسیار Permissive می‌تواند Exposure را افزایش دهد.

GraphQL و Overfetching

در GraphQL، Client مشخص می‌کند چه Fieldهایی نیاز دارد.

این انعطاف قدرت زیادی ایجاد می‌کند.

اما Schema باید فقط Fieldهایی را expose کند که واقعاً باید قابل دسترسی باشند.

اگر Field حساس در Schema وجود داشته باشد و Resolver Authorization کافی نداشته باشد، مخفی نکردن آن در UI مانع Query مستقیم Client نمی‌شود.

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

تفاوت اطلاعات عمومی و Secret

گاهی تیم امنیت هر اطلاعات Technical را Secret در نظر می‌گیرد.

این رویکرد نیز دقیق نیست.

برای مثال نام Framework ممکن است Public باشد و هیچ Impact جدی نداشته باشد.

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

چه اطلاعاتی افشا شده؟

چه کسی قادر به مشاهده آن است؟

آیا Authentication لازم است؟

اطلاعات چه مدت معتبر است؟

آیا قابل ترکیب با Vulnerability دیگر است؟

آیا Credential واقعی است؟

آیا داده متعلق به کاربران دیگر است؟

این سؤال‌ها Severity را تعیین می‌کنند.

چگونه Information Disclosure را به‌صورت امن شناسایی کنیم؟

در تست دفاعی نیازی نیست به دنبال استخراج حداکثری اطلاعات باشیم.

هدف شناسایی Exposure و ثبت حداقل Evidence لازم است.

بررسی Responseها

Responseهای Application را برای موارد زیر بررسی کنید:

Error،

Stack Trace،

Internal Path،

Private Field،

Internal IP،

Server Banner،

Debug Information.

بررسی Source صفحات

HTML و JavaScript باید از نظر:

Comment،

Internal Endpoint،

Secret،

Configuration،

Metadata

بررسی شوند.

OWASP WSTG نیز بررسی HTML Commentها، Metadata و JavaScript را بخشی از تست Information Leakage می‌داند.

بررسی فایل‌های منتشرشده

Deployment Artifact باید Inventory شود.

ببینید آیا فایل‌های:

Backup،

Temporary،

Old Version،

Archive،

Log،

Configuration

در Public Directory قرار دارند یا خیر.

بررسی Directoryها

Directory Listingهای غیرضروری شناسایی شوند.

OWASP WSTG نیز بررسی Directory Listing و فایل‌های قدیمی یا Unreferenced را بخشی از Configuration Testing می‌داند.

بررسی APIها

برای هر Role مشخص کنید:

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

هر Endpoint چه Fieldهایی برمی‌گرداند؟

آیا User اطلاعات Resource فرد دیگری را می‌بیند؟

آیا Admin Field برای User عادی ارسال می‌شود؟

بررسی Error Handling

Inputهای نامعتبر و حالت‌های Exception در محیط Staging بررسی شوند.

هدف Crash کردن Production نیست.

هدف این است که مطمئن شویم Error عمومی به Client و جزئیات فنی به Log امن می‌روند.

Code Review برای Information Disclosure

Code Review باید فقط دنبال عبارت password نباشد.

منابع Exposure متعددند.

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

debug output
exception handlers
logging calls
API serializers
response DTOs
template variables
configuration dumps
file download handlers
backup jobs
export functions
frontend environment variables

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

Sensitive Source
      ↓
Processing
      ↓
Storage / Response / Log
      ↓
Who can access it?

Data Classification

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

حداقل می‌توان داده‌ها را به دسته‌های زیر تقسیم کرد:

Public
Internal
Confidential
Restricted

سپس برای هر دسته مشخص شود:

کجا ذخیره شود؟

چه کسی دسترسی دارد؟

آیا Encryption لازم است؟

آیا در Log مجاز است؟

آیا در Browser مجاز است؟

چه مدت Retain شود؟

این کار Data Handling را بسیار ساده‌تر می‌کند.

اصل Data Minimization

یکی از بهترین روش‌های پیشگیری از Information Disclosure کاهش داده‌هایی است که اصلاً نگهداری یا منتقل می‌شوند.

اگر Application شماره کارت کامل نیاز ندارد، آن را ذخیره نکند.

اگر API به User ID نیاز ندارد، آن را ارسال نکند.

اگر Log به Request Body کامل نیاز ندارد، آن را ثبت نکند.

هر داده‌ای که وجود ندارد نمی‌تواند از همان نقطه نشت کند.

اصل Least Privilege

Service باید فقط به اطلاعاتی دسترسی داشته باشد که نیاز دارد.

اگر Web Frontend فقط باید Profile عمومی را بخواند، نباید Credential دسترسی کامل Database در اختیار داشته باشد.

اگر Worker فقط یک Storage مشخص را پردازش می‌کند، نباید تمام Backup Storage را Mount کند.

Least Privilege باعث می‌شود حتی در صورت Vulnerability، مقدار اطلاعات قابل افشا کاهش پیدا کند.

Segmentation

جدا کردن Componentها نیز Exposure را محدود می‌کند.

مثلاً:

Public Web Server،

Internal API،

Database،

Backup Storage،

Monitoring System

نباید همگی در یک Trust Zone بدون محدودیت باشند.

اگر Public Web App Compromise شود، دسترسی آن به سایر منابع باید حداقل باشد.

Secret Management

Credentialها نباید:

داخل Source Code،

Frontend Bundle،

Image Container،

Public Config،

یا Backup عمومی

قرار گیرند.

Secret Managerهای استاندارد، Access Policy و Rotation باید استفاده شوند.

همچنین Secret باید به Service موردنیاز داده شود، نه به تمام Applicationها.

جلوگیری از Error Disclosure

در Production باید Exception Handling مرکزی وجود داشته باشد.

ساختار پیشنهادی:

Exception
    ↓
Central Error Handler
    ↓
Detailed Secure Log
    +
Generic User Response

این معماری مزیت دیگری هم دارد:

فرمت Errorها یکنواخت می‌شود.

Developer مجبور نیست در هر Controller تصمیم جداگانه بگیرد.

Sanitization اطلاعات Error

گاهی لازم است بخشی از Error به Client برگردد.

مثلاً Validation Error:

شماره تلفن نامعتبر است.

این پیام مفید و امن است.

اما Error داخلی Database:

SQL error in table ...

برای User ضروری نیست.

Error Handling باید بین:

User-correctable error

و:

Internal system failure

تفاوت قائل شود.

Production Hardening

برای جلوگیری از Information Disclosure، Production Environment باید Hardening شود.

موارد مهم:

Debug Mode خاموش،

Directory Listing غیرضروری خاموش،

Sample Fileها حذف،

Backup از Web Root خارج،

Detailed Error خاموش،

Default Account حذف،

Permission محدود،

Unnecessary Service غیرفعال،

Storage Policy بررسی‌شده.

OWASP Top 10:2025، Security Misconfiguration را دومین دسته فهرست کرده و مواردی مانند Errorهای بیش از حد دقیق، Directory Listing و Cloud Storage Public را نمونه‌های آن معرفی می‌کند.

CI/CD چگونه به جلوگیری از نشت اطلاعات کمک می‌کند؟

Pipeline می‌تواند قبل از Deployment بررسی کند:

Secret وارد Repository نشده باشد،

Source Map غیرمجاز منتشر نشده باشد،

Backup File در Artifact نباشد،

Debug Setting Production صحیح باشد،

Configuration Test پاس شده باشد.

این کنترل‌ها احتمال Human Error را کاهش می‌دهند.

Secret Scanning

Secret Scannerها می‌توانند Patternهایی مانند API Key، Private Key یا Token را در Repository شناسایی کنند.

اما Scanner جای Process را نمی‌گیرد.

False Negative ممکن است وجود داشته باشد.

همچنین Credential کشف‌شده باید Rotate شود؛ فقط حذف String از Git کافی نیست.

SAST و Information Disclosure

SAST می‌تواند برخی مسیرهای Data Flow را شناسایی کند.

مثلاً:

password
   ↓
log()

یا:

internal config
   ↓
HTTP response

ولی بسیاری از Information Disclosureها Configuration-Based هستند و فقط با SAST قابل تشخیص نیستند.

ترکیب:

Code Review،

SAST،

DAST،

Configuration Review،

Cloud Security Review

بهتر است.

DAST

DAST می‌تواند Responseهای واقعی Application را بررسی کند.

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

Error Page،

Version Disclosure،

Directory Listing،

Backup File،

API Overexposure

قابل شناسایی‌اند.

اما Scanner ممکن است Context را نفهمد.

مثلاً یک Public User Name را به اشتباه Sensitive تلقی کند یا یک Field بسیار حساس را نشناسد.

Manual Review همچنان اهمیت دارد.

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

• اطلاعات حساس را شناسایی و طبقه‌بندی کنید؛ Debug Mode را در Production غیرفعال کنید؛ Stack Trace و Internal Error را به کاربر نمایش ندهید؛ Errorها را در Log امن و غیرعمومی ثبت کنید؛ PHP display_errors را روی Live Site غیرفعال نگه دارید؛ در WordPress وضعیت WP_DEBUG، WP_DEBUG_DISPLAY و WP_DEBUG_LOG را بررسی کنید؛ APIها فقط Fieldهای موردنیاز را برگردانند؛ Authorization هر Resource را در Server بررسی کنید؛ Domain Object را مستقیم به Response تبدیل نکنید و از Response DTO استفاده کنید؛ Secret را داخل JavaScript یا Frontend Bundle قرار ندهید؛ Source Map Production را براساس Policy مشخص مدیریت کنید؛ Comment و Metadata عمومی را بررسی کنید؛ Backup، Archive و فایل‌های قدیمی را از Web Root حذف کنید؛ Directory Listing غیرضروری را غیرفعال کنید؛ Log File را Public نکنید؛ Password، Token و اطلاعات حساس را در Log ثبت نکنید؛ Secretها را داخل URL قرار ندهید؛ Permission Cloud Storage را Default Deny تنظیم کنید؛ فایل Configuration را از Public Access محافظت کنید؛ Metadata فایل‌های عمومی را در صورت نیاز پاک‌سازی کنید؛ robots.txt را Access Control فرض نکنید؛ Version و Banner غیرضروری را کاهش دهید؛ Software را Patch و Update نگه دارید؛ Least Privilege را روی Application و Storage اعمال کنید؛ Network Segmentation اجرا کنید؛ Secret Management و Rotation داشته باشید؛ CI/CD را برای Secret و Artifact Leakage بررسی کنید؛ SAST، DAST و Configuration Review را ترکیب کنید؛ Exposureهای کشف‌شده را براساس Impact واقعی اولویت‌بندی کنید.

اشتباهات رایج در جلوگیری از Information Disclosure

تصور اینکه HTTPS همه چیز را حل می‌کند

HTTPS از Data in Transit محافظت می‌کند.

اما اگر Server خودش اطلاعات حساس را به User غیرمجاز برگرداند، TLS نمی‌تواند آن را اصلاح کند.

مثلاً:

Server → Sensitive API Response → Unauthorized User

ممکن است ارتباط کاملاً HTTPS باشد، ولی Disclosure همچنان وجود دارد.

مخفی کردن Element با CSS

اگر Data در HTML یا JSON وجود داشته باشد، display:none امنیت نیست.

User می‌تواند Source یا Network Response را مشاهده کند.

Minify کردن JavaScript

Minification باعث Secret شدن Code نمی‌شود.

Browser باید JavaScript را دریافت کند، بنابراین User نیز می‌تواند آن را دریافت کند.

حذف Server Version به‌جای Patch

Banner Hardening مفید است، اما جای Patch Management را نمی‌گیرد.

استفاده از robots.txt برای مخفی کردن Admin

robots.txt فهرست دسترسی نیست.

Authentication لازم است.

ذخیره Backup در همان Public Directory

Backup باید در Storage محافظت‌شده نگهداری شود.

اگر Backup کنار Application قرار گیرد، یک Misconfiguration کوچک می‌تواند همه داده‌ها را افشا کند.

نمایش Error فقط برای «چند دقیقه»

بسیاری از Debug Leakها با همین منطق ایجاد می‌شوند.

Developer Debug را فعال می‌کند و بعد فراموش می‌کند خاموش کند.

Production Change باید Process داشته باشد.

Logging همه چیز

«Log بیشتر همیشه بهتر است» اصل امنیتی صحیحی نیست.

Log باید اطلاعات مفید برای Detection داشته باشد، نه Secret غیرضروری.

Information Disclosure و WordPress؛ چک‌لیست عملی

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

WP_DEBUG در Live Site بدون نیاز فعال نباشد.

WP_DEBUG_DISPLAY باعث نمایش Error عمومی نشود.

PHP display_errors خاموش باشد.

Debug Log از Public Download محافظت شود.

Backupهای wp-config.php در Web Root وجود نداشته باشند.

Export Database عمومی نباشد.

Plugin و Theme آزمایشی حذف شوند.

Directoryهای Upload و Backup Permission مناسب داشته باشند.

REST APIهای Pluginها فقط Fieldهای لازم را ارائه کنند.

AJAX Actionها Capability Check داشته باشند.

Errorهای Plugin اطلاعات Database و Path را نمایش ندهند.

WordPress Site Health خود نیز Debug Mode را از نظر احتمال افشای اطلاعات بررسی می‌کند.

Information Disclosure و Pluginهای وردپرس

Plugin ممکن است Endpoint سفارشی ایجاد کند.

مثلاً:

/wp-json/plugin/v1/user

اگر Developer کل User Object را برگرداند، Fieldهای داخلی ممکن است افشا شوند.

همچنین Admin AJAX Endpoint ممکن است Capability Check ناقصی داشته باشد.

بنابراین هنگام Code Review Plugin باید بررسی شود:

چه Fieldهایی Serialize می‌شوند؟

چه Roleهایی Endpoint را فراخوانی می‌کنند؟

آیا Error خام نمایش داده می‌شود؟

آیا File Download Handler وجود دارد؟

آیا Export یا Backup قابل دریافت است؟

آیا User Enumeration نوعی Information Disclosure است؟

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

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

اما Severity باید Context-Based باشد.

در بعضی Platformها Username عمومی است.

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

بنابراین User Enumeration همیشه Severity یکسانی ندارد.

Timing Information Disclosure

Information Disclosure همیشه از متن Response نیست.

گاهی تفاوت زمان پاسخ اطلاعاتی درباره وضعیت داخلی می‌دهد.

برای مثال Application ممکن است برای User موجود پردازش متفاوتی از User ناموجود انجام دهد.

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

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

MITRE نیز اشاره می‌کند Exposure می‌تواند شامل اطلاعات غیرمستقیمی باشد که از تفاوت رفتار عملیات داخلی برای Actor خارجی قابل مشاهده هستند.

Cache Side Effects

Cache نیز ممکن است به‌صورت غیرمستقیم اطلاعات ایجاد کند.

اگر Response خصوصی یک User اشتباه Cache شود، Exposure مستقیم رخ می‌دهد.

یا تفاوت Cache Hit و Miss ممکن است در برخی معماری‌ها اطلاعاتی درباره وجود Resource ارائه دهد.

این موارد نیازمند Threat Modeling متناسب با سیستم هستند.

Information Disclosure در Errorهای Database

نمایش SQL Error بسیار رایج و خطرناک است.

Error ممکن است:

نام Database،

Table،

Column،

Query Structure،

Database Engine

را فاش کند.

حتی اگر Injection وجود نداشته باشد، این اطلاعات برای Reconnaissance مفید هستند.

در Production باید Error Database در Log داخلی بماند.

Information Disclosure در Authentication

Login Page نباید بیش از نیاز اطلاعات بدهد.

مثلاً تفاوت:

این کاربر وجود ندارد.

و:

رمز عبور اشتباه است.

ممکن است امکان Account Enumeration را ایجاد کند.

یک پیام عمومی‌تر:

نام کاربری یا رمز عبور صحیح نیست.

در بسیاری از سیستم‌ها Exposure کمتری ایجاد می‌کند.

البته Authentication Design باید User Experience و Threat Model را هم در نظر بگیرد.

Reset Password

Password Reset نیز نباید بی‌دلیل وضعیت Account را فاش کند.

مثلاً می‌توان پیام عمومی داد:

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

بدون آنکه Public Response وجود Account را تأیید کند.

ولی خود سیستم در Backend همچنان باید عملیات لازم را فقط برای Account معتبر انجام دهد.

Information Disclosure و Rate Limiting

اگر Endpoint امکان Enumeration اطلاعات را فراهم می‌کند، Rate Limiting می‌تواند سرعت جمع‌آوری داده را کاهش دهد.

اما Rate Limiting Root Cause را اصلاح نمی‌کند.

اگر User اصلاً مجاز به مشاهده داده نیست، Authorization باید آن را متوقف کند.

Rate Limit فقط لایه مکمل است.

چگونه Severity یک Information Disclosure تعیین می‌شود؟

Severity باید براساس نوع اطلاعات و شرایط دسترسی تعیین شود.

Exposure بسیار حساس

مانند:

Private Key،

Password،

Active Session Token،

Database Credential،

Personal Data گسترده.

Exposure با اهمیت متوسط

مانند:

Source Code خصوصی،

Internal API Map،

Configuration بدون Secret،

Internal Network Information.

Exposure با اهمیت پایین‌تر

در برخی Contextها:

Software Banner،

Full Path،

Framework Name.

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

بنابراین Severity ثابت وجود ندارد.

گزارش Information Disclosure حرفه‌ای

گزارش باید بگوید دقیقاً چه اطلاعاتی افشا شده است.

نه اینکه فقط بنویسد:

Sensitive information exposed.

گزارش بهتر:

Unauthenticated users can trigger an application error
that exposes the absolute filesystem path, framework
namespace, and internal database driver name.

سپس:

Endpoint،

Precondition،

Evidence حداقلی،

Impact،

Root Cause،

Remediation

مشخص شوند.

اگر Credential واقعی پیدا شده است، خود Credential کامل نباید داخل Ticket عمومی قرار گیرد.

Evidence نیز باید Redact شود.

چه زمانی Information Disclosure یک Incident است؟

اگر Exposure فقط یک Version Banner باشد شاید Incident Response گسترده لازم نباشد.

اما اگر:

Credential،

Token،

Personal Data،

Source Code حساس،

Backup،

Private Key

در دسترس بوده است، باید فرض شود احتمال Access وجود داشته.

سپس بررسی شود:

از چه زمانی Exposure وجود داشته؟

Log دریافت فایل چیست؟

چه IPهایی Access داشته‌اند؟

Search Engine آن را Index کرده؟

Cache شده؟

Credential هنوز معتبر است؟

داده متعلق به چه افرادی بوده؟

بر اساس نتیجه ممکن است Rotation، Notification و Incident Response لازم شود.

حذف فایل افشاشده کافی نیست

اگر Secret عمومی شده باشد:

Delete leaked file

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

باید:

Credential Rotate شود،

Session Token Revoked شود،

Public Cache پاک شود،

Repository History بررسی شود،

Search Cache در صورت لزوم مدیریت شود،

و Root Cause رفع شود.

اصل مهم:

Once a secret is exposed,
treat it as compromised.

Information Disclosure و E-E-A-T در محتوای امنیتی

در تحلیل Vulnerability نباید هر نشتی به‌عنوان Critical معرفی شود.

ارزیابی معتبر باید Context داشته باشد.

این موضوع برای E-E-A-T محتوای امنیتی نیز اهمیت دارد.

مثلاً:

«Server Header وجود دارد، پس سایت هک می‌شود»

ادعای علمی صحیحی نیست.

بیان دقیق‌تر:

Server Banner ممکن است اطلاعات Reconnaissance ارائه دهد، اما Severity آن به محتوای Banner، Patch Level و قابلیت ترکیب با سایر ضعف‌ها بستگی دارد.

همین دقت باید در تمام گزارش‌های Information Disclosure رعایت شود.

Defense in Depth برای جلوگیری از نشت اطلاعات

هیچ کنترل واحدی تمام Exposureها را متوقف نمی‌کند.

لایه اول:

Data Classification.

لایه دوم:

Data Minimization.

لایه سوم:

Access Control.

لایه چهارم:

Secure Error Handling.

لایه پنجم:

Production Hardening.

لایه ششم:

Secure Logging.

لایه هفتم:

Least Privilege.

لایه هشتم:

Secret Management.

لایه نهم:

Monitoring و Detection.

لایه دهم:

SAST، DAST و Configuration Review.

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

سؤالات متداول درباره Information Disclosure

Information Disclosure چیست؟

Information Disclosure به افشای اطلاعات در اختیار فرد یا Actorای گفته می‌شود که مجاز به مشاهده آن نیست. اطلاعات ممکن است شامل داده شخصی، Credential، Source Code، Configuration، مسیرهای داخلی، Metadata یا اطلاعات زیرساخت باشند. MITRE این مفهوم را در سطح کلی با CWE-200 توضیح می‌دهد.

CWE مربوط به Information Disclosure چیست؟

CWE-200 عنوان Exposure of Sensitive Information to an Unauthorized Actor دارد. با این حال MITRE توصیه می‌کند برای Vulnerability واقعی در صورت امکان CWE دقیق‌تر مربوط به Root Cause استفاده شود، زیرا CWE-200 یک Class کلی است.

آیا نمایش Stack Trace خطرناک است؟

می‌تواند باشد. Stack Trace ممکن است Internal Path، Framework، Library، Class، API و ساختار Application را افشا کند. OWASP Improper Error Handling را یکی از منابع مهم Information Leakage معرفی می‌کند.

آیا Debug Mode در Production باید فعال باشد؟

به‌طور معمول خیر. Debug Output عمومی می‌تواند Error Detail و اطلاعات داخلی سیستم را افشا کند. WordPress نیز هشدار می‌دهد Debug Information ممکن است به بازدیدکنندگان نمایش داده شود یا در فایل عمومی ثبت شود.

آیا WP_DEBUG آسیب‌پذیری است؟

خود WP_DEBUG یک قابلیت توسعه است و ذاتاً Vulnerability نیست. خطر زمانی ایجاد می‌شود که Debug Information در Production در اختیار افراد غیرمجاز قرار گیرد یا Log حاوی اطلاعات حساس Public باشد.

آیا PHP display_errors باید در سایت Live فعال باشد؟

WordPress Developer Resources و PHP Guidance توصیه می‌کنند Error Display عمومی در Production غیرفعال باشد و اطلاعات فنی از طریق Logging مناسب مدیریت شود.

آیا نمایش نسخه Web Server یک Vulnerability خطرناک است؟

معمولاً به‌تنهایی Severity بالایی ندارد، اما اطلاعات Reconnaissance ارائه می‌کند. بهتر است Bannerهای غیرضروری کاهش یابند، ولی Update و Patch Management بسیار مهم‌تر از اتکا به پنهان بودن Version هستند.

آیا Directory Listing نوعی Information Disclosure است؟

بله، در صورتی که فهرست فایل‌ها و Directoryهایی را نمایش دهد که User نباید ببیند. OWASP Security Misconfiguration و WSTG هر دو Directory Listing را از Configurationهای قابل بررسی می‌دانند.

آیا robots.txt برای مخفی کردن صفحات حساس مناسب است؟

خیر. robots.txt یک Access Control نیست و خود آن برای کاربران قابل مشاهده است. صفحات حساس باید Authentication و Authorization واقعی داشته باشند.

آیا Backup File می‌تواند باعث نشت اطلاعات شود؟

بله. OWASP هشدار می‌دهد Backup یا فایل‌های قدیمی ممکن است Source Code، نسخه‌های آسیب‌پذیر قبلی یا Archive کامل سایت را افشا کنند.

آیا Source Map خطرناک است؟

وجود Source Map همیشه Vulnerability نیست، اما ممکن است Source Code، Commentها، مسیرها یا اطلاعات داخلی را در Production آشکارتر کند. انتشار آن باید براساس نیاز و Threat Model انجام شود.

آیا JavaScript می‌تواند Secret داشته باشد؟

Secret واقعی نباید در JavaScript Browser قرار گیرد، چون Client فایل را دریافت می‌کند و می‌تواند محتوای آن را مشاهده کند. OWASP نیز Hardcoded Information در JavaScript را یکی از منابع Information Leakage معرفی می‌کند.

آیا HTTPS از Information Disclosure جلوگیری می‌کند؟

HTTPS از ارتباط در Transit محافظت می‌کند، اما اگر Application اطلاعات حساس را مستقیماً به User غیرمجاز ارسال کند، HTTPS مانع Disclosure نمی‌شود.

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

یک راهکار واحد وجود ندارد. Data Minimization، Access Control، Error Handling امن، Production Hardening، حذف Debug Output، حفاظت از Backup و Log، Least Privilege و بررسی API Responseها از مهم‌ترین کنترل‌ها هستند.

آیا WAF جلوی Information Disclosure را می‌گیرد؟

WAF ممکن است برخی Requestهای مشکوک را متوقف کند، اما بسیاری از Disclosureها ناشی از Business Logic، API Design، Permission، Debug Configuration یا فایل‌های Public هستند. بنابراین WAF فقط یک کنترل مکمل است.

آیا Information Disclosure می‌تواند به هک کامل سایت منجر شود؟

در بعضی شرایط اطلاعات افشاشده می‌توانند بخشی از یک Attack Chain باشند. برای مثال Credential افشاشده ممکن است مستقیماً دسترسی ایجاد کند یا Internal Path و Version Information به Exploitation ضعف دیگری کمک کنند. اما شدت هر مورد باید جداگانه ارزیابی شود.

جمع‌بندی

Information Disclosure یا افشای اطلاعات یکی از مفاهیم مهم امنیت وب است که از یک Error ساده تا انتشار Credential و Database کامل را می‌تواند در بر گیرد.

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

گاهی خود Application اطلاعاتی را بیش از نیاز در Response قرار می‌دهد.

گاهی Error Handling نامناسب Stack Trace و Internal Path را نشان می‌دهد.

گاهی Backup File در Web Root باقی مانده است.

گاهی Directory Listing فعال است.

گاهی API به دلیل Broken Access Control اطلاعات User دیگر را برمی‌گرداند.

گاهی JavaScript حاوی Secret است.

و گاهی Cloud Storage به دلیل Misconfiguration عمومی شده است.

به همین دلیل Information Disclosure را نباید فقط با یک Fix مانند «حذف Server Header» حل‌شده در نظر گرفت.

MITRE نیز CWE-200 را یک دسته کلی برای Exposure اطلاعات معرفی می‌کند و تأکید دارد که Root Cause دقیق باید در صورت امکان شناسایی شود.

در OWASP Top 10:2025 بسیاری از مسیرهای افشای اطلاعات در دسته‌هایی مانند Broken Access Control، Security Misconfiguration، Cryptographic Failures و Mishandling of Exceptional Conditions ریشه دارند. Security Misconfiguration به‌طور مشخص شامل نمونه‌هایی مانند Directory Listing، Errorهای دارای Stack Trace و Cloud Storage عمومی است.

بهترین دفاع از شناخت داده شروع می‌شود.

تیم توسعه باید بداند کدام اطلاعات Public، Internal، Confidential یا Restricted هستند.

سپس هر Component فقط اطلاعاتی را دریافت و ارسال کند که واقعاً برای وظیفه خود نیاز دارد.

APIها باید Response DTO محدود داشته باشند.

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

Errorهای Production باید برای User عمومی و برای تیم فنی در Log داخلی دقیق باشند.

Debug Mode نباید بدون دلیل در سایت Live فعال بماند.

Backup، Log، Configuration و Archiveها نباید در Public Web Root نگهداری شوند.

Secretها نباید وارد Frontend Bundle، Git Repository عمومی یا URL شوند.

Cloud Storage باید Default Deny باشد.

Application Process نیز باید براساس Least Privilege اجرا شود.

در WordPress باید وضعیت WP_DEBUG، WP_DEBUG_DISPLAY، PHP display_errors، فایل‌های Backup، REST API Pluginها و محل Debug Log بررسی شود. مستندات رسمی WordPress نیز نسبت به نمایش Debug Information و Errorهای PHP در Production هشدار می‌دهند.

در نهایت یک سؤال ساده می‌تواند پایه بررسی Information Disclosure باشد:

«آیا این اطلاعات واقعاً لازم است در اختیار این User، Browser، Service یا فایل عمومی قرار بگیرد؟»

اگر پاسخ منفی است، آن داده نباید به آن Trust Boundary وارد شود.