HTTP را مثل یک Pentester ببین

View HTTP like a pentester
صفر و یک سایبر
0 دیدگاه
۱۴۰۵-۰۶-۲۹ ۱۲:۱۱:۵۳

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

Scope
   ↓
Recon
   ↓
Port Discovery
   ↓
Service Detection
   ↓
Enumeration

اما حالا باید یک مهارت بسیار مهم را یاد بگیریم:

وقتی یک برنامه وب با ما صحبت می‌کند، دقیقاً چه چیزی بین Browser و Server ردوبدل می‌شود؟

اگر HTTP را درست نفهمی، درک بسیاری از آسیب‌پذیری‌های وب هم ناقص خواهد بود.

پس قبل از اینکه سراغ آسیب‌پذیری‌هایی مثل SQL Injection، XSS یا ضعف‌های Authentication برویم، باید خود HTTP را بشناسیم.

۱. HTTP چیست؟

HTTP مخفف:

HyperText Transfer Protocol

است.

به زبان ساده، HTTP یکی از پروتکل‌هایی است که Browser و Web Server از طریق آن با یکدیگر ارتباط برقرار می‌کنند.

مثلاً وقتی وارد:

http://localhost:3000

می‌شوی، مرورگر یک Request ارسال می‌کند.

سرور آن را پردازش کرده و Response برمی‌گرداند.

مدل ذهنی:

┌──────────────┐
│   Browser    │
└──────┬───────┘
       │
       │ HTTP Request
       ▼
┌──────────────┐
│ Web Server   │
└──────┬───────┘
       │
       │ HTTP Response
       ▼
┌──────────────┐
│   Browser    │
└──────────────┘

همین رفت‌وبرگشت، یکی از مهم‌ترین چیزهایی است که در Web Pentesting بررسی می‌کنیم.

۲. یک Request ساده

فرض کن مرورگر می‌خواهد صفحه اصلی را دریافت کند.

یک Request ساده می‌تواند چیزی شبیه این باشد:

GET / HTTP/1.1
Host: localhost:3000
User-Agent: Browser
Accept: text/html

بیایید آن را تجزیه کنیم.

۳. HTTP Method

قسمت اول:

GET

نام Method است.

Method به سرور می‌گوید نوع عملیاتی که Client درخواست کرده چیست.

Methodهای مهم:

GET
POST
PUT
PATCH
DELETE
OPTIONS
HEAD

فعلاً چهار مورد اصلی را بشناس:

GET

معمولاً برای دریافت اطلاعات.

GET /products

POST

معمولاً برای ارسال داده.

POST /login

PUT

معمولاً برای جایگزینی یا به‌روزرسانی یک Resource.

DELETE

برای حذف یک Resource.

نکته مهم:

Method به‌تنهایی مشخص نمی‌کند عملیات امن است یا آسیب‌پذیر.

باید رفتار واقعی برنامه را بررسی کنیم.

۴. Path چیست؟

در این Request:

GET /products HTTP/1.1

این قسمت:

/products

Path است.

در یک برنامه ممکن است Pathهای مختلفی وجود داشته باشد:

/
/login
/register
/products
/search
/account
/api/products

هر Path می‌تواند منطق متفاوتی در Backend داشته باشد.

بنابراین برای Pentester:

Endpointها بخشی از Attack Surface هستند.

۵. Host

در HTTP/1.1 معمولاً Header مهمی داریم:

Host: localhost:3000

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

در محیط‌های واقعی ممکن است یک سرور چند Virtual Host داشته باشد.

بنابراین:

IP Address
   ↓
Server
   ↓
Multiple Hosts
   ↓
Different Applications

این موضوع در Recon و Enumeration اهمیت زیادی دارد.

۶. HTTP Headers

بعد از Request Line، Headerها قرار می‌گیرند.

مثلاً:

User-Agent: ...
Accept: ...
Content-Type: ...
Cookie: ...
Authorization: ...

Headerها اطلاعاتی درباره Request و نحوه پردازش آن منتقل می‌کنند.

برای Pentester، Headerها بسیار مهم هستند چون ممکن است اطلاعاتی درباره:

  • Authentication
  • Session
  • Content Type
  • Client
  • Caching
  • Security Policies

در اختیارمان قرار دهند.

۷. Request Body

همه Requestها Body ندارند.

اما مثلاً یک POST Request ممکن است داده‌ای ارسال کند:

POST /login HTTP/1.1
Host: localhost:3000
Content-Type: application/json

{
  "email": "user@example.test",
  "password": "example"
}

در اینجا اطلاعات بعد از خط خالی، Request Body است.

ساختار ذهنی:

Request
│
├── Method
├── Path
├── Headers
└── Body

این چهار بخش را خوب یاد بگیر.

در Web Pentesting دائماً با آن‌ها سروکار خواهی داشت.

۸. Response چیست؟

بعد از دریافت Request، سرور Response ارسال می‌کند.

