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

Scope
   ↓
Recon
   ↓
Enumeration
   ↓
HTTP Analysis
   ↓
Burp Suite
   ↓
Input Mapping

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

Authentication و Session

وقتی یک کاربر وارد حساب خودش می‌شود، برنامه از کجا می‌فهمد که درخواست‌های بعدی متعلق به همان کاربر هستند؟

پشت یک Login ساده، معمولاً یک زنجیره کامل وجود دارد:

Credentials
    ↓
Authentication
    ↓
Session / Token
    ↓
Authenticated Request
    ↓
Authorization
    ↓
Resource

هدف این قسمت این است که این زنجیره را دقیق بشناسیم.

۱. Authentication چیست؟

Authentication یعنی:

اثبات هویت کاربر

مثلاً:

Email + Password
        ↓
Authentication
        ↓
User Identity

برنامه بررسی می‌کند که اطلاعات ارائه‌شده معتبر هستند یا خیر.

اگر معتبر باشند، کاربر وارد حساب می‌شود.

۲. Authorization چیست؟

Authorization مرحله دیگری است.

بعد از اینکه برنامه فهمید:

«این کاربر چه کسی است؟»

باید تصمیم بگیرد:

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

مثلاً:

Authentication
      ↓
Who are you?

Authorization
      ↓
What can you access?

این دو مفهوم را همیشه جدا نگه دار.

۳. Login در پشت صحنه

فرض کنیم کاربر فرم Login را پر می‌کند:

Email:
user@example.test

Password:
********

Browser یک Request ارسال می‌کند.

مثلاً:

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

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

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

سپس فرآیند Authentication انجام می‌شود.

۴. بعد از Login چه اتفاقی می‌افتد؟

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

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

Session Cookie

یا:

Token

مدل کلی:

Login
  ↓
Authentication Success
  ↓
Session / Token
  ↓
Future Requests

۵. Session چیست؟

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

مثلاً:

User
 ↓
Login
 ↓
Server creates Session
 ↓
Session Identifier
 ↓
Browser

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

۶. Cookie چیست؟

یکی از روش‌های رایج انتقال Session Identifier استفاده از Cookie است.

مثلاً:

Set-Cookie: session=example

Browser آن را ذخیره می‌کند.

بعد ممکن است در Request بعدی ارسال شود:

Cookie: session=example

مدل ساده:

Server
  │
  │ Set-Cookie
  ▼
Browser
  │
  │ Cookie
  ▼
Server

۷. Cookie را از Session اشتباه نگیر

این دو یکی نیستند.

Cookie
=
داده‌ای که Browser نگهداری و ارسال می‌کند

Session
=
مکانیزم نگهداری وضعیت احراز هویت

در بعضی معماری‌ها Cookie می‌تواند Session Identifier را حمل کند.

پس:

Cookie ≠ Session

اما ممکن است به هم مرتبط باشند.

۸. ویژگی‌های مهم Cookie

در بررسی امنیتی Cookie، چند Attribute اهمیت زیادی دارند.

Secure

اگر Cookie دارای:

Secure

باشد، مرورگر آن را برای ارتباط‌های HTTP معمولی ارسال نمی‌کند و ارسال آن به HTTPS محدود می‌شود.

HttpOnly

اگر:

HttpOnly

فعال باشد، دسترسی مستقیم JavaScript به Cookie محدود می‌شود.

این ویژگی می‌تواند در کاهش برخی ریسک‌های سرقت Cookie در سناریوهای خاص مؤثر باشد.

SameSite

این Attribute به کنترل نحوه ارسال Cookie در Contextهای Cross-Site کمک می‌کند.

مقادیر رایج:

Strict
Lax
None

رفتار دقیق آن‌ها را باید با Context برنامه بررسی کرد.

۹. چرا Session Security مهم است؟

فرض کن یک Session Identifier داریم:

session=ABC123

این مقدار می‌تواند برای شناسایی Session کاربر استفاده شود.

بنابراین سؤال‌های امنیتی مهمی مطرح می‌شود:

آیا Session تصادفی و غیرقابل پیش‌بینی است؟

