SS7_Vulnerabilities_Attacks_V7x Academy.en.ar.pdf

كتاب ممتاز يشرح بروتوكول إس إس سفن أو "SS7" إختصارا لـ "Signal System Seven" بشكل مُفصل، حيث يشرح الكتاب أهم الثغرات والتهديدات الأمنية وطرق التنصت علي الرسائل القصيرة والإشارات أو المكالمات



تفاعلو مع المنشورات لتحفيزنا على نشر المزيد 🫶

🔰Mastering Python | تعلم لغة البايثون 🔰
            🔰 Cyber Attack Team 🔰

🔴Learn Python in Arabic #079 - Date And Time Introduction

#Cyber_Attak_Team
#Mastering_Python
#ElzeroWebSchool
#Cyber_Security

أكيد 👍 هذا فهرس مرتب ومنسق للكتاب بشكل جميل وواضح ليسهل عليك التنقل والفهم:


---

📘 فهرس كتاب Web Hacking Arsenal

🟢 القسم الأول: الأساسيات

1. مقدمة في الويب والمتصفح

HTTP (الطلبات والاستجابات)

Headers والثغرات المرتبطة بها

تطور تطبيقات الويب

الترميز (Encoding)

مكونات المتصفح

سياسات الأمان (SOP, CSP, Cookies, HSTS)



---

🔍 القسم الثاني: الاستطلاع (Recon)

2. جمع المعلومات والاستكشاف

Enumerating IPs و ASN

فحص المنافذ والخدمات

Subdomain Enumeration

اكتشاف Endpoints

رسم Attack Surface

اكتشاف الثغرات تلقائيًا

Cloud Enumeration (مثل AWS)



---

💣 القسم الثالث: هجمات السيرفر

3. Server-Side Injection

SQL Injection (كل الأنواع)

Command Execution (RCE)

Template Injection (SSTI)

NoSQL Injection



---

⚡ القسم الرابع: هجمات المتصفح

4. Client-Side Attacks

XSS (Reflected / Stored / DOM)

تجاوز الحمايات

استغلال XSS (Phishing, Keylogging)



---

🔁 القسم الخامس: التحكم في الطلبات

5. CSRF Attacks

كيفية تنفيذ الهجوم

تجاوز الحماية

SameSite Cookies



---

📂 القسم السادس: هجمات الملفات

6. File System Attacks

Directory Traversal

File Inclusion (LFI/RFI)

File Upload Exploits



---

🔐 القسم السابع: المصادقة والصلاحيات

7. Authentication & Authorization

Brute Force

IDOR

JWT / OAuth / SAML

MFA Bypass



---

🧠 القسم الثامن: منطق التطبيق

8. Business Logic Flaws

التلاعب بالرصيد والمعاملات

Race Conditions

استغلال العمليات الداخلية



---

🌐 القسم التاسع: الهجمات المتقدمة

9. Advanced Attacks

XXE

SSRF

HTTP Request Smuggling



---

🧩 القسم العاشر: Serialization

10. Serialization Attacks

Insecure Deserialization

استغلال PHP / Java / Python / .NET



---

☁️ القسم الحادي عشر: API و Cloud

11. Web Services & Cloud

REST / SOAP / GraphQL

Serverless

Cloud Misconfigurations



---

🧪 القسم الثاني عشر: HTML5

12. HTML5 Attacks

CORS

Web Storage

WebSockets

postMessage



---

🛡️ القسم الثالث عشر: تجاوز الحماية

13. WAF Evasion

اكتشاف WAF

تقنيات تجاوز الحماية

Obfuscation



---

📝 القسم الأخير: التقارير

14. Report Writing

كتابة تقرير Pentest

CVSS

Risk Assessment

عرض النتائج



---

✨ ملاحظة

هذا الفهرس مبني على الصفحات الأولى (جدول المحتويات) في الملف، حيث يعرض جميع الفصول من 1 إلى 14 بشكل منظم.


---

إذا تريد، أقدر أحول هذا الفهرس إلى:

🗺️ خريطة ذهنية (Mind Map)

📅 جدول دراسة يومي

🎯 خطة احتراف Bug Bounty خطوة بخطوة

🧠 أولًا: الخريطة الذهنية (Mind Map)

تخيلها بهذا الشكل (من المركز للخارج):

Web Hacking Arsenal
│
├── 🟢 Basics
│ ├─ HTTP
│ ├─ Browser
│ ├─ Security Policies
│
├── 🔍 Recon
│ ├─ Subdomains
│ ├─ Ports & Services
│ ├─ Attack Surface
│
├── 💣 Server Attacks
│ ├─ SQLi
│ ├─ SSTI
│ ├─ RCE
│
├── ⚡ Client Attacks
│ ├─ XSS
│ ├─ DOM Attacks
│
├── 🔁 CSRF
│
├── 📂 File Attacks
│ ├─ LFI / RFI
│ ├─ Upload
│
├── 🔐 Auth
│ ├─ IDOR
│ ├─ JWT / OAuth
│
├── 🧠 Logic Bugs
│
├── 🌐 Advanced
│ ├─ XXE
│ ├─ SSRF
│ ├─ Smuggling
│
├── 🧩 Serialization
│
├── ☁️ API & Cloud
│
├── 🧪 HTML5
│
├── 🛡️ WAF Bypass
│
└── 📝 Reporting

👉 الفكرة:

كل فرع = مهارة

كل مهارة = تمارين + تطبيق عملي



---

📅 ثانيًا: خطة دراسة 30 يوم 🔥

🟢 الأسبوع 1 (الأساسيات + Recon)

اليوم 1-2

HTTP + Headers


اليوم 3

Browser + SOP + CSP


اليوم 4-5

Subdomain Enumeration


اليوم 6

Port Scanning + Services


اليوم 7

تطبيق عملي (Recon على موقع)



---

⚡ الأسبوع 2 (الهجمات الأساسية)

اليوم 8-9

XSS (Reflected + Stored)


اليوم 10

DOM XSS


اليوم 11

CSRF


اليوم 12-13

File Upload + LFI


اليوم 14

تطبيق عملي (Labs)



---

💣 الأسبوع 3 (الهجمات القوية)

اليوم 15-17

SQL Injection


اليوم 18

SSTI


اليوم 19

RCE


اليوم 20-21

Auth + IDOR + JWT



---

🔴 الأسبوع 4 (الاحتراف)

اليوم 22

Business Logic


اليوم 23

SSRF + XXE


اليوم 24

APIs + GraphQL


اليوم 25

Serialization


اليوم 26

HTML5


اليوم 27

WAF Bypass


اليوم 28

Report Writing


اليوم 29-30

🔥 مشروع عملي (اختبار موقع كامل)



---

🚀 كيف تطبق الخطة صح؟

كل يوم:

📖 اقرأ (30–60 دقيقة)

🧪 طبق (1–2 ساعة)


استخدم:

PortSwigger Labs

TryHackMe




---

🔥 نصيحة مهمة

لو طبقت هذه الخطة بجد: ➡️ خلال شهر واحد ستفهم 70% من مجال Web Hacking
➡️ خلال 3 شهور تقدر تبدأ Bug Bounty فعليًا

✅ طريقة الشرح اللي راح أستخدمها (بأسلوب عالمي)

لكل Chapter ترسله، راح أقسمه لك بهذا الشكل:

1) 🧠 الفهم النظري (Concept)

شرح الفكرة من الصفر

