تا اینجا در مسیر یادگیری تست نفوذ با آسیب‌پذیری‌هایی مثل SQL Injection، XSS و File Upload آشنا شدیم و یاد گرفتیم یافته‌های امنیتی را چگونه در قالب یک گزارش حرفه‌ای مستند کنیم.

اما یک سؤال مهم باقی می‌ماند:

اگر مهاجم بتواند وارد حساب کاربر شود یا Session او را تحت تأثیر قرار دهد، چه اتفاقی می‌افتد؟

اینجاست که مفهوم Authentication & Session Security اهمیت پیدا می‌کند.

در این قسمت بررسی می‌کنیم:

• Authentication چیست؟
• Session چیست؟
• Cookie چه نقشی دارد؟
• Login امن چگونه باید پیاده‌سازی شود؟
• Session چگونه ایجاد و مدیریت می‌شود؟
• مشکلات رایج احراز هویت چیست؟
• Session ID ناامن چه خطری دارد؟
• Brute Force چگونه در یک آزمایشگاه بررسی می‌شود؟
• چگونه درخواست‌های Authentication را با Burp Suite تحلیل کنیم؟
• چگونه این مشکلات را در گزارش تست نفوذ ثبت کنیم؟

⚠️ تمام تست‌های این آموزش باید فقط روی DVWA، محیط آزمایشگاهی شخصی یا سامانه‌ای که مجوز تست آن را دارید انجام شود.

1. Authentication چیست؟

Authentication یا احراز هویت فرآیندی است که سیستم با استفاده از آن تشخیص می‌دهد:

«آیا این کاربر واقعاً همان کسی است که ادعا می‌کند؟»

برای مثال وقتی وارد یک سایت می‌شویم:

Username: admin
Password: ********

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

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

فرآیند ساده:

User
 │
 ▼
Login Form
 │
 ▼
Username + Password
 │
 ▼
Server
 │
 ├── Invalid → Login Failed
 │
 └── Valid
       │
       ▼
   Create Session
       │
       ▼
   Authenticated User

2. Session چیست؟

بعد از Login، سرور باید بتواند درخواست‌های بعدی کاربر را به همان حساب مرتبط کند.

اینجا Session وارد می‌شود.

برای مثال:

Login
   ↓
Server creates Session
   ↓
Session ID
   ↓
Browser Cookie
   ↓
Future Requests

مرورگر ممکن است چیزی شبیه این دریافت کند:

Set-Cookie: PHPSESSID=abc123xyz

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

Cookie: PHPSESSID=abc123xyz

سرور با استفاده از این Session ID متوجه می‌شود که درخواست متعلق به کدام Session است.

3. تفاوت Authentication و Session

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

Authentication

پاسخ این سؤال است:

کاربر چه کسی است؟

Session

پاسخ این سؤال است:

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

مثلاً:

Username + Password
        ↓
 Authentication
        ↓
    Session ID
        ↓
   Authenticated
      Session

4. Cookie چه نقشی دارد؟

Cookie یکی از روش‌های رایج برای نگهداری Session ID در مرورگر است.

برای مشاهده Cookieها می‌توان از Developer Tools مرورگر استفاده کرد.

در Chrome:

F12
↓
Application
↓
Cookies

در یک آزمایشگاه ممکن است چیزی شبیه این ببینید:

PHPSESSID = abc123xyz
security = low

نکته مهم:

Session ID معمولاً نباید اطلاعات حساس یا قابل حدس درباره کاربر در خود داشته باشد.

مثلاً طراحی بد:

session=admin

یا:

session=user123

می‌تواند اطلاعات غیرضروری در اختیار مهاجم قرار دهد.

5. Flagهای مهم Cookie

یکی از مهم‌ترین بخش‌های Session Security، تنظیم صحیح Cookieهاست.

سه Flag بسیار مهم:

HttpOnly

این Flag باعث می‌شود JavaScript سمت مرورگر نتواند مستقیماً Cookie را بخواند.

مثال:

Set-Cookie: PHPSESSID=abc123; HttpOnly

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

Secure

باعث می‌شود Cookie فقط از طریق HTTPS ارسال شود.

Set-Cookie: PHPSESSID=abc123; Secure