آیا Session از طریق HTTPS منتقل می‌شود؟

آیا Cookie تنظیمات امنیتی مناسبی دارد؟

Session چه زمانی منقضی می‌شود؟

بعد از Logout چه اتفاقی می‌افتد؟

آیا Session پس از تغییر سطح دسترسی تغییر می‌کند؟

این‌ها سؤال‌های اصلی یک Session Review هستند.

۱۰. Session Lifecycle

یک Session فقط هنگام Login ایجاد نمی‌شود.

باید کل چرخه آن را بررسی کنیم:

Login
  ↓
Session Creation
  ↓
Authenticated Requests
  ↓
Session Refresh / Rotation
  ↓
Logout
  ↓
Session Invalidation

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

۱۱. Session Rotation

یکی از مفاهیم مهم:

Session Rotation

است.

در برخی سناریوهای امنیتی، بعد از یک تغییر مهم در وضعیت Authentication، برنامه می‌تواند Session Identifier را تغییر دهد.

مثلاً:

Before Login
Session = A

       ↓ Login

After Login
Session = B

این مفهوم در طراحی امن Session اهمیت دارد.

۱۲. Logout واقعاً چه کاری باید انجام دهد؟

وقتی کاربر Logout می‌کند، انتظار داریم Session دیگر معتبر نباشد.

مدل ذهنی:

Authenticated
     ↓
Logout
     ↓
Session Invalidated
     ↓
Authenticated Request
     ↓
Access Denied

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

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

۱۳. تمرین اول — مشاهده Login Request

Juice Shop را اجرا کن و Burp را فعال نگه دار.

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

در HTTP History، Request مربوط به Login را پیدا کن.

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

Method:
Endpoint:
Content-Type:
Parameters:
Request Body:
Status Code:
Response Type:

۱۴. تمرین دوم — بررسی Response

حالا Response مربوط به Login را مشاهده کن.

بررسی کن:

Status Code
Response Headers
Set-Cookie
Token
JSON Body
Redirect

اگر Token یا Cookie وجود نداشت، چیزی را حدس نزن.

فقط آنچه واقعاً مشاهده می‌کنی ثبت کن.

۱۵. تمرین سوم — Request بعد از Login

بعد از ورود، یک صفحه دیگر از برنامه را باز کن.

در HTTP History یک Request جدید پیدا کن.

حالا مقایسه کن:

Before Login
      ↓
Request

After Login
      ↓
Request

چه چیزی تغییر کرده؟

مثلاً ممکن است:

Cookie
Authorization Header
Session State

اضافه شده باشد.

۱۶. Authorization Header

در برخی برنامه‌ها Authentication با Cookie انجام نمی‌شود و Token در Header ارسال می‌شود.

مثلاً:

Authorization: Bearer <token>

در این حالت مدل ارتباط می‌تواند شبیه این باشد:

Login
  ↓
Token
  ↓
Browser
  ↓
Authorization Header
  ↓
API

این معماری را با Session Cookie اشتباه نکن.

هر Application معماری Authentication خودش را دارد.

۱۷. Session Review Checklist

برای بررسی Session یک چک‌لیست داشته باش:

[ ] Session Creation
[ ] Session Identifier
[ ] Cookie Attributes
[ ] HTTPS Usage
[ ] Session Lifetime
[ ] Logout Behavior
[ ] Session Invalidation
[ ] Session Rotation
[ ] Authentication State
[ ] Authorization State

این چک‌لیست را می‌توانی در پروژه‌های آموزشی آینده هم استفاده کنی.

۱۸. Authentication ≠ Authorization

یک سناریوی مهم:

فرض کن Login کاملاً درست کار می‌کند.

کاربر:

user@example.test

احراز هویت شده است.

اما حالا درخواست می‌دهد:

GET /api/admin/users

سؤال:

آیا فقط چون کاربر Login کرده، اجازه مشاهده کاربران را دارد؟

قطعاً نه.

Server باید Authorization را بررسی کند.

Authenticated?
      ↓
YES
      ↓
Authorized?
      ↓
YES / NO

این تفاوت پایه بسیاری از مباحث Access Control است.