لماذا هذه الثغرة موجودة؟

كيف يفكر الهاكر؟



---

2) ⚙️ الآلية (How it works)

كيف يعمل الهجوم تقنيًا

شرح خطوة بخطوة

ربطه بـ HTTP / Browser / Server



---

3) 💣 التطبيق (Attack Scenarios)

سيناريوهات حقيقية

أمثلة من الواقع

كيف يتم الاستغلال



---

4) 🛡️ الحماية (Defense)

كيف يتم منع الهجوم

أخطاء المطورين الشائعة



---

5) 🧪 التدريب العملي

تمارين

Labs (مثل PortSwigger)

أفكار للتجربة بنفسك



---

6) 📅 تقسيم الشابتر على أيام

راح أقسم لك كل Chapter إلى:

خطة يومية (2–5 أيام حسب حجمه)

كل يوم فيه:

📖 ماذا تقرأ

🎯 ماذا تفهم

🧪 ماذا تطبق




---

🎯 مثال سريع (كيف راح يكون التقسيم)

مثلاً لو الشابتر عن XSS:

اليوم 1:

الفهم العام + Reflected XSS


اليوم 2:

Stored XSS + DOM XSS


اليوم 3:

Bypass + Advanced Techniques


اليوم 4:

Exploitation (سرقة حسابات)


اليوم 5:

Labs + Practice



---

🔥 مهم جدًا

أنا ما راح: ❌ أختصر بشكل مخل
❌ أشرح بشكل نظري ممل

أنا راح: ✅ أبسّط + أعمّق بنفس الوقت
✅ أربط لك كل شيء بالواقع
✅ أدرّبك تفكر مثل Bug Hunter

الفهرس🔎

📅 خطة دراسة 30 يوم 🔥

🟢 الأسبوع 1 (الأساسيات + Recon)

اليوم 1
HTTP
اليوم 2
Headers
اليوم 3
Browser + SOP + CSP
اليوم 4-5
Subdomain Enumeration
اليوم 6
Port Scanning + Services
اليوم 7
تطبيق عملي (Recon على موقع)
⚡ الأسبوع 2 (الهجمات الأساسية)
اليوم 8-9
XSS (Reflected + Stored)
اليوم 10
DOM XSS
اليوم 11
CSRF
اليوم 12-13
File Upload + LFI
اليوم 14
تطبيق عملي (Labs)
💣 الأسبوع 3 (الهجمات القوية)
اليوم 15-17
SQL Injection
اليوم 18
SSTI
اليوم 19
RCE
اليوم 20-21
Auth + IDOR + JWT
🔴 الأسبوع 4 (الاحتراف)
اليوم 22
Business Logic
اليوم 23
SSRF + XXE
اليوم 24
APIs + GraphQL
اليوم 25
Serialization
اليوم 26
HTML5
اليوم 27
WAF Bypass
اليوم 28
Report Writing
اليوم 29-30
🔥 مشروع عملي (اختبار موقع كامل)

📅 اليوم 1 — HTTP من الصفر (شرح معماري عميق)

> اليوم الأول ليس “مقدمة بسيطة”.
هذا اليوم هو الأساس الذي ستُبنى عليه كل الثغرات لاحقًا:

XSS

CSRF

SQLi

SSRF

حتى OAuth وJWT


كلها في النهاية تتحرك داخل HTTP.
لذلك سنفهم HTTP كمهندس ومخترق في نفس الوقت.



الجزء الذي نعتمد عليه هنا من بداية Chapter 1 يشرح:

مفهوم HTTP

خصائصه

الطلبات والاستجابات

كيف تنتقل البيانات بين Client وServer

لماذا HTTP صُمم بهذه الطريقة أصلًا



---

1) 🧠 الفهم النظري (Concept)


---

🔹 أولًا: ما هو HTTP فعلًا؟

HTTP اختصار لـ:

> HyperText Transfer Protocol



لكن هذا التعريف لا يشرح شيئًا فعليًا.

لفهم HTTP بعمق، يجب أن نفهم:

> لماذا تم اختراعه أصلًا؟




---

🔹 كيف بدأ الويب تاريخيًا؟

في البداية، الإنترنت لم يكن “تطبيقات” كما نعرف اليوم.

لم يكن هناك:

تسجيل دخول

حسابات

جلسات

APIs

JWT

React


بل كان الهدف الأساسي:

> مشاركة مستندات بين الجامعات ومراكز الأبحاث.



يعني:

شخص يطلب ملف

السيرفر يرسل الملف


مثل:

GET /paper.html

ثم السيرفر:

HTTP/1.1 200 OK


---

🔥 المشكلة الكبرى

HTTP صُمم أصلًا:

> “لنقل المستندات”



لكننا اليوم نستخدمه لـ:

البنوك

المصادقة

المدفوعات

الأنظمة الحساسة


وهنا بدأت المشاكل الأمنية.


---

🔹 لماذا؟

لأن التصميم الأصلي لـ HTTP:

بسيط جدًا

عديم الحالة (Stateless)

نصي (Text-based)

قابل للتعديل بالكامل



---

🔹 ماذا يعني Text-Based؟

يعني أن HTTP ليس Binary معقدًا.

بل مجرد:

> نص يمكن قراءته وتعديله بسهولة



مثل:

GET / HTTP/1.1
Host: example.com


---

🔥 لماذا هذا مهم جدًا أمنيًا؟

لأن أي شخص يستطيع:

قراءة الطلب

تعديله

إعادة إرساله


ولهذا:

> الويب بطبيعته “بيئة غير موثوقة”




---

🔹 الآن أهم نقطة في اليوم كله

المستخدم العادي يرى:

زر

صفحة

نموذج


لكن السيرفر لا يرى شيئًا من ذلك.

السيرفر يرى فقط:

Request Text


---

🧠 كيف يفكر الهاكر؟

المستخدم:

> "ضغطت زر تسجيل دخول"



الهاكر:

> "تم إرسال POST Request"



المستخدم:

> "هذه صفحة ملفي الشخصي"



الهاكر:

> "هذا endpoint يستقبل id"




---

🔥 إذن ما هو الاختراق الحقيقي؟

في أغلب اختراقات الويب:

> أنت لا “تكسر الموقع”



بل:

> تغيّر طريقة فهم السيرفر للطلب




---

🔹 مفهوم Stateless (عميق جدًا)

الكتاب يذكر أن HTTP:

> Stateless Protocol



لكن ما معنى ذلك فعليًا؟


---

🧠 المعنى الحقيقي

السيرفر:

> لا يتذكر أي شيء بين الطلبات



كل Request مستقل تمامًا.


---

🔥 مثال واقعي

إذا أرسلت:

GET /profile

ثم بعد ثانية:

GET /settings

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

نفس الشخص أرسل الطلبين

إلا إذا تم إثبات ذلك



---

🔥 كيف حُلّت هذه المشكلة؟

تم اختراع:

Cookies

Sessions

Tokens


وهذه ليست جزءًا أصليًا من HTTP.

بل:

> حلول إضافية فوق بروتوكول بسيط لم يُصمم للحالة (State).




---

🔥 وهنا تبدأ كمية هائلة من الثغرات

لأن:

HTTP لا يعرف المستخدم

نحن نحاول “إجباره” على تذكر المستخدم


ومن هنا ظهرت:

Session Hijacking

CSRF

Cookie Attacks



---

🔹 خاصية أخرى مهمة: HTTP غير مشفر