مثلاً:

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

<html>
...
</html>

Response نیز ساختار مشخصی دارد:

Response
│
├── Status Code
├── Headers
└── Body

۹. Status Code

Status Code یکی از اولین چیزهایی است که هنگام تحلیل Response می‌بینیم.

چند مورد مهم:

200 OK
201 Created
204 No Content

301 Moved Permanently
302 Found

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found

500 Internal Server Error

اما یک نکته بسیار مهم:

Status Code به‌تنهایی وجود یا عدم وجود Vulnerability را ثابت نمی‌کند.

مثلاً:

403 Forbidden

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

ما باید بفهمیم:

چرا؟

و آیا راه دیگری برای دسترسی وجود دارد یا نه.

۱۰. Content-Type

یکی از Headerهای مهم:

Content-Type

است.

مثلاً:

Content-Type: text/html

یعنی محتوای Response از نوع HTML است.

یا:

Content-Type: application/json

یعنی داده JSON است.

در APIها معمولاً JSON زیاد مشاهده می‌کنیم:

{
  "id": 15,
  "name": "test"
}

Pentester باید بتواند نوع داده‌ای که برنامه مصرف و تولید می‌کند را تشخیص دهد.

۱۱. Cookie چیست؟

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

Session Management

فرض کن کاربر Login کرده است.

سرور باید somehow بفهمد درخواست‌های بعدی مربوط به همان کاربر هستند.

یکی از روش‌های رایج استفاده از Cookie است.

مثلاً:

Set-Cookie: session=example

مرورگر این Cookie را ذخیره می‌کند و در درخواست‌های بعدی ممکن است آن را ارسال کند:

Cookie: session=example

مدل ذهنی:

Login
  ↓
Server
  ↓
Session Created
  ↓
Cookie
  ↓
Browser
  ↓
Future Requests

۱۲. چرا Cookie برای Pentester مهم است؟

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

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

Session چگونه ساخته می‌شود؟
Session چگونه اعتبارسنجی می‌شود؟
Session چه زمانی منقضی می‌شود؟
Cookie چه ویژگی‌هایی دارد؟
آیا Session قابل پیش‌بینی است؟
آیا Session پس از Logout معتبر می‌ماند؟

فعلاً قرار نیست سراغ سوءاستفاده برویم.

ابتدا باید رفتار صحیح برنامه را بفهمیم.

۱۳. Authentication و Authorization یکی نیستند

این دو مفهوم را از همین الان جدا کن.

Authentication

یعنی:

تو چه کسی هستی؟

مثلاً Login.

Username + Password
        ↓
Authentication
        ↓
User Identity

Authorization

یعنی:

چه کاری اجازه داری انجام بدهی؟

مثلاً:

User
 ↓
View Own Profile

Admin
 ↓
Manage Users

ممکن است یک برنامه Authentication مناسبی داشته باشد اما Authorization ضعیفی داشته باشد.

این تفاوت در تست نفوذ بسیار مهم است.

۱۴. یک سناریوی ساده

فرض کن کاربر A وارد حساب خودش شده است.

درخواست:

GET /api/profile/100

سرور اطلاعات کاربر A را برمی‌گرداند.

حالا یک سؤال امنیتی:

اگر کاربر بتواند شناسه را تغییر دهد و:

GET /api/profile/101

بزند، چه اتفاقی می‌افتد؟

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

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

Request
   ↓
Authorization Check
   ↓
Is User Allowed?
   ↓
Response

اگر برنامه بدون بررسی مالکیت، اطلاعات Resource متعلق به کاربر دیگر را برگرداند، می‌تواند نشانه یک Broken Access Control باشد.

این دقیقاً نمونه‌ای از اهمیت تحلیل Request و Response است.

۱۵. Browser DevTools

حالا وارد بخش عملی شو.

Juice Shop را اجرا کن و:

http://localhost:3000

را باز کن.

سپس:

F12

را بزن.

و وارد:

Network

شو.

صفحه را Refresh کن.

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

روی یکی از Requestها کلیک کن.

معمولاً بخش‌هایی مثل این را می‌بینی:

Headers
Payload
Response
Cookies

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

۱۶. Request را قدم‌به‌قدم بخوان

یک Request را انتخاب کن و این موارد را پیدا کن:

Method:
GET / POST / ...

URL:
...

Status:
...

Request Headers:
...

Response Headers:
...

Cookies:
...

Response Body:
...

حالا تلاش کن Request را بدون نگاه کردن به ابزار توضیح بدهی.

مثلاً:

«این یک GET Request است که برای Endpoint مشخصی ارسال شده، سرور با Status Code مشخصی پاسخ داده و Response از نوع JSON است.»

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

۱۷. Payload چیست؟

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

مثلاً:

{
  "email": "user@example.test",
  "password": "example"
}

این داده‌ها ممکن است در:

  • Query Parameters
  • Form Data
  • JSON Body
  • Path Parameters

