نویسنده: SINISTER | رضا فروزان
برند: صفر و یک سایبر
سطح: متوسط تا پیشرفته
حوزه: Web Application Security
محیط تمرین: آزمایشگاه محلی و مجاز
ابزارها: Burp Suite، DevTools، Nmap، curl

۱. مقدمه؛ همیشه مشکل از کد نیست

وقتی درباره امنیت یک برنامه وب صحبت می‌کنیم، معمولاً ذهنمان به سمت آسیب‌پذیری‌هایی مانند:

• SQL Injection
• XSS
• SSRF
• Broken Access Control

می‌رود.

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

اینجا با مفهوم:

Security Misconfiguration

مواجه می‌شویم.

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

۲. Security Misconfiguration یعنی چه؟

فرض کن یک برنامه در محیط Development قرار دارد.

در این محیط ممکن است:

• Debug فعال باشد.
• خطاهای کامل نمایش داده شوند.
• اطلاعات داخلی در Response وجود داشته باشد.
• Directory Listing فعال باشد.
• سرویس‌های غیرضروری اجرا شوند.
• Headerهای امنیتی تنظیم نشده باشند.
• فایل‌های آزمایشی روی سرور باقی مانده باشند.

اگر همین تنظیمات بدون بررسی وارد Production شوند، سطح حمله افزایش پیدا می‌کند.

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

«برنامه چه باگی دارد؟»

گاهی سؤال مهم‌تر این است:

«برنامه چگونه پیکربندی شده است؟»

۳. چهار لایه‌ای که باید بررسی کنیم

برای تحلیل حرفه‌ای، Misconfiguration را فقط در وب‌سایت جست‌وجو نکن.

چهار لایه را بررسی کن:

Application
     ↓
Web Server
     ↓
Operating System
     ↓
Network / Infrastructure

هر لایه می‌تواند تنظیمات ناامن داشته باشد.

۴. لایه اول؛ Application Configuration

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

• Debug Mode
• Verbose Error Messages
• Development Endpoints
• Test Routes
• Default Configuration
• افشای اطلاعات داخلی
• مدیریت نادرست Secretها
• تنظیمات CORS
• Session Configuration

مثال

برنامه‌ای در محیط Production با خطای داخلی مواجه می‌شود و به جای یک پیام عمومی:

Something went wrong.

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

Database connection failed
Internal module: ...
Stack trace: ...
Application path: ...

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

خطا باید برای کاربر مفید باشد، نه برای مهاجم بیش از حد گویا.

۵. Debug Mode؛ دوست توسعه‌دهنده، دشمن Production

Debug برای توسعه‌دهنده بسیار مفید است.

اما در محیط Production می‌تواند اطلاعاتی مانند:

• Stack Trace
• مسیر فایل‌ها
• نام Moduleها
• تنظیمات داخلی
• Queryهای داخلی
• جزئیات Framework

را افشا کند.

بنابراین یکی از اولین سؤال‌های Pentester:

آیا محیط Production واقعاً با تنظیمات Production اجرا می‌شود؟

۶. HTTP Security Headers

یکی از قسمت‌های مهم Security Configuration، Headerهای HTTP است.

برای مشاهده Response Headers می‌توانی از Burp Suite یا DevTools استفاده کنی.

نمونه Headerهای مهم:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

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

Content-Security-Policy

می‌تواند منابع و رفتارهای قابل اجرای صفحه را محدود کند و در کاهش اثر برخی حملات مانند XSS نقش دفاعی داشته باشد.

Strict-Transport-Security

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

X-Content-Type-Options

به جلوگیری از برخی رفتارهای MIME sniffing کمک می‌کند.

Referrer-Policy

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

Permissions-Policy

دسترسی برخی قابلیت‌های مرورگر را محدود می‌کند.

نکته مهم: وجود یک Header به‌تنهایی به معنی پیکربندی امن نیست. مقدار و Context آن نیز باید بررسی شود.

۷. CORS؛ یک تنظیم کوچک با اثر بزرگ

CORS یا Cross-Origin Resource Sharing تعیین می‌کند مرورگر تحت چه شرایطی اجازه دسترسی یک Origin به منابع Origin دیگر را بدهد.

در بررسی CORS به مواردی مانند این‌ها توجه کن:

Origin
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Methods
Access-Control-Allow-Headers

یک اشتباه رایج این است که تصور کنیم:

CORS = Authentication

در حالی که چنین نیست.

CORS مکانیزم کنترل مرورگر است و جایگزین Authorization در سمت سرور نمی‌شود.

۸. Directory Listing