الكتاب يذكر أن HTTP:

> لا يحتوي تشفيرًا داخليًا




---

🧠 ماذا يعني هذا؟

أي جهاز في الطريق يمكنه رؤية البيانات:

Router

ISP

Proxy

أي شخص على الشبكة



---

🔥 لذلك ظهر HTTPS

HTTPS ليس بروتوكولًا جديدًا بالكامل.

بل:

> HTTP داخل طبقة TLS/SSL



يعني:

HTTP + Encryption = HTTPS


---

🔥 لماذا هذا مهم جدًا أمنيًا؟

بدون HTTPS:

كلمات المرور مكشوفة

الكوكيز مكشوفة

التوكنات مكشوفة



---

2) ⚙️ الآلية (How it works — Deep Architecture)


---

🔹 ماذا يحدث عندما تفتح موقعًا؟

عندما تكتب:

google.com

أنت لا “تذهب لموقع”.

بل تبدأ سلسلة معقدة جدًا.


---

🧩 المرحلة 1 — DNS

المتصفح لا يفهم:

google.com

بل يحتاج:

142.250.xxx.xxx

لذلك يسأل DNS.


---

🧩 المرحلة 2 — إنشاء الاتصال

يبدأ TCP Handshake.

لماذا؟ لأن HTTP يعتمد على TCP.


---

🔥 لماذا TCP مهم؟

لأن TCP:

يضمن الترتيب

يمنع فقدان البيانات

يضمن وصول الحزم



---

🧩 المرحلة 3 — بناء HTTP Request

الآن المتصفح يبني الطلب.


---

🔬 تحليل حقيقي للطلب

من الكتاب:

GET /index.html HTTP/1.1
Host: www.redseclabs.com
User-Agent: Mozilla/5.0
Referer: https://google.com




---

🔍 السطر الأول

GET /index.html HTTP/1.1

هذا يسمى:

> Request Line




---

🔹 GET

نوع العملية (Method)


---

🔹 /index.html

المورد المطلوب


---

🔹 HTTP/1.1

نسخة البروتوكول


---

🔥 نقطة احترافية

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

هل هذا زر؟

هل هذا فورم؟


بل يعرف فقط:

Method + Path


---

🔍 Host Header

Host: www.redseclabs.com


---

🧠 لماذا أُضيف Host أصلًا؟

قديمًا:

كل IP = موقع واحد


لكن لاحقًا:

IP واحد يستضيف آلاف المواقع


كيف يميز السيرفر؟

عبر:

Host


---

🔥 الآن بدأت المشاكل الأمنية

لأن السيرفر:

> بدأ يعتمد على قيمة يرسلها المستخدم



ومن هنا ظهرت:

Host Header Injection

Password Reset Poisoning



---

🔍 User-Agent

User-Agent: Mozilla/5.0


---

🧠 لماذا وُجد؟

لأن المواقع احتاجت معرفة:

نوع المتصفح

النظام

التوافق



---

🔥 لكن المشكلة

هو مجرد:

> String يمكن تزويره بالكامل




---

🔍 Referer

Referer: https://google.com


---

🧠 لماذا وُجد؟

لإخبار السيرفر:

> من أين جاء المستخدم




---

🔥 لماذا أصبح خطيرًا؟

لأنه قد يسرّب:

tokens

sessions

reset links



---

🧩 المرحلة 4 — السيرفر يرد

مثال من الكتاب:

HTTP/1.1 200 OK
Server: Apache/2.4.41
Content-Type: text/html




---

🔥 هنا يبدأ تفكير الهاكر

Server: Apache/2.4.41

هذه ليست “معلومة بريئة”.

بل:

> بصمة تقنية (Fingerprint)




---

🧠 ماذا يفعل الهاكر؟

يبحث:

هل هذا الإصدار قديم؟

هل له CVE؟

هل يوجد Exploit؟



---

3) 💣 التطبيق (Attack Scenarios — Real Security Thinking)


---

🔥 سيناريو 1 — البيانات في GET

GET /login?user=admin&pass=123


---

🔬 لماذا هذا كارثي؟

لأن Query String:

تُخزن

تُسجل

تُشارك



---

🔥 أين؟

1️⃣ Browser History

المتصفح يحفظ الرابط كاملًا.


---

2️⃣ Server Logs

السيرفر يسجل الطلب.


---

3️⃣ Referer Leakage

إذا خرج المستخدم لموقع آخر: قد يُرسل الرابط كاملًا.


---

🔥 السيناريو الحقيقي

موقع:

/reset?token=ABC123

ثم المستخدم يضغط إعلان خارجي.

المتصفح قد يرسل:

Referer: https://site.com/reset?token=ABC123

💥 انتهى الأمر.


---

🔥 سيناريو 2 — الاعتماد على User-Agent

تطبيق:

if User-Agent == mobile

الهاكر:

User-Agent: iPhone

💥 bypass


---

🔥 سيناريو 3 — معلومات السيرفر

Server: Apache/2.4.41

الهاكر:

يبحث عن ثغرات لهذا الإصدار



---

4) 🛡️ الحماية (Defense — Architectural Thinking)


---

🔐 1) Treat Everything as Untrusted

أي شيء يأتي من:

Request

Header

Parameter


❌ غير موثوق


---

🔐 2) لا تضع Secrets في URL

أبدًا.


---

🔐 3) استخدم HTTPS دائمًا

لأن HTTP:

> غير آمن بطبيعته




---

🔐 4) قلل المعلومات

لا تعرض:

الإصدارات

التفاصيل الداخلية



---

🔐 5) افهم أن الواجهة ليست حماية

JavaScript: ❌ ليس Security Boundary


---

5) 🧪 التدريب العملي (احترافي)


---

🧪 تمرين 1 — رؤية HTTP الحقيقي

افتح:

DevTools

Network


راقب:

Method

Headers

Response



---

🧪 تمرين 2 — التفكير كهاكر

لكل Request اسأل:

ماذا لو غيرته؟

هل يتحقق السيرفر؟



---

🧪 تمرين 3 — تحليل معماري

خذ أي موقع واسأل:

أين تُخزن البيانات؟

هل هناك GET حساس؟

هل يوجد معلومات في headers؟



---

🧠 خلاصة اليوم (الفهم الحقيقي)

اليوم الأول ليس عن “HTTP فقط”.

بل عن:

> كيف صُمم الويب أصلًا، ولماذا أدى هذا التصميم إلى ظهور الثغرات الحديثة.




---

🎯 أهم فكرة في اليوم كله

> "معظم اختراقات الويب ليست كسرًا للتشفير… بل استغلال لطريقة فهم السيرفر للطلبات."

📅 اليوم 2 — HTTP Methods & Headers (شرح معماري وهجومي عميق)

> اليوم الأول فهمنا فيه:

لماذا HTTP صُمم بهذه الطريقة

كيف يتحرك الطلب

كيف يرى السيرفر العالم


اليوم الثاني سندخل إلى: 🔥 “الطبقة التي يعتمد عليها التطبيق لاتخاذ القرارات”

وهي:

Methods

Headers


وهذا اليوم مهم جدًا لأن كثيرًا من:

Logic Bugs

Authentication bypasses

Cache Poisoning

Password Reset Poisoning

Access Control flaws


تبدأ من سوء فهم هذه الطبقة.



الكتاب في هذا الجزء يشرح:

خصائص HTTP methods

الفرق بين GET وPOST

