Hamada Khairy — Web Security 101

// 01 — لغة الويب

HTTP Protocol — تشريح الـ Request

لما بتدوس على زرار في أي موقع، الـ Browser (الـ Client) بيبعت رسالة نصية بسيطة جداً للـ Server اسمها HTTP Request. السيرفر بيرد برسالة اسمها HTTP Response.

◆ ◇ ◆

HTTP Methods (الأفعال)

إنت عايز تعمل إيه؟

كل Request بيبدأ بفعل بيحدد نيتك للسيرفر:

GET: عايز أقرأ بيانات (زي فتح بروفايل). الـ Parameters بتتبعت في الـ URL (زي ?id=5).
POST: عايز أعمل حاجة جديدة (زي تسجيل حساب أو كتابة بوست). البيانات بتتبعت في الـ Body.
PUT / PATCH: عايز أعدل حاجة موجودة (زي تغيير باسورد أو تحديث دور يوزر).
DELETE: عايز أمسح حاجة.

💡 Hackers Trick: في లابات הـ Access Control، إحنا بنغير الـ POST لـ PUT عشان نخدع الـ Security Firewall اللي بيكون متبرمج يحمي الـ POST بس! (ده اسمه Verb Tampering).

Status Codes (الردود)

السيرفر بيقول إيه؟

لما السيرفر يرد، بيبدأ الرد برقم بيعرفك نتيجة طلبك:

200 OK / 201 Created: نجاح! طلبك اتنفذ بدون مشاكل.
400 Bad Request: إنت باعت حاجة غلط في الـ JSON أو الـ Parameters ناقصة.
401 Unauthorized: إنت مين؟ السيرفر مش متعرف عليك، لازم تبعت Login Token.
403 Forbidden: السيرفر عارف إنت مين، بس إنت ممنوع تدخل هنا! (ده الهدف بتاعنا في الاختراق، إننا نتخطى الـ 403).

// Anatomy of a Request RAW HTTP

أي HTTP Request بيتكون من 3 أجزاء رئيسية ولازم تكون فاهمهم كويس عشان دي الحتة اللي هتعدل فيها طول شغلك:

// 1. REQUEST LINE (Method + Path + Protocol) POST /api/users/update HTTP/1.1 // 2. HEADERS (المعلومات الجانبية للمتصفح والسيرفر) Host: api.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)... Authorization: Bearer eyJhbGciOiJIUzI1... // ده مفتاح دخولك (Token) Content-Type: application/json // إنت بتفهم السيرفر إن الـ Body نوعه JSON Cookie: session_id=123456789 // [EMPTY LINE IS MANDATORY HERE] // 3. BODY (البيانات الفعلية اللي بتتبعت في الـ POST/PUT) { "user_id": "4815", "email": "attacker@test.com", "role": "admin" // ← Parameter Injection Example }

// 02 — المعمارية

API & Databases — فهم הـ Backend

◆ ◇ ◆

// RESTful APIs & Resource Identifiers

التطبيقات الحديثة (اللي معموله بـ React أو Vue) مش بترندر HTML من السيرفر. هي عبارة عن Client بيكلم API بيجيب بيانات (JSON) من الداتابيز.

عشان הـ API يعرف يجيب أي بيانات بالظبط، بيستخدم نظام الـ RESTful routing. כל شيء في الداتابيز بيبقى ليه مسار (Path) ورقم تعريفي (ID).

// مثال لكيفية عمل الـ Routing: GET /api/invoices → بيجيب كل الفواتير بتاعتك GET /api/invoices/901 → بيجيب فاتورة رقم 901 بالظبط DELETE /api/invoices/901→ بيمسح فاتورة رقم 901

🎯 مفهوم הـ IDOR (Insecure Direct Object Reference):
لو إنت فاتورتك رقمها 901، وإنت بعت GET /api/invoices/902.
المفروض السيرفر يقولك 403 Forbidden عشان دي فاتورة حد تاني. بس لو السيرفر جاب البيانات من الداتابيز بدون ما يتأكد إن الفاتورة دي تخصك، إنت كده اكتشفت ثغرة IDOR!