فرض کن سرور به جای ارائه یک صفحه یا خطای مناسب، فهرست فایل‌های یک مسیر را نمایش دهد:

/uploads/

├── image1.png
├── backup.zip
├── test.txt
└── old-config.json

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

Pentester باید بپرسد:

• آیا این مسیر باید عمومی باشد؟
• آیا فایل‌های حساس در آن قرار دارند؟
• آیا Listing لازم است؟
• آیا دسترسی به فایل‌ها کنترل شده است؟

۹. فایل‌های اضافی و Backupها

گاهی یک برنامه اصلی امن است، اما فایل‌های اضافی روی سرور باقی مانده‌اند.

برای مثال:

backup/
old/
test/
dev/
tmp/

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

config.old
database.backup
test.php
debug.log

وجود این فایل‌ها به‌تنهایی آسیب‌پذیری را ثابت نمی‌کند.

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

اصل مهم: هر چیزی که روی Web Server قرار دارد، باید عمداً آنجا باشد.

۱۰. سرویس‌های غیرضروری

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

مثلاً:

HTTP
HTTPS
SSH
Database
Admin Service
Development Service

وجود Port باز به‌تنهایی آسیب‌پذیری نیست.

سؤال Pentester این است:

آیا این سرویس باید در دسترس باشد؟

اگر پاسخ منفی است، بهترین راهکار معمولاً حذف یا محدود کردن آن سرویس است.

۱۱. آزمایشگاه عملی امن؛ Zero Config Lab

در این سناریو فقط روی سیستم خودت کار می‌کنیم.

معماری:

┌─────────────┐
│   Browser   │
└──────┬──────┘
       │
       ▼
┌──────────────────┐
│ Local Web Server │
│   127.0.0.1      │
└──────────────────┘

هدف:

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

۱۲. مرحله اول؛ بررسی Response Headers

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

سپس:

curl -I http://127.0.0.1:8000/

یا درخواست را از طریق Burp Suite مشاهده کن.

Headerهای Response را ثبت کن.

برای مثال:

HTTP/1.1 200 OK
Content-Type: text/html
Server: ...

حالا بررسی کن:

• آیا HTTPS در محیط Production اجباری است؟
• آیا Headerهای امنیتی موردنیاز وجود دارند؟
• آیا اطلاعات غیرضروری درباره Server افشا می‌شود؟
• آیا Cookieها تنظیمات مناسب دارند؟

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

۱۳. مرحله دوم؛ بررسی Error Handling

یک مسیر ناموجود را درخواست کن:

http://127.0.0.1:8000/does-not-exist

Response را بررسی کن.

سؤال:

آیا فقط چنین چیزی دریافت می‌کنی؟

404 Not Found

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

مثلاً:

Stack Trace
File Path
Framework Version
Internal Module

اگر اطلاعات اضافی مشاهده شد، آن را مستند کن.

هدف این آزمایش، مشاهده و گزارش است؛ نه تلاش برای استخراج اطلاعات بیشتر.

۱۴. مرحله سوم؛ بررسی فایل‌های عمومی

در محیط آزمایشگاهی، مسیرهای عمومی برنامه را بررسی کن.

مثلاً اگر خودت پوشه‌ای مانند:

/uploads/

ساخته‌ای، بررسی کن:

• آیا Directory Listing فعال است؟
• چه فایل‌هایی قابل مشاهده‌اند؟
• آیا فایل آزمایشی حساس وجود دارد؟
• آیا دسترسی باید عمومی باشد؟

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

۱۵. مرحله چهارم؛ بررسی سرویس‌های شبکه

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

برای مثال در Linux:

ss -lntup

هدف این دستور در این تمرین، شناخت سطح سرویس‌های سیستم خودت است.

یک جدول بساز:

Port	Service	موردنیاز؟	دسترسی مورد انتظار
8000	Web App	بله	Local
9000	Test Service	بله	Local
…	…	…	…

سپس سرویس‌هایی را که واقعاً موردنیاز نیستند مشخص کن.

۱۶. مرحله پنجم؛ بررسی تنظیمات Cookie

در قسمت‌های قبلی با Session آشنا شدیم.

اکنون Response را از نظر Cookie بررسی کن:

Set-Cookie: session=...

به Attributeهایی مانند:

Secure
HttpOnly
SameSite

توجه کن.

اما مانند همیشه، نتیجه را با Context بسنج.

برای مثال، نبود Secure در یک محیط کاملاً محلی HTTP الزاماً همان اثر امنیتی Production را ندارد.

Pentester باید محیط آزمایش را از محیط واقعی جدا کند.