خطورة وضع البيانات الحساسة داخل URL

الهيدرز المختلفة مثل Host وReferer وUser-Agent

وكيف تؤدي إلى مشاكل أمنية عند الثقة بها بشكل خاطئ



---

1) 🧠 الفهم النظري (Concept)


---

🔹 أولًا: ما هي HTTP Methods فعلًا؟

في الشرح السطحي يُقال:

GET = جلب بيانات

POST = إرسال بيانات


لكن هذا ليس الفهم الحقيقي.


---

🔥 الفهم الحقيقي

HTTP Methods ليست “تعليمات برمجية”.

بل:

> “إشارات Intent” يخبر بها العميل السيرفر ماذا يريد أن يفعل.



مثلًا:

GET /profile

المعنى المنطقي:

> “أريد قراءة profile”




---

POST /profile

المعنى:

> “أريد إرسال/تعديل بيانات”




---

🔥 لكن هنا المشكلة الكبيرة

HTTP نفسه:

> لا يفرض هذه المعاني



يعني:

يمكن أن تجعل GET يحذف بيانات

ويمكن أن تجعل POST يقرأ فقط



---

🧠 إذن أين تأتي القواعد؟

من:

المطور

Framework

Convention


وليس من HTTP نفسه.


---

🔥 لماذا هذا مهم أمنيًا؟

لأن كثيرًا من المطورين يخلط بين:

> “المعنى المتوقع” و “السلوك الحقيقي”




---

🔥 مثال خطير جدًا

المطور يعتقد:

GET = آمن

فيقوم بكتابة:

GET /deleteUser?id=5


---

💣 ما المشكلة؟

لأن GET:

يمكن فتحه عبر رابط

يمكن عمل preload له

يمكن أن يزوره المتصفح تلقائيًا

يمكن تضمينه داخل img/script



---

🔥 الآن بدأت مشاكل مثل:

CSRF

Accidental Actions

Unsafe State Changes



---

🔹 ثانيًا: ما هي Headers معماريًا؟

الشرح السطحي:

> “معلومات إضافية”



لكن الحقيقة:

Headers هي:

> طبقة Metadata تتحكم بكيفية تفسير الطلب والرد.




---

🧠 ماذا يعني Metadata؟

يعني:

معلومات عن البيانات

وليس البيانات نفسها


مثل:

من أرسل؟

من أين جاء؟

ماذا يقبل؟

ما نوع المحتوى؟

كيف يجب تفسيره؟



---

🔥 لماذا هذا مهم جدًا؟

لأن التطبيق يبدأ بالاعتماد عليها لاتخاذ قرارات.


---

🔥 وهنا أصل المشكلة

Headers:

تبدو “رسمية”

لكنها تأتي من المستخدم



---

🧠 التناقض الخطير

السيرفر يتعامل معها أحيانًا كأنها:

> Trusted Context



لكنها فعليًا:

> User Input




---

🔥 وهذا أصل كمية ضخمة من الثغرات الحديثة.


---

2) ⚙️ الآلية (How it works — Deep Technical Analysis)


---

🔹 تحليل GET بعمق

مثال الكتاب:

GET /login.php?username=myusername&password=mypassword HTTP/1.1




---

🔬 ماذا يحدث فعليًا هنا؟

البيانات أصبحت جزءًا من:

URL


---

🔥 لماذا هذا خطير جدًا معماريًا؟

لأن الويب كله بُني على افتراض أن:

> URL يمثل “موردًا” يمكن:



حفظه

مشاركته

تخزينه

عمل Cache له



---

🔥 إذن عندما تضع Secret داخل URL:

أنت فعليًا:

> تُدخل السر داخل بنية الويب نفسها




---

🔬 أين ينتشر هذا السر؟


---

1️⃣ Browser History

المتصفح يحفظ:

/login?username=...&password=...


---

2️⃣ Server Logs

Apache/Nginx غالبًا يسجل الطلب كاملًا.


---

3️⃣ Reverse Proxies

مثل:

Cloudflare

Nginx

CDN


قد تسجل الطلبات.


---

4️⃣ Analytics Platforms

قد تقرأ URLs.


---

5️⃣ Referer Leakage

وهذه أخطر نقطة غالبًا.

إذا زار المستخدم:

/reset?token=ABC

ثم خرج إلى:

facebook.com

قد يرسل المتصفح:

Referer: https://site.com/reset?token=ABC

💥 الآن التوكن خرج خارج النظام.


---

🔹 POST (الفهم الحقيقي)

مثال:

POST /login.php HTTP/1.1

username=admin&password=123




---

🔬 لماذا POST “أفضل”؟

ليس لأنه:

> آمن



بل لأن:

> Body لا يُعامل كبنية URL




---

🔥 ماذا يعني ذلك؟

عادة:

لا يدخل history

لا يُستخدم cache key

لا يُرسل في Referer



---

❗ لكن انتبه

POST:

ما زال قابلًا للاعتراض

ما زال قابلًا للتعديل

ما زال يُقرأ داخل السيرفر



---

🔥 أهم نقطة

الفرق بين:

GET

POST


ليس:

> Security



بل:

> How the web ecosystem treats the data




---

🔹 تحليل Headers بعمق


---

🔍 Host Header

Host: example.com


---

🧠 لماذا أُضيف؟

قديمًا:

IP واحد = موقع واحد


لاحقًا:

Virtual Hosting


فأصبح:

IP واحد = آلاف المواقع



---

🔥 إذن Host أصبح:

> طريقة اختيار التطبيق داخل السيرفر




---

💣 المشكلة الأمنية

المطور بدأ يستخدم Host في:

بناء الروابط

redirects

reset links



---

🔥 مثال خطير جدًا

التطبيق:

resetLink = "https://" + Host + "/reset?token=XYZ"

الهاكر:

Host: evil.com


---

💥 النتيجة

الرابط يصبح:

https://evil.com/reset?token=XYZ


---

🔥 الآن:

الضحية تستلم الرابط

تضغط

التوكن يذهب للمهاجم



---

🔥 هذا يسمى:

Password Reset Poisoning


---

🔍 User-Agent

User-Agent: Mozilla/5.0


---

🧠 لماذا وُجد؟

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

نوع المتصفح

النظام

التوافق



---

💣 المشكلة

هو مجرد:

String


---

🔥 أي شخص يستطيع:

User-Agent: iPhone


---

🔥 لماذا هذا مهم؟

بعض الأنظمة:

تعطي صلاحيات

تخفي خصائص

تغير behavior


اعتمادًا عليه.


---

🔍 Referer

Referer: https://google.com


---

🧠 لماذا أُضيف؟

لإخبار الموقع:

> من أين جاء المستخدم




---

🔥 المشكلة

يمكن أن يحتوي:

Tokens

Secrets

Session IDs



---

💣 وعند الانتقال لموقع آخر:

قد يتم تسريبه.


---

3) 💣 التطبيق (Real Attack Scenarios)


---

🔥 سيناريو 1 — GET State Change

GET /deleteAccount


---

💣 لماذا خطير؟

لأن:

المتصفح قد يزور الرابط تلقائيًا

صورة مخفية قد تستدعيه

crawler قد يفتحه



---

🔥 النتيجة

حذف الحساب بدون قصد.


---

🔥 سيناريو 2 — Host Header Injection

المهاجم:

Host: evil.com

التطبيق:

يبني reset link



---

💥 النتيجة

سرقة حساب.


---