در سایت‌های واقعی استفاده از HTTPS و Secure Cookie اهمیت زیادی دارد.

SameSite

برای کنترل ارسال Cookie در درخواست‌های Cross-Site استفاده می‌شود.

مثلاً:

SameSite=Lax

یا:

SameSite=Strict

یا در شرایط خاص:

SameSite=None; Secure

تنظیم صحیح SameSite می‌تواند به کاهش برخی حملات مرتبط با Cross-Site Request کمک کند.

6. ساخت آزمایشگاه

برای این قسمت می‌توانیم از همان آزمایشگاه قبلی استفاده کنیم:

┌──────────────────────┐
│      Kali Linux      │
│                      │
│ Burp Suite           │
│ Browser              │
└──────────┬───────────┘
           │
           │ HTTP
           ▼
┌──────────────────────┐
│         DVWA         │
│                      │
│ Authentication       │
│ Session Management   │
└──────────────────────┘

فرض می‌کنیم IP ماشین آزمایشگاهی:

192.168.56.20

این IP صرفاً نمونه است؛ IP محیط خودتان را جایگزین کنید.

7. بررسی ارتباط با آزمایشگاه

ابتدا اتصال را بررسی کنید:

ping 192.168.56.20

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

nmap -sV 192.168.56.20

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

8. ورود به DVWA

صفحه Login مربوط به DVWA را باز کنید.

مثلاً:

http://192.168.56.20/dvwa/

بعد از ورود، یک Session برای مرورگر ایجاد می‌شود.

حالا سؤال مهم:

این Session چگونه ایجاد شده و چگونه در درخواست‌های بعدی استفاده می‌شود؟

برای پاسخ، Burp Suite را باز می‌کنیم.

9. مشاهده درخواست Login در Burp Suite

Burp Suite را اجرا کنید و مرورگر را از طریق Proxy آزمایشگاه تنظیم کنید.

سپس Login کنید.

در Burp Suite → Proxy → HTTP history درخواست مربوط به Login را پیدا کنید.

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

POST /login.php HTTP/1.1
Host: 192.168.56.20
Content-Type: application/x-www-form-urlencoded

username=admin&password=password

این درخواست نشان می‌دهد اطلاعات Login چگونه به سرور ارسال شده‌اند.

10. بررسی پاسخ Server

حالا Response را بررسی کنید.

ممکن است سرور Headerای مانند زیر ارسال کند:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=abc123xyz

این قسمت بسیار مهم است.

سرور بعد از Authentication یک Session ایجاد کرده است.

11. بررسی Session ID

Session ID را در درخواست‌های بعدی پیدا کنید:

Cookie: PHPSESSID=abc123xyz

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

آیا Session ID ثابت باقی می‌ماند؟

آیا بعد از Logout تغییر می‌کند؟

آیا بعد از Login مجدداً تولید می‌شود؟

این‌ها دقیقاً همان سؤالاتی هستند که در یک تست امنیتی واقعی باید بررسی شوند.

12. Session Fixation چیست؟

یکی از مشکلات مهم Session Security، Session Fixation است.

ایده کلی:

Attacker
   ↓
Obtains / controls a Session ID
   ↓
Victim uses that Session
   ↓
Victim authenticates
   ↓
Session remains associated

اگر برنامه بعد از Authentication Session ID را تغییر ندهد، در شرایط خاص می‌تواند ریسک ایجاد کند.

رفتار امن

Before Login
Session A

      ↓ Login

After Login
Session B

یعنی بعد از Authentication، Session ID جدید ایجاد شود.

13. بررسی Session ID در آزمایشگاه

در Burp، قبل از Login مقدار Session را یادداشت کنید.

مثلاً:

PHPSESSID=AAA111

Login کنید.

سپس Cookie را دوباره بررسی کنید.

اگر برنامه امن طراحی شده باشد، بهتر است بعد از Authentication Session مناسب و معتبر برای کاربر ایجاد شود و Session قبلی در صورت نیاز بی‌اعتبار شود.

14. Weak Session ID چیست؟

Session ID باید:

• تصادفی باشد
• غیرقابل حدس باشد
• طول مناسب داشته باشد
• اطلاعات قابل پیش‌بینی در آن نباشد
• با الگوریتم امن تولید شود

