تا اینجا یاد گرفتیم:
Recon
↓
Enumeration
↓
HTTP
↓
Request / Response
حالا یک سؤال مهم داریم:
اگر بخواهیم HTTP Traffic را دقیقتر ببینیم و Requestها را برای تحلیل امنیتی بررسی کنیم، چه ابزاری استفاده کنیم؟
اینجا Burp Suite وارد داستان میشود.
۱. Burp Suite چیست؟
Burp Suite مجموعهای از ابزارهای امنیتی برای تست برنامههای وب است.
یکی از مهمترین قابلیتهای آن، قرار گرفتن بین Browser و Web Application است.
به این معماری دقت کن:
┌─────────────┐
│ Browser │
└──────┬──────┘
│
│ HTTP Traffic
▼
┌─────────────┐
│ Burp Proxy │
└──────┬──────┘
│
│ HTTP Traffic
▼
┌─────────────┐
│ Web App │
└─────────────┘
در این حالت Burp میتواند Traffic را مشاهده و در محیط آزمایشگاهی برای تحلیل کنترلشده، Requestها را بررسی کند.
۲. چرا Burp مهم است؟
مرورگر اطلاعات زیادی را برای ما نمایش میدهد، اما Burp یک دید امنیتیتر به ارتباط Client و Server میدهد.
با Burp میتوانیم Traffic را در قالبی ساختاریافتهتر بررسی کنیم:
Request
↓
Method
↓
URL
↓
Headers
↓
Cookies
↓
Parameters
↓
Body
↓
Response
در Web Pentesting، این اطلاعات بسیار مهم هستند.
۳. آزمایشگاه
هدف ما همان Juice Shop محلی است.
اگر اجرا نشده:
docker run --rm -p 3000:3000 bkimminich/juice-shop
سپس:
http://localhost:3000
را باز کن.
هیچ Target عمومی یا متعلق به شخص دیگری را برای این تمرین وارد Burp نکن.
۴. Proxy چیست؟
کلمهی Proxy را زیاد خواهی شنید.
Proxy یک واسطه بین Client و Server است.
در آزمایش ما:
Browser
↓
Proxy
↓
Juice Shop
Browser فکر میکند مستقیماً با برنامه صحبت میکند، اما Traffic از Proxy عبور میکند.
این همان چیزی است که به ما امکان مشاهده و تحلیل HTTP را میدهد.
۵. راهاندازی Burp
Burp Suite را اجرا کن.
در بخش Proxy، تنظیمات Listener را بررسی کن.
معمولاً Burp روی یک Listener محلی مانند:
127.0.0.1:8080
منتظر اتصال میماند.
این عدد را کورکورانه حفظ نکن؛ در محیط خودت مقدار Listener را بررسی کن.
۶. اتصال Browser به Burp
Browser باید طوری تنظیم شود که HTTP Traffic آن از Proxy عبور کند.
معماری نهایی:
Browser
│
│ localhost proxy
▼
Burp Suite
│
▼
localhost:3000
بعد از تنظیم Proxy، صفحه Juice Shop را باز کن.
اگر همهچیز درست باشد، Requestها را در Burp مشاهده خواهی کرد.
۷. Intercept چیست؟
یکی از قابلیتهای مهم Burp:
Intercept
است.
در حالت Intercept، Burp میتواند یک Request را قبل از ارسال آن به Server متوقف کند.
مثلاً:
Browser
│
│ Request
▼
┌─────────────┐
│ Burp │
│ │
│ INTERCEPT │
└──────┬──────┘
│
│ Forward
▼
Server
در این مرحله هنوز هیچ Exploitی اجرا نمیکنیم.
فقط میخواهیم بفهمیم:
Request دقیقاً چه شکلی است؟
۸. اولین Request
در Burp، Intercept را فعال کن.
حالا در Juice Shop یک صفحه ساده را باز کن.
ممکن است Requestی شبیه این ببینی:
GET / HTTP/1.1
Host: localhost:3000
User-Agent: ...
Accept: text/html
حالا آن را تحلیل کن.
Method
GET
Path
/
Host
localhost:3000
Headers
اطلاعات اضافی مربوط به Request.
۹. Forward یعنی چه؟
بعد از مشاهده Request، معمولاً میتوانی اجازه بدهی Request به مقصد ادامه پیدا کند.
این همان مفهوم:
Forward
است.
یعنی:
Intercept
↓
Inspect
↓
Forward
↓
Server
هدف ما در این قسمت، یادگیری همین چرخه است.
۱۰. Response را ببین
وقتی Request به Server برسد، Server پاسخ میدهد.
مدل کامل:
Browser
↓
Request
↓
Burp
↓
Server
↓
Response
↓
Burp
↓
Browser
حالا Response را بررسی کن.
به دنبال این موارد باش:
Status Code
Headers
Content-Type
Cookies
Body
مثلاً:
HTTP/1.1 200 OK
Content-Type: application/json
۱۱. HTTP History
یکی از بخشهای بسیار مهم Burp، تاریخچه HTTP Traffic است.
در این قسمت میتوانی Requestهای مشاهدهشده را بررسی کنی.
مثلاً:
GET /
GET /assets/...
GET /api/...
POST /api/...
GET /api/...
حالا چیزی که قبلاً در Browser پراکنده میدیدیم، به شکل یک مجموعه Traffic قابل تحلیل درمیآید.
۱۲. پیدا کردن Endpointها
حالا یکی از کاربردهای مهم Burp مشخص میشود.
فرض کن کاربر روی:
Products
کلیک میکند.
در HTTP History ممکن است Requestهای مرتبط با آن را ببینی.
مثلاً:
GET /api/products
حالا یک Endpoint پیدا کردهای.
آن را در Recon Notebook ثبت کن:
Endpoint:
/api/products
Method:
GET
Purpose:
Product Data
Status:
...
فعلاً فقط شناسایی و مستندسازی میکنیم.
۱۳. POST Request
حالا یک عملیات در برنامه انجام بده که دادهای به Server ارسال میکند.
مثلاً یک عملیات عادی در محیط آموزشی.
ممکن است Requestی شبیه این ببینی:
POST /api/example HTTP/1.1
Host: localhost:3000
Content-Type: application/json
{
"example": "value"
}
حالا سؤالهای ما:
چه دادهای ارسال شد؟
نوع داده چیست؟
Endpoint کجاست؟
آیا Cookie وجود دارد؟
Response چه چیزی میگوید؟
اینها پایهی تحلیل امنیتی هستند.
۱۴. Parameters
در Web Application معمولاً ورودیهای مختلفی داریم.
مثلاً:
/search?q=phone
پارامتر:
q=phone
یا در Body:
{
"search": "phone"
}
از دید Pentester:
Input
↓
Request
↓
Backend
↓
Processing
↓
Response
این مسیر را باید بشناسیم.
چرا؟
چون در مراحل بعدی میخواهیم بررسی کنیم آیا برنامه ورودیها را به شکل امن پردازش میکند یا نه.
۱۵. Repeater چیست؟
یکی از مهمترین ابزارهای Burp:
Repeater
است.
Repeater به ما اجازه میدهد یک Request را برای تحلیل مجدد به شکل کنترلشده ارسال کنیم.
مثلاً:
HTTP Request
↓
Send to Repeater
↓
Review
↓
Modify a harmless value
↓
Send
↓
Compare Response
مثلاً فرض کن Request شامل:
page=1
است.
در محیط آزمایشگاهی میتوانی مقدار آن را تغییر دهی:
page=2
و Response را مقایسه کنی.
هدف فعلاً این نیست که چیزی را Exploit کنیم.
هدف:
درک رابطه بین Input و Application Behavior
است.
۱۶. مقایسه Request و Response
یکی از مهارتهای مهم Pentester، مقایسه است.
فرض کن:
Request A
GET /api/products?page=1
Response:
200 OK
حالا:
Request B
GET /api/products?page=2
Response:
200 OK
حالا سؤال:
چه چیزی در Response تغییر کرد؟
این سؤال ساده، بعدها برای کشف رفتارهای غیرعادی بسیار مهم میشود.
۱۷. Authentication را مشاهده کنیم
در یک برنامه دارای Login، Request مربوط به Authentication اهمیت زیادی دارد.
مثلاً:
POST /api/login
ممکن است Body داشته باشد:
{
"email": "user@example.test",
"password": "example"
}
بعد Server ممکن است Session یا Token ایجاد کند.
مدل ذهنی:
Credentials
↓
Login Request
↓
Authentication
↓
Session / Token
↓
Authenticated Requests
ما در این مرحله فقط جریان را مشاهده میکنیم.
۱۸. Authorization را جدا بررسی کن
بعد از Login، یک سؤال مهم داریم:
کاربر احراز هویت شده، دقیقاً به چه منابعی دسترسی دارد؟
این همان Authorization است.
برای مثال:
Authentication
↓
Who are you?
Authorization
↓
What can you access?
در مراحل بعدی، همین بخش میتواند ما را به سمت بررسی ضعفهای Access Control ببرد.
۱۹. Scope را فراموش نکن
Burp ابزار قدرتمندی است.
اما قدرت ابزار به معنی مجاز بودن استفاده از آن روی هر Targetی نیست.
همیشه:
Authorization
↓
Scope
↓
Testing
اول باید مشخص باشد که Target در محدوده مجاز قرار دارد.
در آزمایش ما:
localhost:3000
هدف آزمایشگاهی است.
پس تمام تمرینها را روی همین محیط انجام میدهیم.
۲۰. اشتباه رایج
یک تازهکار ممکن است Burp را باز کند و بلافاصله دنبال:
Intruder
Scanner
Exploit
Payload
برود.
اما فعلاً این کار را نکن.
اول باید بتوانی یک Request را بخوانی.
اگر نتوانی بگویی:
Method چیست؟
Endpoint چیست؟
Parameter چیست؟
Cookie چیست؟
Response چیست؟
استفاده از ابزارهای پیشرفتهتر بیشتر شبیه حدسزدن خواهد بود تا Pentesting.
۲۱. تمرین عملی
در Juice Shop این کارها را انجام بده:
تمرین ۱
Burp را اجرا کن.
Browser را از Proxy عبور بده.
سپس:
http://localhost:3000
را باز کن.
تمرین ۲
یک Request را در HTTP History پیدا کن.
این موارد را ثبت کن:
Method:
URL:
Host:
Status:
Content-Type:
تمرین ۳
یک Request دارای Parameter پیدا کن.
مثلاً:
?q=...
یا یک JSON Body.
ثبت کن:
Parameter:
Location:
Value:
Response:
تمرین ۴
یک Request را به Repeater بفرست.
فقط یک مقدار بیخطر را تغییر بده.
مثلاً:
page=1
به:
page=2
سپس Responseها را مقایسه کن.
ثبت کن:
Original Request:
Modified Request:
Original Response:
Modified Response:
What changed?
۲۲. چالش قسمت پنجم
یک Endpoint از Juice Shop پیدا کن و یک کارت اطلاعاتی برای آن بساز:
================================
ENDPOINT CARD
================================
Method:
GET / POST / ...
Endpoint:
...
Parameters:
...
Authentication:
Yes / No / Unknown
Status:
...
Content-Type:
...
Interesting Headers:
...
Response:
...
Questions:
1.
2.
3.
هدف این تمرین پیدا کردن Vulnerability نیست.
هدف این است که بتوانی یک Endpoint را مثل یک Pentester مستندسازی و تحلیل کنی.
جمعبندی
در این قسمت یاد گرفتیم:
Browser
↓
Burp Proxy
↓
Request
↓
Server
↓
Response
↓
Burp
↓
Browser
و با مفاهیم مهمی مثل:
- Proxy
- Intercept
- HTTP History
- Repeater
- Request
- Response
- Parameters
- Authentication
- Authorization
آشنا شدیم.
اما مهمترین چیزی که باید با خودت ببری این است:
Burp Suite آسیبپذیری را بهجای تو پیدا نمیکند؛ به تو کمک میکند رفتار برنامه را دقیقتر ببینی.
از اینجا به بعد، دیگر فقط یک سایت را مشاهده نمیکنیم.
ترافیکش را میخوانیم.
و وقتی ترافیک را بفهمیم، میتوانیم وارد مرحله بعد شویم:
قسمت ۰۶ — Input و Attack Surface
ورودیهای برنامه کجا هستند و چرا هر Input یک نقطه مهم امنیتی است؟
در قسمت بعد، از Requestهای معمولی عبور میکنیم و یاد میگیریم تمام نقاط ورودی یک Web Application را پیدا و دستهبندی کنیم؛ بدون اینکه هنوز سراغ Exploit برویم.

دیدگاه شما