🔥 سيناريو 3 — Referer Leakage

رابط reset يحتوي token.

المستخدم يخرج لموقع خارجي.


---

💥 النتيجة

التوكن يتسرب.


---

🔥 سيناريو 4 — User-Agent Trust

النظام:

if User-Agent == internal


---

💥 bypass


---

4) 🛡️ الحماية (Defense — Deep Defensive Thinking)


---

🔐 1) Treat Headers as User Input

أي Header: ❌ غير موثوق


---

🔐 2) Never Put Secrets in URLs

أبدًا.


---

🔐 3) Validate Host Header

whitelist

canonical host



---

🔐 4) استخدم Referrer-Policy

مثل:

Referrer-Policy: strict-origin-when-cross-origin




---

🔐 5) لا تعتمد على User-Agent أمنيًا


---

🔐 6) GET يجب ألا يغير State

هذه نقطة معمارية مهمة جدًا.


---

5) 🧪 التدريب العملي (Professional Labs)


---

🧪 تمرين 1 — تحليل Requests

افتح DevTools:

راقب Headers

راقب Methods



---

🧪 تمرين 2 — Burp Suite

غيّر:

Host

Referer

User-Agent


وراقب behavior.


---

🧪 تمرين 3 — تفكير معماري

لكل Request اسأل:

هل هذه البيانات يجب أن تكون في URL؟

هل هناك secret؟

هل يعتمد التطبيق على Header؟



---

🧪 تمرين 4 — تحليل State Changes

ابحث:

هل يوجد GET يغير بيانات؟



---

🧠 خلاصة اليوم (الفهم الحقيقي)

اليوم الثاني ليس عن:

> “ما هو GET وPOST”



بل عن:

> كيف تتعامل بنية الويب بالكامل مع البيانات، وكيف يؤدي سوء فهم هذه البنية إلى ظهور الثغرات.




---

🎯 أهم فكرة في اليوم

> "الثغرات لا تظهر لأن HTTP ضعيف… بل لأن التطبيقات تبني ثقة خاطئة فوق بروتوكول لا يفرض هذه الثقة."

📅 اليوم 3 — Browser Security Model + Same-Origin Policy (SOP) + CSP

(شرح معماري عميق لكيف يفكر المتصفح ولماذا ظهرت أخطر ثغرات الويب)

> اليوم الثالث يعتبر من أهم الأيام في الرحلة كلها.

لأنك اليوم لن تتعلم “ثغرة”.

بل ستتعلم:

🔥 كيف يفكر المتصفح نفسه.

وإذا فهمت هذا اليوم جيدًا… ستفهم لاحقًا:

XSS

CSRF

CORS

Clickjacking

Token Theft

Session Hijacking

DOM Attacks


لأن كل هذه مرتبطة مباشرة بطريقة عمل الـ Browser Security Model.



الكتاب في هذا الجزء يشرح:

مكونات المتصفح

Same-Origin Policy

Content Security Policy

Iframe sandboxing

Subresource Integrity

HSTS

وكيف ظهرت مشاكل الـ SOP bypasses بسبب اختلاف تفسير الطبقات المختلفة داخل المتصفح



---

1) 🧠 الفهم النظري (Concept — Deep Browser Architecture)


---

🔹 أولًا: ما هو المتصفح فعلًا؟

الناس تتعامل مع المتصفح كأنه:

> “برنامج يعرض مواقع”



لكن هذا فهم سطحي جدًا.


---

🔥 المتصفح فعليًا هو:

> نظام تشغيل مصغر للتطبيقات غير الموثوقة




---

🧠 ماذا يعني ذلك؟

عندما تفتح موقعًا…

أنت فعليًا تسمح لكود خارجي من الإنترنت أن يعمل على جهازك:

JavaScript

HTML

CSS

WebAssembly

APIs



---

🔥 تخيل خطورة هذا

أي موقع تفتحه:

> يمكنه تنفيذ كود داخل بيئة المتصفح




---

🔥 إذن السؤال التاريخي المهم:

كيف سمحت المتصفحات بتشغيل كود من الإنترنت… بدون أن تدمر جهاز المستخدم؟


---

🔥 هنا ظهر:

> Browser Security Model




---

🔹 ما هو Browser Security Model؟

هو:

> مجموعة القوانين التي تمنع المواقع من مهاجمة بعضها أو الوصول لبيانات بعضها.




---

🔥 لماذا هذا ضروري؟

تخيل السيناريو التالي:

أنت فتحت:

Gmail

Facebook

بنكك


في نفس المتصفح.

ثم فتحت:

evil.com


---

💣 ماذا سيحدث بدون حماية؟

evil.com يمكنه:

قراءة Gmail

سرقة Session البنك

إرسال رسائل

قراءة البيانات



---

🔥 إذن المتصفح يحتاج:

> “عزل” المواقع عن بعضها



ومن هنا ظهرت:

🔐 Same-Origin Policy (SOP)


---

🔹 ما هي SOP فعليًا؟

الشرح السطحي يقول:

> “سياسة تمنع المواقع من الوصول لبعضها”



لكن هذا ليس الفهم الحقيقي.


---

🔥 SOP فعليًا هي:

> الجدار الأمني الأساسي الذي يمنع JavaScript من كسر حدود المواقع الأخرى.




---

🧠 ماذا يعني Origin؟

Origin =

Protocol + Host + Port


---

🔬 مثال

هذه:

https://example.com

ليست نفس:

http://example.com

ولا نفس:

https://admin.example.com

ولا نفس:

https://example.com:8080


---

🔥 لماذا كل هذا مهم؟

لأن:

> المتصفح يعزل البيانات بناءً على Origin




---

🔥 إذن ما الذي تمنعه SOP؟

إذا كان لديك:

evil.com

فإن JavaScript بداخله لا يستطيع:

❌ قراءة:

gmail.com

bank.com

facebook.com



---

🔥 نقطة مهمة جدًا

SOP لا تمنع:

> إرسال الطلبات



بل تمنع:

> قراءة الردود




---

🧠 هذه نقطة احترافية جدًا

يعني:

fetch("https://bank.com")

قد يُرسل الطلب…

لكن: ❌ JavaScript لن يستطيع قراءة النتيجة غالبًا.


---

🔥 لماذا هذا التصميم؟

لأن الويب يحتاج:

تحميل صور

تحميل scripts

تحميل iframes


من مواقع مختلفة.


---

🔥 إذن لو مُنع كل شيء:

> الويب لن يعمل أصلًا




---

🔥 لذلك SOP هي:

> توازن بين الوظائف والأمان




---

🔹 الآن السؤال الخطير

إذا كانت SOP قوية جدًا…

كيف تظهر:

XSS

Token Theft

Session Hijacking ؟



---

🔥 الجواب المهم جدًا

لأن:

> SOP تثق بالكود داخل نفس الـ Origin




---

🔥 وهذه أخطر نقطة في XSS

إذا استطعت تشغيل JavaScript داخل:

bank.com

فأنت أصبحت:

> “داخل الحدود الموثوقة”




---

🔥 إذن XSS ليس:

> “تشغيل JavaScript”



بل:

> “إقناع المتصفح أن كود المهاجم ينتمي لنفس Origin”




---

2) ⚙️ الآلية (How it works — Deep Internal Mechanics)


---

🔹 كيف يرى المتصفح المواقع داخليًا؟

المتصفح لا يرى:

صفحات

أزرار


بل يرى:

Origins

Processes

Execution Contexts



---

🔥 لماذا؟

لأن المتصفح يشغّل:

JavaScript

DOM

Rendering


داخل بيئات منفصلة.


---

🔹 Site Isolation

الكتاب يذكر مفهوم:

> Site Isolation




---

🧠 لماذا ظهر؟

قديمًا:

عدة مواقع كانت تعمل داخل نفس Process



---

💣 المشكلة

لو حدث:

Memory corruption

Browser bug


قد يتم الوصول لبيانات مواقع أخرى.


---

🔥 لذلك المتصفحات الحديثة بدأت:

> فصل المواقع في Processes مستقلة




---

🔥 هذا مهم جدًا ضد:

Spectre

Memory leaks

Cross-site attacks



---

🔹 كيف تطبق SOP فعليًا؟


---

🧩 السيناريو

لدينا:

evil.com

يحاول تنفيذ:

fetch("https://bank.com/account")


---

🔥 ماذا يحدث داخليًا؟

1️⃣ المتصفح يسمح بإرسال الطلب

لأن:

الإنترنت يحتاج cross-origin requests



---

2️⃣ bank.com يرد


---

3️⃣ الآن SOP تتدخل

المتصفح يفحص:

Origin(requester) != Origin(target)


---

💥 النتيجة

JavaScript لا يستطيع قراءة response.


---

🔥 إذن SOP تعمل:

> بعد وصول الرد



وهذه نقطة دقيقة جدًا.


---

🔹 DOM وSOP

JavaScript من:

evil.com

لا يستطيع:

window.frames[0].document

إذا كان iframe من Origin مختلف.


---

🔥 لأن DOM أيضًا محمي بـ SOP


---

🔹 لماذا ظهرت SOP bypasses؟

الكتاب يذكر:

> اختلاف تفسير الطبقات المختلفة داخل المتصفح قد يؤدي إلى bypasses




---

🧠 ماذا يعني هذا؟

المشكلة ليست دائمًا:

> “فشل SOP”



بل:

> “طبقة تفهم البيانات بطريقة تختلف عن طبقة أخرى”




---

🔥 مثال معماري مهم

قد:

DNS يرى domain معين

DOM يراه مختلفًا

Cookie store يفسره بطريقة أخرى



---

💣 هنا تبدأ bypasses


---

3) 💣 التطبيق (Real Attack Scenarios)


---

🔥 سيناريو 1 — لماذا XSS كارثي؟

إذا حقن المهاجم JavaScript داخل:

bank.com

فإن SOP تعتبره:

> موثوقًا




---

💥 النتيجة

يمكنه:

قراءة DOM

قراءة tokens

إرسال requests

تنفيذ actions



---

🔥 الآن فهمت:

لماذا XSS من أخطر الثغرات.


---

🔥 سيناريو 2 — iframe attacks

evil.com يضع:

<iframe src="https://bank.com">


---

💣 هل يستطيع قراءة محتواه؟

❌ لا

بسبب SOP.


---

🔥 سيناريو 3 — Browser Bug

لو حدث:

renderer bug

memory corruption


قد يتم تجاوز العزل.


---

🔥 لهذا Browser Exploitation خطير جدًا.


---

4) 🛡️ الحماية (Defense — Browser-Level Security Thinking)


---

🔐 1) SOP

أول خط دفاع.


---

🔐 2) CSP (Content Security Policy)

الكتاب يشرح CSP كآلية:

> لتقييد مصادر المحتوى والسكربتات




---

🔥 لماذا ظهرت CSP؟

لأن:

> SOP وحدها لا تمنع XSS




---

🔥 كيف تعمل CSP؟

مثال:

Content-Security-Policy:
script-src trusted.com


---

🧠 ماذا يعني؟

المتصفح:

> لن يشغّل JavaScript إلا من trusted.com




---

🔥 إذن CSP تحاول:

> تقليل أثر XSS




---

🔥 لكنها ليست مثالية

لأن:

misconfigurations

unsafe-inline

bypasses



---

🔐 3) Iframe Sandbox

لعزل المحتوى داخل iframe.


---

🔐 4) Subresource Integrity (SRI)

الكتاب يذكر:

> SRI يتحقق من سلامة الملفات الخارجية




---

🔥 لماذا هذا مهم؟

إذا تم اختراق CDN…

المتصفح يرفض الملف المعدل.


---

🔐 5) HSTS

لإجبار HTTPS.


---

5) 🧪 التدريب العملي (Professional Labs)


---

🧪 تمرين 1 — مراقبة SOP

افتح Console:

fetch("https://google.com")

راقب:

هل أُرسل الطلب؟

هل أمكن قراءة الرد؟



---

🧪 تمرين 2 — iframe isolation

أنشئ:

<iframe src="https://example.com"></iframe>

ثم حاول الوصول للـ DOM.


---

🧪 تمرين 3 — CSP

افتح موقع يستخدم CSP.

راقب:

Headers

blocked scripts



---

🧪 تمرين 4 — تحليل Origins

قارن:

https://example.com
http://example.com
https://admin.example.com

هل تعتبر نفس Origin؟


---

🧠 خلاصة اليوم (الفهم الحقيقي)

اليوم الثالث ليس عن:

> “سياسة SOP”



بل عن:

> كيف يحاول المتصفح تشغيل كود غير موثوق من الإنترنت… بدون أن يسمح له بكسر حدود المواقع الأخرى.




---

🎯 أهم فكرة في اليوم

> "XSS خطير ليس لأنه JavaScript… بل لأنه يجعل المتصفح يثق بكود المهاجم كأنه جزء من نفس الموقع."

📅 اليوم 4 — Cookies + Sessions + State Management

(كيف يحاول الويب “تذكر” المستخدم… ولماذا أدى ذلك إلى ظهور أخطر الهجمات)

> اليوم الرابع يعتبر نقطة تحول مهمة جدًا.

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

🔥 كيف يعرف الموقع أنك “أنت”

وهذا يقود مباشرة لفهم:

Session Hijacking

CSRF

Cookie Attacks

Authentication Bypass

Token Theft


لأن كل هذه تعتمد على:

إدارة الحالة (State Management)



الكتاب في هذا الجزء يشرح:

Cookies

Domain & Path scoping

Secure / HttpOnly / SameSite

كيف تُخزن الجلسات

ولماذا يؤدي سوء تصميمها إلى مشاكل أمنية خطيرة



---

1) 🧠 الفهم النظري (Concept — لماذا ظهرت Cookies أصلًا؟)


---

🔹 المشكلة الأساسية في HTTP

في اليوم الأول فهمنا أن HTTP:

> Stateless



يعني:

كل Request مستقل

السيرفر لا “يتذكر” المستخدم



---

🔥 لكن التطبيقات الحديثة تحتاج حالة (State)

مثلًا:

بعد تسجيل الدخول

يجب أن يعرف الموقع أنك نفس الشخص



---

🔥 إذن كيف حُلّت المشكلة؟

تم اختراع:

🍪 Cookies


---

🔹 ما هي Cookie فعلًا؟

الشرح السطحي يقول:

> “ملف صغير يُخزن في المتصفح”



لكن هذا ليس الفهم الحقيقي.


---

🔥 الفهم الحقيقي

Cookie هي:

> آلية ربط بين عدة Requests مستقلة لتبدو كأنها جلسة واحدة.




---

🧠 ماذا يعني ذلك؟