۱۹. Principle of Least Privilege

یک اصل مهم امنیتی:

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

مثلاً:

Normal User
   ↓
Own Profile
Own Orders
Own Data

در مقابل:

Administrator
   ↓
User Management
System Configuration
Administrative Functions

سطح دسترسی باید بر اساس Role و Policy برنامه تعیین شود.

۲۰. Role چیست؟

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

Guest
User
Moderator
Admin

اما وجود Role به‌تنهایی کافی نیست.

باید بدانیم:

Role
 ↓
Permissions
 ↓
Resources
 ↓
Actions

چه ارتباطی با هم دارند.

۲۱. یک اشتباه رایج در Pentesting

تازه‌کارها گاهی فکر می‌کنند:

«اگر Login پیدا کردم، پس Authentication تمام شد.»

در واقع Login فقط شروع بررسی است.

باید جریان کامل را بفهمی:

Credentials
 ↓
Login Request
 ↓
Authentication
 ↓
Session / Token
 ↓
Authenticated Request
 ↓
Authorization
 ↓
Resource Access
 ↓
Logout
 ↓
Session Invalidation

این زنجیره را حفظ کن.

۲۲. Recon Notebook را توسعه بده

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

================================
AUTHENTICATION MAP
================================

Login Endpoint:
...

HTTP Method:
...

Credential Inputs:
...

Authentication Response:
...

Session Mechanism:
Cookie / Token / Unknown

Cookie Name:
...

Security Attributes:
Secure:
HttpOnly:
SameSite:

Session Lifetime:
Unknown / Observed

Logout Endpoint:
...

Post-Logout Behavior:
...

Authorization Model:
...

Open Questions:
...

۲۳. تمرین نهایی قسمت ۰۷

در محیط آزمایشگاهی خودت این زنجیره را مستند کن:

1. Login
2. Authentication Response
3. Session / Token Creation
4. Authenticated Request
5. Authorization Check
6. Logout
7. Post-Logout Request

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

What happened?
What evidence do I have?
What is still unknown?

این سه سؤال باعث می‌شوند تحلیل تو بر اساس شواهد باشد، نه حدس.

چالش قسمت ۰۷

یک Authentication Flow Map بساز:

┌──────────────┐
│ Login Form   │
└──────┬───────┘
       ↓
┌──────────────┐
│ Login        │
│ Request      │
└──────┬───────┘
       ↓
┌──────────────┐
│ Server       │
│ Authentication│
└──────┬───────┘
       ↓
┌──────────────┐
│ Session /    │
│ Token        │
└──────┬───────┘
       ↓
┌──────────────┐
│ Authenticated│
│ Request      │
└──────┬───────┘
       ↓
┌──────────────┐
│ Authorization│
└──────┬───────┘
       ↓
    Resource

سپس برای هر مرحله بنویس:

چه چیزی می‌دانم؟

چه چیزی نمی‌دانم؟

چه چیزی باید بررسی شود؟

جمع‌بندی

در این قسمت یاد گرفتیم:

Authentication
      ↓
Identity
      ↓
Session / Token
      ↓
Authenticated Request
      ↓
Authorization
      ↓
Resource

و فهمیدیم که امنیت Login فقط به درست یا غلط بودن Password محدود نمی‌شود.

یک Pentester باید کل چرخه را ببیند:

Login
 ↓
Session
 ↓
Request
 ↓
Authorization
 ↓
Logout

امنیت Authentication فقط به لحظه ورود مربوط نیست؛ کل چرخه هویت کاربر باید درست طراحی و کنترل شود.

قسمت بعد — ۰۸

در قسمت بعد وارد مبحث بسیار مهم Access Control می‌شویم.

بررسی می‌کنیم که برنامه چگونه تصمیم می‌گیرد:

چه کاربری → به چه Resourceی → با چه سطح دسترسی → چه عملیاتی انجام دهد.

و با مفهوم مهم:

Broken Access Control

آشنا می‌شویم؛ ابتدا در سطح مفهومی و سپس با سناریوی کاملاً آزمایشگاهی روی محیط خودمان.