طراحی ضعیف می‌تواند چیزی شبیه این باشد:

1001
1002
1003
1004

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

مثلاً:

9f72a1c8d4e6...

مقدار واقعی Session ID باید توسط مکانیزم امن سمت سرور تولید شود.

15. بررسی Weak Session IDs در DVWA

DVWA شامل بخشی برای بررسی Session ID است.

از منوی:

DVWA
↓
Weak Session IDs

وارد بخش مربوطه شوید.

با ایجاد چند Session، مقادیر تولیدشده را بررسی کنید.

هدف این آزمایش:

تشخیص اینکه آیا Session ID الگوی قابل پیش‌بینی دارد یا خیر.

برای مثال اگر مقادیر به شکل زیر تغییر کنند:

1
2
3
4
5

واضح است که طراحی بسیار ضعیفی وجود دارد.

اما اگر مقادیر کاملاً غیرقابل پیش‌بینی باشند، تحلیل متفاوت خواهد بود.

16. Brute Force چیست؟

یکی دیگر از مشکلات Authentication، Brute Force است.

در Brute Force مهاجم تلاش می‌کند تعداد زیادی ترکیب Username و Password را امتحان کند.

فرآیند مفهومی:

Username
   +
Password List
   ↓
Login Attempts
   ↓
Server
   ↓
Success / Failure

اما یک سیستم امن نباید اجازه دهد تعداد نامحدودی تلاش Login انجام شود.

17. تست Brute Force در آزمایشگاه

در DVWA وارد بخش:

Brute Force

شوید.

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

مثلاً بررسی کنید:

• آیا تعداد تلاش‌ها محدود شده؟
• آیا بعد از چند تلاش Account Lockout ایجاد می‌شود؟
• آیا Rate Limiting وجود دارد؟
• آیا پاسخ Login اطلاعات اضافی لو می‌دهد؟
• آیا CAPTCHA یا کنترل مشابه وجود دارد؟
• آیا IP یا رفتار غیرعادی شناسایی می‌شود؟

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

18. مشکل پیام‌های Login

فرض کنید سایت دو پیام متفاوت نمایش دهد:

Username does not exist

و:

Incorrect password

این طراحی می‌تواند به مهاجم کمک کند بفهمد کدام Username معتبر است.

به این مشکل:

Username Enumeration

گفته می‌شود.

طراحی بهتر:

Username or password is incorrect.

یعنی پاسخ عمومی و یکسان برای حالت‌های ناموفق.

19. Password Policy

امنیت Authentication فقط به Login محدود نمی‌شود.

Password Policy نیز اهمیت دارد.

یک سیستم امن باید از کاربران در برابر Passwordهای بسیار ضعیف محافظت کند.

مثلاً:

123456
password
qwerty
admin

نباید به‌راحتی به عنوان رمز عبور قابل قبول باشند.

اما فقط پیچیدگی Password کافی نیست.

مهم‌تر از آن:

• جلوگیری از Passwordهای رایج
• Rate Limiting
• MFA
• جلوگیری از Credential Stuffing
• ذخیره‌سازی امن Passwordها
• کنترل Loginهای مشکوک

است.

20. Password Storage

یک اشتباه بسیار خطرناک این است که Passwordها به صورت Plain Text ذخیره شوند.

طراحی ناامن:

Database

username | password
--------------------
admin    | 123456

طراحی صحیح باید از الگوریتم‌های Password Hashing مناسب استفاده کند.

مثلاً خانواده الگوریتم‌های:

Argon2
bcrypt
scrypt

برای ذخیره امن Passwordها استفاده می‌شوند.

نکته مهم:

رمز عبور نباید با Encryption ساده جایگزین Hashing مناسب Password شود.

21. Session Timeout

Session نباید برای همیشه معتبر باقی بماند.

برای مثال:

Login
 ↓
Session Created
 ↓
User inactive
 ↓
Session Timeout
 ↓
Login Required

در برنامه‌های حساس، Session Timeout اهمیت بیشتری پیدا می‌کند.

22. Logout واقعی چیست؟

وقتی کاربر روی Logout کلیک می‌کند، فقط حذف Cookie از مرورگر کافی نیست.