بدل أن يكون كل Request منفصلًا:

يقوم السيرفر بإعطاء المتصفح:

> معرف Session



ثم يعيده المتصفح مع كل Request.


---

🔥 إذن السيرفر لا “يتذكر” المستخدم فعليًا

بل:

> المستخدم يحمل معه “دليل هويته” ويرسله كل مرة.




---

🔥 وهذه فكرة خطيرة جدًا أمنيًا

لأن:

> إذا سرق شخص هذا الدليل… يصبح هو المستخدم.




---

🔹 كيف تعمل الجلسات معماريًا؟


---

🧩 السيناريو الكامل

1️⃣ المستخدم يسجل الدخول

POST /login


---

2️⃣ السيرفر يتحقق من كلمة المرور


---

3️⃣ السيرفر ينشئ Session

في قاعدة البيانات مثلًا:

Session ID User

abc123 admin



---

4️⃣ السيرفر يرسل Cookie

Set-Cookie: session=abc123


---

5️⃣ المتصفح يخزنها


---

6️⃣ مع كل Request لاحق

المتصفح يرسل:

Cookie: session=abc123


---

🔥 الآن فهمت شيئًا مهمًا جدًا

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

IP

اسمك

جهازك


بل يعرفك من:

Session Token


---

🔥 إذن أخطر شيء في حسابك غالبًا ليس كلمة المرور…

بل:

> Session Cookie




---

🔹 لماذا Cookies خطيرة جدًا؟

لأنها:

تُرسل تلقائيًا

مع كل Request

بدون تدخل المستخدم



---

🔥 وهذه النقطة هي أساس:

CSRF

(سنفهمها لاحقًا بعمق)


---

🔹 كيف يحدد المتصفح أين يرسل Cookie؟

الكتاب يشرح:

Domain

Path

SameSite

Secure

HttpOnly



---

🔥 لماذا هذا مهم؟

لأن Cookie ليست:

> “عالمية”



بل مرتبطة بسياق معين.


---

🔹 Domain Scoping

مثال:

Set-Cookie: session=abc;
Domain=.example.com


---

🧠 ماذا يعني؟

كل:

app.example.com

admin.example.com


سيحصلون على نفس Cookie.


---

💣 لماذا هذا خطير؟

إذا كان أحد الـ subdomains ضعيفًا…

قد يسرق:

> Session الموقع الرئيسي.




---

🔥 هذه نقطة احترافية جدًا

ضعف:

blog.example.com

قد يؤدي لاختراق:

bank.example.com

إذا كانت الـ Cookie مشتركة.


---

🔹 Path Scoping

Path=/admin


---

🧠 ماذا يعني؟

Cookie تُرسل فقط لمسارات:

/admin


---

🔥 لماذا هذا مهم؟

لتقليل:

exposure

accidental leakage



---

🔹 Secure Flag

Secure


---

🧠 ماذا يفعل؟

Cookie: ❌ لا تُرسل عبر HTTP

✔ فقط HTTPS


---

🔥 لماذا هذا مهم جدًا؟

بدونها:

أي downgrade لـ HTTP

قد يسرّب الجلسة



---

🔹 HttpOnly Flag

HttpOnly


---

🧠 ماذا يفعل؟

JavaScript: ❌ لا يستطيع قراءة Cookie


---

🔥 لماذا أُضيف؟

لأن:

> XSS كان يسرق Cookies بسهولة




---

🔥 لكن نقطة مهمة جدًا

HttpOnly: ❌ لا يمنع XSS

بل: ✔ يقلل أثره


---

🔹 SameSite (مهم جدًا)

الكتاب يشرح SameSite كآلية لتقليل إرسال Cookies عبر Cross-Site Requests


---

🔥 لماذا ظهرت SameSite؟

لأن:

Cookies تُرسل تلقائيًا

حتى في requests القادمة من مواقع أخرى



---

💣 وهذا أصل:

CSRF


---

🔥 مثال خطير

أنت مسجل دخول في:

bank.com

ثم تزور:

evil.com

evil.com ينشئ:

<img src="https://bank.com/transfer?amount=1000">


---

💥 المتصفح قد يرسل Cookie البنك تلقائيًا


---

🔥 النتيجة

السيرفر يظن:

> “الطلب من المستخدم الحقيقي”




---

🔥 لذلك ظهر SameSite


---

🔹 SameSite=Lax

يقلل بعض Cross-site requests.


---

🔹 SameSite=Strict

لا يرسل Cookie تقريبًا في Cross-site context.


---

🔥 لكن:

قد يؤثر على usability.


---

2) ⚙️ الآلية (How it works — Internal Mechanics)


---

🔹 كيف يخزن المتصفح Cookies؟

المتصفح يملك:

> Cookie Store




---

🧠 ماذا يحتوي؟

لكل Cookie:

name

value

domain

path

expiry

flags



---

🔥 عند كل Request

المتصفح:

1. يفحص الـ URL


2. يحدد الـ domain


3. يحدد الـ path


4. يقرر أي Cookies تُرسل




---

🔥 نقطة احترافية جدًا

المطور:

> لا “يرسل” Cookies يدويًا غالبًا



المتصفح:

> يفعل ذلك تلقائيًا




---

🔥 وهذا سبب خطورة CSRF


---

🔹 Cookie Tossing

الكتاب يلمّح لمشاكل cookie scope وسوء ضبط الـ domain


---

🧠 ما الفكرة؟

إذا استطاع attacker ضبط:

Set-Cookie

على subdomain…

قد يحقن Cookie تؤثر على الموقع الرئيسي.


---

💣 وهذا قد يؤدي إلى:

session confusion

auth bypass

overwriting cookies



---

3) 💣 التطبيق (Real Attack Scenarios)


---

🔥 سيناريو 1 — Session Hijacking

المهاجم يسرق:

session=abc123


---

💥 النتيجة

السيرفر يظنه:

> المستخدم الحقيقي




---

🔥 إذن:

> الجلسة = الهوية




---

🔥 سيناريو 2 — XSS + Cookie Theft

بدون HttpOnly:

document.cookie


---

💥 المهاجم:

يرسل Cookie لنفسه

يخطف الجلسة



---

🔥 سيناريو 3 — CSRF

evil.com يجعل المتصفح يرسل:

Cookies

تلقائيًا

للبنك



---

💥 السيرفر يثق بالجلسة


---

🔥 سيناريو 4 — Shared Domain Risk

Domain=.example.com


---

💣 اختراق:

blog.example.com

قد يؤدي لاختراق:

admin.example.com


---

4) 🛡️ الحماية (Defense — Deep Defensive Thinking)


---

🔐 1) استخدم Secure دائمًا


---

🔐 2) استخدم HttpOnly

لتقليل سرقة Cookies عبر XSS.


---

🔐 3) استخدم SameSite

خصوصًا ضد CSRF.


---

🔐 4) لا تشارك Cookies بين subdomains بلا داعٍ


---

🔐 5) اجعل Sessions قصيرة


---

🔐 6) Rotate Session IDs

خصوصًا بعد login.


---

🔐 7) لا تضع معلومات حساسة داخل Cookie نفسها


---

🔐 8) اربط الجلسة بسياق منطقي

مثل:

device

IP heuristics

behavior


لكن بحذر.


---

5) 🧪 التدريب العملي (Professional Labs)


---

🧪 تمرين 1 — رؤية Cookies

افتح DevTools:

Application

Cookies


راقب:

Domain