عشان المبرمجين يحموا نفسهم من الـ IDOR، أحياناً بيبدلوا الأرقام بـ UUIDs (زي 8f14e45f-e23a-4f51-a9f8-b18d86f7ab52) عشان يكون صعب التخمين. في لابات الـ IDOR بتاعتنا هنتعلم إزاي نكسر الـ UUIDs دي لما المبرمج يسربها بالغلط.

// 03 — أهم فرق في السيكيوريتي

AuthN vs AuthZ — القاعدة الذهبية للاختراق

◆ ◇ ◆

Authentication (AuthN)

إثبات الهوية (إنت مين؟)

دي عملية الـ Login. إنت بتدي السيرفر Username و Password، وهو بيتأكد من الداتابيز. لو صح، السيرفر بيعملك Session.

السيرفر ممكن يعطيك Session Cookie (معرف عشوائي محفوظ في السيرفر) أو يعطيك JWT (JSON Web Token) (توكن مشفر بيحتوي على بياناتك).

فشل هذه المرحلة يؤدي دائماً إلى 401 Unauthorized.

Authorization (AuthZ)

الصلاحيات (مسموحلك إيه؟)

بعد ما السيرفر عرف إنت مين من التوكن (AuthN نجح)، لازم يسأل نفسه: هل اليوزر ده معاه صلاحية (Role) إنه يشوف لوحة التحكم دي؟

لو الـ Role بتاعك user والصفحة محتاجة admin، السيرفر بيوقفك.

فشل هذه المرحلة يؤدي دائماً إلى 403 Forbidden.

// THE HACKER'S PERSPECTIVE

الـ Bug Bounty Hunters مش بيقضوا وقتهم في كسر الباسوردات (AuthN). إحنا دايماً بنعمل حساب مجاني عادي جداً عشان ننجح في الـ AuthN، وبعدين بنركز كل مجهودنا على كسر הـ AuthZ.

// JWT Structure (JSON Web Token) // Often passed in: Authorization: Bearer eyJhbGci... HEADER (Algorithm used) PAYLOAD (Data claims: {"user_id": 5, "role": "customer"}) SIGNATURE(Crypto hash verifying it hasn't been modified) // Attack Vector: // If the server fails to verify the SIGNATURE, an attacker can decode the PAYLOAD, change "customer" to "admin", re-encode it, and take over the system.

// 04 — الأداة السحرية

Proxy Tooling — إزاي بنتحكم في الريكويست؟

◆ ◇ ◆

// ما هو الـ Intercepting Proxy؟ (Burp Suite / Caido)

في الوضع الطبيعي، البراوزر بيبعت الريكويست للسيرفر في جزء من الثانية (أقل من 100ms) وإنت مش بتشوفه. الـ Proxy هو برنامج بيقف في النص كـ "شرطي مرور".

Intercept (الاعتراض): بيعمل Pause للـ Request قبل ما يطلع من جهازك للسيرفر.
Manipulation (التلاعب): بيخليك تقرأ الـ Headers والـ JSON Body وتعدل فيهم براحتك (تغير ID، تضيف Role، أو تمسح الـ CSRF Token).
Repeater (التكرار): أداة جوه الـ Proxy بتخليك تبعت نفس الريكويست 100 مرة بتعديلات مختلفة وتشوف الـ Response في نفس الشاشة، بدل ما تقعد تدوس في المتصفح.

💡 في লابات الـ IDOR و Access Control بتاعتنا، إحنا محاكين الـ Repeater بالظبط. واجهة اللاب بتديك خانة الـ Request تكتب فيها براحتك، ولما تدوس SENT ✓ إنت كده عملت Forward للسيرفر (الـ Simulation Engine) وبتشوف الـ Response الحقيقي.

◆ ◇ ◆

You Are Ready!

إنت دلوقتي معاك الأساسيات التقنية. افتح لابات الـ IDOR أو الـ Access Control وابدأ كسر القواعد!