قرار بگیرند.

برای Pentester، هر ورودی یک نقطه مهم برای بررسی رفتار برنامه است.

مدل ذهنی:

User Input
    ↓
HTTP Request
    ↓
Backend
    ↓
Processing
    ↓
Database / Logic
    ↓
HTTP Response

اینجاست که بعدها وارد مبحث Input Validation می‌شویم.

۱۸. Query Parameter

مثلاً:

/search?q=phone

اینجا:

q=phone

یک Query Parameter است.

ممکن است چند پارامتر داشته باشیم:

/search?q=phone&page=2&sort=price

از نگاه Pentester، باید بدانیم:

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

فعلاً فقط مشاهده و تحلیل می‌کنیم.

۱۹. چرا Burp Suite مهم می‌شود؟

تا اینجا از Browser DevTools استفاده کردیم.

در مراحل بعدی از ابزارهای تخصصی‌تر مثل Burp Suite استفاده خواهیم کرد.

Burp می‌تواند به ما کمک کند:

Browser
   ↓
Burp Proxy
   ↓
Application

در نتیجه می‌توانیم HTTP Traffic را بهتر مشاهده و در محیط آزمایشگاهی Requestها را برای تحلیل کنترل‌شده بررسی کنیم.

اما قبل از استفاده جدی از Burp باید HTTP را خوب بفهمیم.

ابزار جای دانش را نمی‌گیرد.

۲۰. یک طرز فکر مهم

وقتی یک Request می‌بینی، به جای اینکه فقط بگویی:

«این Request چیست؟»

این سؤال‌ها را بپرس:

چه کسی این Request را ارسال کرده؟

به کجا ارسال شده؟

چه داده‌ای ارسال شده؟

سرور چه پاسخی داده؟

چه چیزی در سمت Client کنترل می‌شود؟

چه چیزی باید در سمت Server کنترل شود؟

آیا Authentication وجود دارد؟

آیا Authorization بررسی می‌شود؟

آیا داده حساس ارسال می‌شود؟

این‌ها سؤال‌های امنیتی هستند.

۲۱. تمرین عملی

در Juice Shop:

تمرین اول

DevTools را باز کن.

یک Request از نوع GET پیدا کن.

ثبت کن:

Method:
URL:
Status:
Content-Type:

تمرین دوم

یک Request از نوع POST پیدا کن.

ثبت کن:

Method:
URL:
Content-Type:
Request Body:
Status:
Response Type:

تمرین سوم

یک Request دارای Cookie پیدا کن.

بررسی کن:

Cookie Name:
Secure:
HttpOnly:
SameSite:

اگر یکی از این ویژگی‌ها در ابزار نمایش داده نشد، آن را حدس نزن؛ فقط همان چیزی را که واقعاً مشاهده می‌کنی ثبت کن.

۲۲. Recon Notebook را کامل‌تر کن

دفترچه‌ای که در قسمت قبل ساختیم را به این شکل گسترش بده:

================================
HTTP ANALYSIS
================================

Methods Observed:
GET
POST
...

Interesting Endpoints:
...

Content Types:
...

Cookies:
...

Authentication:
...

Potential Parameters:
...

Interesting Responses:
...

Open Questions:
...

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

۲۳. چالش قسمت چهارم

بدون اجرای Exploit، فقط با مشاهده Traffic، یک Request را انتخاب کن و این زنجیره را کامل کن:

Browser
   ↓
HTTP Method
   ↓
URL / Endpoint
   ↓
Parameters
   ↓
Headers
   ↓
Cookies
   ↓
Server
   ↓
Status Code
   ↓
Response

بعد جواب این سؤال را بنویس:

«اگر بخواهم امنیت این Request را بررسی کنم، دقیقاً چه چیزهایی باید بدانم؟»

پاسخ را با حداقل ۵ مورد بنویس.

جمع‌بندی

در این قسمت یاد گرفتیم که Web Application فقط چیزی نیست که در Browser می‌بینیم.

پشت هر صفحه:

Request
   ↓
Server Logic
   ↓
Response

وجود دارد.

و پشت هر Request، اطلاعاتی مثل:

Method
URL
Parameters
Headers
Cookies
Body

قرار گرفته است.

یک Pentester باید بتواند این ارتباط را بخواند.

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

HTTP
 ↓
Input
 ↓
Application Logic
 ↓
Security Control
 ↓
Potential Vulnerability

قسمت بعد

در قسمت ۰۵ وارد Burp Suite و Intercept کردن HTTP Traffic در آزمایشگاه می‌شویم و یاد می‌گیریم چگونه یک Request را متوقف، مشاهده و برای تحلیل امنیتی بررسی کنیم.

از آنجا، Web Pentesting وارد فاز بسیار عملی‌تری می‌شود.

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

مباحث تخصصی

آنچه در این مقاله میخوانید

دیدگاه شما

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

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

آخرین وبلاگ‌ها