۱۷. مرحله ششم؛ بررسی CORS در آزمایشگاه

اگر برنامه API دارد، یک درخواست آزمایشی با Header زیر مشاهده یا ارسال کن:

Origin: https://example.test

سپس Response را بررسی کن.

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

Access-Control-Allow-Origin
Access-Control-Allow-Credentials

سؤال مهم:

آیا Originهای غیرمجاز می‌توانند به داده‌ای دسترسی پیدا کنند که باید محدود باشد؟

در تحلیل CORS، فقط Header را نبین؛ رفتار واقعی مرورگر و حساس بودن داده را نیز در نظر بگیر.

۱۸. چالش اصلی قسمت سیزدهم

یک Security Configuration Audit برای آزمایشگاه محلی خودت انجام بده.

حداقل این موارد را بررسی کن:

Application

• Debug

• Error Handling

• Development Endpoints

• Test Files

Web Server

• Security Headers

• Directory Listing

• Server Information

• HTTP/HTTPS Configuration

Network

• Open Ports

• Unnecessary Services

• Service Exposure

Session

• Secure

• HttpOnly

• SameSite

API

• CORS

• Error Responses

• Unnecessary Endpoints

۱۹. جدول گزارش Pentest

نتایج را در چنین قالبی ثبت کن:

مورد	وضعیت	شدت احتمالی	شواهد
Debug Mode	فعال/غیرفعال	Low/Medium/High	Response
Security Headers	بررسی شد	…	Headers
Directory Listing	فعال/غیرفعال	…	Browser
اطلاعات Server	افشا/محافظت‌شده	…	HTTP Response
سرویس اضافی	وجود/عدم وجود	…	ss
Cookie Flags	مناسب/نیازمند بررسی	…	Set-Cookie
CORS	امن/نیازمند بررسی	…	Response

نکته حرفه‌ای: شدت را فقط بر اساس وجود یک تنظیم نادرست تعیین نکن. تأثیر واقعی، قابلیت سوءاستفاده و حساسیت دارایی را نیز در نظر بگیر.

۲۰. چگونه Security Misconfiguration را کاهش دهیم؟

اصل اول: Secure by Default

تنظیمات پیش‌فرض باید تا حد امکان امن باشند.

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

هر سرویس فقط به منابع موردنیاز دسترسی داشته باشد.

اصل سوم: حذف سرویس‌های غیرضروری

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

اصل چهارم: Production ≠ Development

تنظیمات Development را بدون بازبینی وارد Production نکن.

اصل پنجم: Errorها را کنترل کن

کاربر نباید Stack Trace و جزئیات داخلی را دریافت کند.

اصل ششم: Configuration را Version-Control و Audit کن

تغییرات مهم Configuration باید قابل بررسی و ردیابی باشند.

اصل هفتم: Secretها را از کد جدا کن

کلیدها، Tokenها و Credentialها نباید در Repository یا فایل‌های عمومی قرار بگیرند.

اصل هشتم: Monitoring

تغییرات غیرمنتظره در Configuration و رفتار سرویس‌ها باید قابل شناسایی باشند.

۲۱. طرز فکر Pentester

یک متخصص امنیت فقط نمی‌پرسد:

«آیا این برنامه آسیب‌پذیری دارد؟»

بلکه می‌پرسد:

«آیا این برنامه با تنظیمات مورد انتظار سازمان اجرا می‌شود؟»

و مهم‌تر:

«اگر یک تنظیم اشتباه باشد، اثر آن روی زنجیره امنیتی چیست؟»

ممکن است یک Header ناقص به‌تنهایی ریسک کوچکی داشته باشد، اما وقتی در کنار Debug فعال، Errorهای افشاگر، سرویس اضافی و دسترسی بیش از حد قرار گیرد، تصویر کاملاً متفاوتی ایجاد می‌شود.

جمع‌بندی

Security Misconfiguration یادآوری می‌کند که امنیت فقط در Source Code اتفاق نمی‌افتد.

امنیت واقعی حاصل ترکیب:

Secure Code
     +
Secure Configuration
     +
Secure Infrastructure
     +
Secure Network
     +
Continuous Monitoring

است.

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

یادت باشد:

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

قسمت بعدی

قسمت ۱۴ — API Security

از Endpointهای مخفی تا Authentication، Authorization، Rate Limiting و خطاهای رایج در APIها؛ جایی که دیگر فقط صفحه وب را بررسی نمی‌کنیم، بلکه مستقیماً با منطق پشت آن صحبت می‌کنیم.

صفر و یک سایبر | آموزش فارسی امنیت سایبری و هک قانونمند

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