Burp Suite؛ دیدن چیزی که مرورگر نمی‌بیند

Burp Suite Seeing what the browser doesn't see
0 دیدگاه
۱۴۰۵-۰۷-۰۱ ۱۱:۱۵:۲۹

تا اینجا یاد گرفتیم:

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 برویم.

دسته بندی‌ها:

دیدگاه شما

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *