در قسمت قبل یاد گرفتیم چطور یک آزمایشگاه بسازیم، هدف را مشخص کنیم و اولین Recon را انجام دهیم.
اما یک سؤال مهم باقی میماند:
وقتی یک پورت باز پیدا کردیم، قدم بعدی چیست؟
اینجا وارد مرحلهای میشویم که به آن Enumeration میگوییم.
۱. Enumeration چیست؟
در Recon معمولاً اطلاعات کلی درباره هدف جمع میکنیم.
اما در Enumeration تلاش میکنیم اطلاعات دقیقتری از سرویسها و برنامهها به دست بیاوریم.
به زبان ساده:
Recon
↓
چه چیزی وجود دارد؟
↓
Enumeration
↓
این چیز دقیقاً چیست و چگونه کار میکند؟
مثلاً:
3000/tcp
↓
Open
↓
HTTP
↓
Web Application
↓
Technology
↓
Endpoints
↓
Functionality
هدف ما این نیست که فقط «اطلاعات بیشتری» جمع کنیم.
هدف این است که اطلاعات مرتبط و قابل استفاده برای تحلیل امنیتی به دست بیاوریم.
۲. سناریوی آزمایشگاه
هدف ما همان آزمایشگاه قسمت قبل است:
Target:
localhost
Application:
OWASP Juice Shop
Port:
3000/tcp
اگر Juice Shop اجرا نیست، ابتدا آن را اجرا کن:
docker run --rm -p 3000:3000 bkimminich/juice-shop
سپس:
http://localhost:3000
را باز کن.
۳. اولین بررسی
ابتدا وضعیت پورت را بررسی میکنیم:
nmap -p 3000 localhost
هدف این دستور بسیار ساده است:
آیا TCP/3000 در دسترس است؟
حالا Service Detection را امتحان میکنیم:
nmap -sV -p 3000 localhost
گزینه -sV تلاش میکند نوع و نسخه سرویس را شناسایی کند.
اما یک نکته حرفهای:
خروجی ابزار را «حقیقت مطلق» در نظر نگیر.
Nmap بر اساس پاسخهایی که دریافت میکند حدس و شناسایی انجام میدهد. همیشه باید نتیجه را با روشهای دیگر بررسی کنیم.
۴. بررسی HTTP
حالا مستقیماً با سرویس وب صحبت میکنیم.
curl -I http://localhost:3000
گزینه -I باعث میشود Headerهای HTTP Response را ببینیم.
ممکن است خروجی شامل مواردی شبیه این باشد:
HTTP/1.1 200 OK
Content-Type: text/html
...
عدد وضعیت HTTP بسیار مهم است.
مثلاً:
200 → درخواست با موفقیت پاسخ داده شده
301/302 → Redirect
401 → نیاز به احراز هویت
403 → دسترسی ممنوع
404 → منبع پیدا نشد
500 → خطای سمت سرور
اما به یک نکته دقت کن:
هر Status Code بهتنهایی یک آسیبپذیری نیست.
ما فقط در حال جمعآوری شواهد هستیم.
۵. Response را مثل یک Pentester بخوان
وقتی Response دریافت میکنی، فقط Status Code را نگاه نکن.
سؤالهای ما:
Status Code چیست؟
Content-Type چیست؟
Cookie ارسال شده؟
Redirect وجود دارد؟
Header امنیتی وجود دارد؟
اطلاعاتی درباره فناوری افشا شده؟
مثلاً:
Response
│
├── Status
├── Headers
├── Cookies
├── Body
└── Redirects
هر کدام میتواند یک سرنخ باشد.
۶. Cookie چیست؟
یکی از مهمترین بخشهای Web Pentesting، Session است.
برای مثال ممکن است سرور Cookieای ارسال کند:
Set-Cookie: session=...
Cookie میتواند برای نگهداری اطلاعات مربوط به Session استفاده شود.
اما اینجا نباید سریع نتیجه بگیریم:
«Cookie وجود دارد، پس آسیبپذیری داریم.»
خیر.
باید بررسی کنیم:
- Cookie چگونه تولید میشود؟
- آیا Secure است؟
- آیا HttpOnly است؟
- SameSite چگونه تنظیم شده؟
- Session چگونه مدیریت میشود؟
این موضوع در بخش Web Security بهصورت عمیقتر بررسی خواهد شد.
۷. مشاهده صفحه اصلی
حالا صفحه را در مرورگر باز کن:
http://localhost:3000
به جای اینکه فقط ظاهر سایت را ببینی، شروع به ساختن نقشه کن.
مثلاً:
Application
│
├── Home
├── Login
├── Register
├── Search
├── Products
├── Basket
└── Account
این نقشه هنوز کامل نیست.
ما باید آن را با اطلاعات بیشتری توسعه دهیم.
۸. Endpoint چیست؟
یک Endpoint را میتوان بهصورت یک نقطه قابلدسترسی در یک برنامه یا API در نظر گرفت.
برای مثال:
/api/products
/api/users
/api/login
این Endpointها میتوانند عملکردهای مختلفی ارائه کنند.
در تست نفوذ، شناخت Endpointها اهمیت زیادی دارد، چون هر Endpoint میتواند منطق، ورودی و کنترل دسترسی مخصوص خودش را داشته باشد.
۹. DevTools؛ یک منبع مهم اطلاعات
مرورگر را باز کن و:
F12
را بزن.
سپس وارد بخش:
Network
شو.
حالا صفحه را Refresh کن.
در این قسمت درخواستهایی را میبینی که مرورگر به برنامه ارسال میکند.
ساختار ذهنی ما:
Browser
↓
HTTP Request
↓
Server
↓
HTTP Response
↓
Browser
در Web Pentesting، یادگیری همین رفتوبرگشت یکی از پایهایترین مهارتهاست.
۱۰. Request را تحلیل کنیم
یک Request معمولاً اطلاعاتی شبیه این دارد:
GET / HTTP/1.1
Host: localhost:3000
User-Agent: ...
Accept: ...
Cookie: ...
فعلاً روی چند بخش تمرکز کن:
Method
مثلاً:
GET
POST
PUT
DELETE
Path
مثلاً:
/
یا:
/api/...
Headers
اطلاعات جانبی Request.
Cookies
اطلاعات مربوط به Session یا تنظیمات سمت کاربر.
۱۱. تفاوت GET و POST
دو Method بسیار مهم:
GET
معمولاً برای دریافت اطلاعات استفاده میشود.
GET /products
POST
معمولاً برای ارسال داده به سرور استفاده میشود.
POST /login
این تفاوت در تست امنیتی اهمیت زیادی دارد، چون نوع Request روی نحوه پردازش ورودیها تأثیر میگذارد.
۱۲. Enumeration یعنی ساختن تصویر
فرض کن تا اینجا این اطلاعات را داریم:
Target:
localhost
Port:
3000
Protocol:
HTTP
Application:
Web Application
Endpoints:
Multiple
Authentication:
Present
Session:
Cookie-based
API:
Present
حالا دیگر با یک «پورت 3000» مواجه نیستیم.
ما یک تصویر اولیه از برنامه داریم.
Web Application
│
┌────────────┼────────────┐
↓ ↓ ↓
Authentication Products API
│ │ │
Login Search Endpoints
Register │
↓
Basket
این دقیقاً همان چیزی است که Enumeration باید برای ما ایجاد کند.
۱۳. یک اشتباه رایج
تازهکارها معمولاً میپرسند:
«چه ابزار دیگری اجرا کنم؟»
اما سؤال حرفهای این است:
«الان چه چیزی را نمیدانم؟»
مثلاً اگر نمیدانیم:
چه سرویسهایی وجود دارند؟
از Service Detection کمک میگیریم.
اگر نمیدانیم:
چه Endpointهایی وجود دارند؟
روی ساختار برنامه و HTTP Traffic تمرکز میکنیم.
اگر نمیدانیم:
چه فناوریهایی استفاده شده؟
Technology Identification انجام میدهیم.
یعنی:
Question
↓
Technique
↓
Tool
↓
Evidence
↓
Analysis
نه اینکه:
Tool
↓
Tool
↓
Tool
↓
Tool
۱۴. ساخت Recon Notebook
حالا اطلاعاتمان را مرتب میکنیم:
================================
TARGET
================================
Host:
localhost
Port:
3000/tcp
Protocol:
HTTP
Application:
OWASP Juice Shop
================================
SERVICES
================================
3000/tcp
Web Application
================================
APPLICATION SURFACE
================================
Authentication
Products
Search
Basket
Account
API
================================
OPEN QUESTIONS
================================
Technology Stack:
[بررسی شود]
API Endpoints:
[بررسی شود]
Authentication Flow:
[بررسی شود]
Authorization:
[بررسی شود]
Session Management:
[بررسی شود]
این قسمت آخر بسیار مهم است.
Open Questions
یعنی هنوز چه چیزهایی را نمیدانیم.
۱۵. Enumeration بدون هدف چه مشکلی دارد؟
اگر بدون برنامه اطلاعات جمع کنیم، خیلی سریع با حجم زیادی از داده مواجه میشویم.
مثلاً:
1000 Endpoints
500 Parameters
200 Headers
50 Technologies
اما کدام مهم است؟
اینجاست که تحلیل اهمیت پیدا میکند.
یک Pentester باید بتواند:
Raw Data
↓
Relevant Data
↓
Security Context
↓
Potential Finding
را انجام دهد.
۱۶. تمرین عملی
در آزمایشگاه خودت این مراحل را انجام بده:
مرحله ۱
nmap -sV -p 3000 localhost
نتیجه را ثبت کن.
مرحله ۲
curl -I http://localhost:3000
Headerهای مهم را یادداشت کن.
مرحله ۳
صفحه را در مرورگر باز کن.
مرحله ۴
با F12 وارد Network شو.
مرحله ۵
صفحه را Refresh کن.
مرحله ۶
چند Request را بررسی کن.
برای هر Request این موارد را ثبت کن:
Method:
Path:
Status:
Request Headers:
Response Headers:
Cookies:
۱۷. چالش قسمت سوم
بدون اینکه هنوز سراغ Exploit بروی، برای Juice Shop یک نقشه اولیه بساز.
حداقل این موارد را پیدا و دستهبندی کن:
Authentication
User Functions
Product Functions
Search
Basket
API
Static Resources
سپس برای هرکدام بنویس:
What do I know?
What don't I know?
What should I investigate next?
این سه سؤال یکی از مهمترین عادتهای یک Pentester حرفهای هستند.
جمعبندی
تا اینجا مسیر ما:
Scope
↓
Recon
↓
Port Discovery
↓
Service Detection
↓
HTTP Analysis
↓
Application Enumeration
↓
Attack Surface Mapping
است.
اما هنوز هیچ Exploitی اجرا نکردهایم.
چون هنوز زمانش نرسیده.
ابتدا باید بفهمیم برنامه چگونه کار میکند.
هرچه Target را بهتر بشناسی، فرضیههای امنیتی دقیقتری میسازی.
قسمت بعد
در قسمت ۰۴ وارد یکی از مهمترین مباحث Web Pentesting میشویم:
HTTP را مثل یک Pentester ببین
یاد میگیریم:
Request → Response → Parameter → Cookie → Session → Authentication
و بعد کمکم به جایی میرسیم که بتوانیم یک Request واقعی را تحلیل کنیم و بفهمیم کدام بخش آن ارزش بررسی امنیتی دارد.

دیدگاه شما