سرور نیز باید Session را بی‌اعتبار کند.

طراحی مناسب:

Logout
  ↓
Invalidate Server Session
  ↓
Clear Cookie
  ↓
Session No Longer Valid

بعد از Logout، اگر Session قبلی دوباره ارسال شود، نباید دسترسی معتبر ایجاد کند.

23. Session Cookie را با Burp بررسی کنیم

یک درخواست احراز هویت‌شده را در Burp Repeater قرار دهید.

مثلاً:

GET /dvwa/ HTTP/1.1
Host: 192.168.56.20
Cookie: PHPSESSID=abc123xyz

حالا Logout کنید.

سپس همان Request را در محیط آزمایشگاهی مجدداً بررسی کنید.

سؤال:

آیا Session قبلی هنوز معتبر است؟

اگر بعد از Logout Session قبلی همچنان دسترسی احراز هویت‌شده ایجاد کند، می‌تواند یک یافته امنیتی مهم باشد.

24. Session Hijacking چیست؟

به صورت مفهومی:

Victim
   ↓
Authenticated Session
   ↓
Session ID
   ↓
Attacker obtains Session ID
   ↓
Attacker attempts to reuse Session

اگر Session ID دزدیده شود و سرور آن را معتبر بداند، مهاجم ممکن است بتواند بدون دانستن Password از Session استفاده کند.

به همین دلیل حفاظت از Session بسیار مهم است.

25. ارتباط XSS با Session Security

در قسمت قبلی XSS را بررسی کردیم.

این دو موضوع می‌توانند با یکدیگر ارتباط داشته باشند.

به صورت مفهومی:

XSS
 ↓
Malicious JavaScript
 ↓
Session-related attack opportunity

استفاده از:

HttpOnly

می‌تواند دسترسی مستقیم JavaScript به Cookieهای HttpOnly را محدود کند.

اما:

HttpOnly به‌تنهایی تمام حملات XSS یا تمام حملات Session را حل نمی‌کند.

XSS باید در خود برنامه نیز به شکل صحیح برطرف شود.

26. Authentication Bypass چیست؟

یکی از مهم‌ترین یافته‌های تست نفوذ، Authentication Bypass است.

در حالت عادی:

No Authentication
       ↓
     Denied

و:

Valid Authentication
       ↓
     Allowed

اما اگر بتوان بدون Authentication به بخش محافظت‌شده دسترسی پیدا کرد:

No Authentication
       ↓
Protected Resource
       ↓
      Allowed

می‌تواند یک آسیب‌پذیری جدی باشد.

27. تست کنترل دسترسی

بعد از Login یک URL داخلی را مشاهده کنید.

مثلاً:

/dashboard

سپس Logout کنید.

حالا همان URL را دوباره درخواست کنید.

بررسی کنید:

Authenticated → Access Granted
Logged Out    → Access Denied

این تست ساده می‌تواند یک کنترل مهم Session را بررسی کند.

28. چک‌لیست تست Authentication

هنگام تست یک برنامه، موارد زیر را بررسی کنید:

Login

• HTTPS استفاده می‌شود؟

• پیام خطا اطلاعات اضافی افشا نمی‌کند؟

• Rate Limiting وجود دارد؟

• MFA در بخش‌های حساس وجود دارد؟

• Password Policy مناسب است؟

• Login Attemptها کنترل می‌شوند؟

Session

• Session ID تصادفی است؟

• Session ID قابل حدس نیست؟

• Cookie دارای HttpOnly است؟

• Cookie دارای Secure است؟

• SameSite مناسب تنظیم شده؟

• Session بعد از Login به شکل امن مدیریت می‌شود؟

• Logout Session را باطل می‌کند؟

• Session Timeout وجود دارد؟

Access Control

• صفحات محافظت‌شده بدون Login قابل دسترسی نیستند؟

• Session منقضی‌شده پذیرفته نمی‌شود؟

• کاربران نمی‌توانند به منابع غیرمجاز دسترسی پیدا کنند؟

29. نمونه گزارش تست نفوذ

فرض کنید در آزمایشگاه یک Session ID قابل پیش‌بینی پیدا کرده‌ایم.