Path

Secure

HttpOnly

SameSite



---

🧪 تمرين 2 — تحليل Session Flow

سجل دخول لأي موقع تجريبي.

راقب:

متى تُنشأ Cookie

متى تُرسل



---

🧪 تمرين 3 — حذف Cookie

احذف Session Cookie.

ماذا يحدث؟


---

🧪 تمرين 4 — تحليل SameSite

راقب Requests:

هل Cookie تُرسل Cross-site؟



---

🧠 خلاصة اليوم (الفهم الحقيقي)

اليوم الرابع ليس عن:

> “ما هي Cookies”



بل عن:

> كيف يحاول الويب بناء مفهوم “الهوية والجلسة” فوق بروتوكول Stateless… ولماذا يؤدي هذا التصميم إلى كمية هائلة من الهجمات.




---

🎯 أهم فكرة في اليوم

> "في أغلب تطبيقات الويب… من يملك Session Cookie يملك هوية المستخدم."

📅 اليوم 5 — Encoding, Canonicalization & Parsing Confusion

(كيف تتحول طريقة “تفسير البيانات” إلى ثغرات خطيرة)

> اليوم الخامس من أخطر الأيام فكريًا.

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

🔥 لماذا لا تأتي كثير من الثغرات من “البيانات نفسها”…

بل من:

اختلاف تفسير البيانات بين الطبقات المختلفة

وهذا اليوم هو الأساس الحقيقي لفهم:

Filter Bypass

WAF Bypass

Path Traversal

XSS Bypass

Double Encoding

Unicode Confusion

Request Smuggling

Canonicalization Bugs


لأن كل هذه تعتمد على:

🔥 “من الذي يفسر البيانات؟ ومتى؟ وكيف؟”



الكتاب في هذا الجزء يشرح:

URL Encoding

Double Encoding

HTML Encoding

Base64

Unicode

ولماذا تؤدي عمليات فك الترميز المتعددة أو اختلاف تفسير الطبقات إلى مشاكل أمنية خطيرة



---

1) 🧠 الفهم النظري (Concept — Deep Parsing Architecture)


---

🔹 أولًا: ما هو Encoding فعلًا؟

الشرح السطحي يقول:

> “تحويل البيانات لصيغة أخرى”



لكن هذا ليس الفهم الحقيقي.


---

🔥 الفهم الحقيقي

Encoding هو:

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




---

🧠 لماذا نحتاج Encoding أصلًا؟

لأن الإنترنت لم يُصمم لكل أنواع البيانات.

HTTP والـ URLs صُممت تاريخيًا للتعامل مع:

حروف معينة

رموز معينة


لكن ماذا لو أردنا:

مسافات؟

Unicode؟

رموز HTML؟

بيانات Binary؟



---

🔥 هنا ظهر Encoding


---

🔹 مثال بسيط

المسافة:

Hello World

في URL تصبح:

Hello%20World


---

🔥 لماذا؟

لأن:

Space

له معنى خاص داخل URLs.


---

🔥 إذن Encoding ليس “أمان”

بل:

> Translation Layer




---

🔹 الآن النقطة الأخطر

كل طبقة في الويب قد:

تفك الترميز

أو تفسره

أو تعيد ترميزه


بطريقة مختلفة.


---

🔥 وهنا تبدأ الكوارث الأمنية


---

🔥 الفكرة الجوهرية لليوم كله

الثغرات كثيرًا ما تظهر لأن:

> طبقة A ترى البيانات بشكل
وطبقة B تراها بشكل مختلف.




---

🔥 وهذا يسمى:

Parsing Ambiguity

أو:

Canonicalization Problems


---

🔹 ما معنى Canonicalization؟

يعني:

> تحويل البيانات إلى “الصيغة النهائية الحقيقية” قبل معالجتها.




---

🔥 المشكلة

إذا:

الـ Filter يرى قيمة

لكن السيرفر بعد decoding يرى قيمة مختلفة


💣 انتهى الأمر.


---

🔥 مثال مهم جدًا

الفلاتر تمنع:

../

لكن المهاجم يرسل:

%2e%2e%2f


---

🔥 ماذا يحدث؟

المرحلة الأولى

الفلتر يرى:

%2e%2e%2f

ولا يكتشف:

../


---

المرحلة الثانية

السيرفر يفك الترميز:

../


---

💥 النتيجة

Path Traversal bypass.


---

🔥 إذن المشكلة ليست:

> “Encoding”



بل:

> “متى تم فك الترميز؟ ومن الذي فسره؟”




---

🔹 كيف يفكر الهاكر هنا؟

لا يسأل:

> “ما هي القيمة؟”



بل:

> “كيف تراها كل طبقة؟”




---

🔥 هذه نقطة احترافية جدًا

الهاكر يفكر:

كيف يفسرها Browser؟

كيف يفسرها Proxy؟

كيف يفسرها WAF؟

كيف يفسرها Framework؟

كيف يفسرها Backend؟



---

🔥 وإذا وجد اختلافًا:

> تبدأ bypasses




---

2) ⚙️ الآلية (How it works — Deep Parsing Mechanics)


---

🔹 URL Encoding

الكتاب يشرح:

> URL Encoding يحول الأحرف الخاصة إلى تمثيل %HEX




---

🔬 مثال

<

تصبح:

%3C


---

🔥 ماذا يحدث داخليًا؟

1️⃣ المتصفح يرسل:

%3C


---

2️⃣ السيرفر يفك الترميز:

<


---

🔥 الآن تخيل:

الفلتر يعمل:

قبل decoding


لكن التنفيذ:

بعد decoding



---

💥 bypass


---

🔹 Double Encoding

الكتاب يشرح:

> يمكن ترميز البيانات أكثر من مرة




---

🔬 مثال

<


---

الترميز الأول

%3C


---

الترميز الثاني

%253C

لأن:

%

تصبح:

%25


---

🔥 لماذا هذا مهم جدًا؟

إذا:

WAF يفك مرة واحدة

السيرفر يفك مرتين



---

💥 النتيجة

الـ WAF يرى:

%3C

لكن التطبيق يرى:

<


---

🔥 وهذا أساس كمية هائلة من bypasses


---

🔹 Unicode Encoding

الكتاب يشرح Unicode كآلية لتمثيل لغات متعددة


---

🔥 المشكلة الأمنية

بعض الحروف:

تبدو متشابهة

لكن قيمتها مختلفة



---

🔬 مثال

حرف:

/

قد يوجد Unicode يشبهه.


---

🔥 النتيجة

الفلتر لا يتعرف عليه

parser آخر يفسره كـ slash



---

💥 bypass


---

🔹 HTML Encoding

< → &lt;


---

🧠 لماذا يُستخدم؟

لمنع:

HTML injection

XSS



---

🔥 لكن المشكلة

إذا:

تم فك الترميز لاحقًا

أو تم إدخاله داخل Context مختلف



---

💥 قد يعود XSS.


---

🔹 Base64

الكتاب يوضح:

> Base64 Encoding ليس تشفيرًا




---

🔥 هذه نقطة مهمة جدًا

Base64: ❌ لا يحمي البيانات

بل: ✔ فقط يغير شكلها


---

🔥 كثير من المطورين يخطئون هنا

ويعتقدون:

Base64 == Security


---

💣 كارثة شائعة جدًا


---

3) 💣 التطبيق (Real Attack Scenarios)


---

🔥 سيناريو 1 — WAF Bypass