Title

Weak Session ID

Severity

Medium

Description

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

Impact

در صورت وجود سایر شرایط لازم، مهاجم ممکن است بتواند Sessionهای معتبر را حدس زده یا سوءاستفاده از Session را ساده‌تر کند.

Evidence

تصاویر Burp Suite و مقادیر Session ID تولیدشده.

Root Cause

استفاده از مکانیزم ضعیف یا قابل پیش‌بینی برای تولید Session Identifier.

Remediation

استفاده از Session IDهای تصادفی و غیرقابل پیش‌بینی با استفاده از مکانیزم امن سمت سرور.

30. Severity چگونه تعیین می‌شود؟

شدت آسیب‌پذیری همیشه فقط به نام Vulnerability بستگی ندارد.

باید مواردی مثل:

Exploitability
+
Impact
+
Authentication Required
+
Privileges
+
Affected Assets

را در نظر گرفت.

برای مثال:

یافته	شدت احتمالی
Weak Password Policy	Low / Medium
Username Enumeration	Low / Medium
Weak Session ID	Medium
Session Fixation	Medium / High
Authentication Bypass	High / Critical
Account Takeover	High / Critical

شدت نهایی باید بر اساس شرایط واقعی محیط و روش ارزیابی انتخاب شود.

31. تمرین عملی قسمت ۱۱

حالا نوبت شماست. 🔥

در آزمایشگاه DVWA:

مرحله ۱

Login کنید و Session Cookie را پیدا کنید.

مرحله ۲

در Burp Suite درخواست‌های بعد از Login را مشاهده کنید.

مرحله ۳

Session ID را در چند درخواست بررسی کنید.

مرحله ۴

رفتار Session قبل و بعد از Logout را بررسی کنید.

مرحله ۵

بخش Weak Session IDs را بررسی کنید.

مرحله ۶

بخش Brute Force را در حد محدود و فقط داخل آزمایشگاه بررسی کنید.

مرحله ۷

پیام‌های خطای Login را تحلیل کنید.

مرحله ۸

در نهایت یافته‌های خود را در قالب یک گزارش ثبت کنید.

32. ساختار گزارش تمرین

برای هر Finding این موارد را بنویسید:

Finding:
Severity:
Affected Component:
Description:
Evidence:
Steps to Reproduce:
Impact:
Root Cause:
Remediation:
Retest:
Status:

مثلاً:

Finding:
Weak Session ID

Severity:
Medium

Affected Component:
Session Management

Description:
Session identifiers generated by the laboratory application
show predictable behavior.

Impact:
Predictable session identifiers may weaken session security.

Remediation:
Use cryptographically secure random session identifiers.

33. چگونه Session Security را امن کنیم؟

یک طراحی مناسب Authentication & Session Management باید شامل مواردی مثل این باشد:

HTTPS
  +
Secure Authentication
  +
Strong Password Hashing
  +
Rate Limiting
  +
MFA
  +
Secure Session IDs
  +
HttpOnly
  +
Secure
  +
SameSite
  +
Session Rotation
  +
Session Timeout
  +
Logout Invalidation

امنیت Authentication یک ویژگی منفرد نیست؛ مجموعه‌ای از کنترل‌هاست.

34. جمع‌بندی

در این قسمت با یکی از مهم‌ترین بخش‌های امنیت برنامه‌های وب آشنا شدیم:

Authentication & Session Security

یاد گرفتیم:

🔐 Authentication چیست
🍪 Cookie چه نقشی دارد
🆔 Session ID چگونه کار می‌کند
🛡️ HttpOnly، Secure و SameSite چیستند
⚠️ Weak Session ID چیست
🔄 Session Fixation چیست
🔓 Authentication Bypass چیست
🚪 Logout چگونه باید Session را باطل کند
⏱️ Session Timeout چرا مهم است
🧪 چگونه Authentication را با Burp Suite تحلیل کنیم
📋 چگونه یافته‌های Authentication را گزارش کنیم

و مهم‌تر از همه:

امنیت یک Login فقط به Username و Password محدود نمی‌شود؛ امنیت واقعی از لحظه ورود کاربر شروع می‌شود و تا پایان Session ادامه دارد.