📅 اليوم 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

الفلتر يمنع:

<script>


---

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

%3Cscript%3E

أو:

%253Cscript%253E


---

💥 إذا اختلف decoding:

bypass



---

🔥 سيناريو 2 — Path Traversal

التطبيق يمنع:

../

المهاجم:

%2e%2e%2f


---

💥 bypass


---

🔥 سيناريو 3 — Unicode Confusion

الفلتر:

لا يرى slash الحقيقي


لكن parser:

يحوله لمسار فعلي



---

💥 bypass


---

🔥 سيناريو 4 — Base64 Misuse

المطور:

Base64(password)

ويعتقد أنه:

> “آمن”




---

💥 أي شخص يستطيع decode.


---

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


---

🔐 1) Canonicalize Before Validation

هذه أهم قاعدة اليوم.


---

🔥 يعني:

✔ فك الترميز أولًا
✔ Normalize
✔ ثم افحص


---

🔐 2) Decode Once

لا تجعل:

طبقات مختلفة

تفك بطرق مختلفة



---

🔐 3) استخدم مكتبات موثوقة

لا تكتب parsers بنفسك.


---

🔐 4) لا تعتمد على Blacklists

خصوصًا قبل canonicalization.


---

🔐 5) افهم Context

Encoding يعتمد على:

HTML context

URL context

JS context



---

🔥 وهذا مهم جدًا لاحقًا في XSS.


---

🔐 6) Base64 ≠ Encryption


---

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


---

🧪 تمرين 1 — URL Encoding

حوّل:

../

إلى URL encoded.


---

🧪 تمرين 2 — Double Encoding

حوّل:

<

إلى:

encoded مرة

encoded مرتين



---

🧪 تمرين 3 — تحليل Parsing

اسأل:

من يفك الترميز أولًا؟

هل هناك WAF؟

هل الـ proxy يختلف عن backend؟



---

🧪 تمرين 4 — Base64

جرّب:

encode

decode


وافهم أنه: ❌ ليس حماية.


---

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

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

> “أنواع الترميز”



بل عن:

> كيف تؤدي اختلافات تفسير البيانات بين الطبقات المختلفة إلى ظهور bypasses وثغرات خطيرة.




---

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

> "كثير من الثغرات ليست لأن البيانات خبيثة… بل لأن الأنظمة المختلفة تفسر نفس البيانات بطرق مختلفة."

📅 اليوم 6 — Recon Fundamentals + Subdomain Enumeration + Attack Surface Mapping

(كيف يفكر المهاجم قبل أي استغلال… وكيف يتحول “جمع المعلومات” إلى أخطر مرحلة في الاختبار)

> كثير من المبتدئين يعتقدون أن الاختراق يبدأ من:

SQL Injection

XSS

RCE


لكن المحترفين يعرفون أن:

🔥 الاختراق الحقيقي يبدأ قبل ذلك بكثير.

يبدأ من:

الفهم الكامل للهدف

وهذا اليوم هو بداية:

Recon

Enumeration

Attack Surface Discovery


وهي المرحلة التي يعتمد عليها:

Bug Bounty Hunters

Red Teams

Advanced Pentesters


لأن:

> “الثغرة التي لا تراها… لا يمكنك استغلالها.”





الكتاب في قسم Recon يشرح:

جمع المعلومات

Enumerating IPs وASN

اكتشاف الخدمات

Subdomain Enumeration

Endpoint Discovery

Attack Surface Mapping

Cloud Enumeration

وكيف يبني المهاجم صورة كاملة عن الهدف قبل أي استغلال



---

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


---

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

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

> “جمع معلومات عن الهدف”



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


---

🔥 Recon الحقيقي هو:

> بناء نموذج ذهني كامل للبنية التقنية للهدف.




---

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

المهاجم لا يرى:

موقعًا واحدًا

صفحة login

دومين واحد


بل يرى:

Infrastructure

Domains

APIs

Cloud Assets

Hidden Services

Third-party integrations

Internal architecture



---

🔥 إذن الهدف الحقيقي من Recon ليس:

> “جمع معلومات”



بل:

> “فهم كيف بُني النظام.”




---

🔹 لماذا Recon مهم جدًا؟

لأن التطبيقات الحديثة:

ضخمة جدًا

موزعة

مليئة بخدمات مخفية



---

🔥 في الواقع

الثغرات الخطيرة غالبًا: ❌ ليست في:

www.example.com

بل في:

dev-api.example.com
old-admin.example.com
staging.example.com


---

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

كلما كبر النظام:

> زادت احتمالية وجود أصل (Asset) منسي وضعيف.




---

🔹 كيف يفكر الهاكر أثناء Recon؟

لا يسأل:

> “هل يوجد XSS؟”



بل يسأل:

كم عدد الأنظمة؟

هل توجد بيئات تطوير؟

هل هناك APIs غير موثقة؟

هل توجد subdomains قديمة؟

هل توجد خدمات غير مستخدمة؟

هل يوجد Cloud Storage مكشوف؟

هل توجد تقنيات قديمة؟



---

🔥 Recon هو:

> “فن تقليل المجهول”




---

🔹 Attack Surface

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

> Attack Surface Mapping




---

🧠 ما هو Attack Surface؟

هو:

> كل نقطة يمكن للمهاجم التفاعل معها.




---

🔥 أمثلة

Web apps

APIs

Login pages

File uploads

Admin panels

Open ports

Cloud buckets

Mobile backends



---

🔥 وكل نقطة:

> احتمال ثغرة




---

🔥 إذن المحترف لا يبحث عن:

> “ثغرة”



بل:

> “أماكن محتملة للثغرات”




---

2) ⚙️ الآلية (How Recon Works — Deep Enumeration Mechanics)


---

🔹 Subdomain Enumeration

هذا من أهم أجزاء Recon.


---

🧠 لماذا؟

لأن الشركات لا تملك:

example.com

فقط.

بل:

api.example.com
dev.example.com
vpn.example.com
mail.example.com
staging.example.com


---

🔥 وبعضها:

قديم

منسي

غير مؤمن



---

🔥 لماذا تظهر هذه الأنظمة؟

لأن فرق التطوير:

تبني

تختبر

تنسى الإزالة



---

🔹 كيف يتم اكتشافها؟


---

🧩 1️⃣ DNS Enumeration

المهاجم يسأل DNS:

> ما هي الأسماء المرتبطة بالدومين؟




---

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

لأن DNS:

> خريطة الإنترنت




---

🧩 2️⃣ Certificate Transparency Logs

عندما يصدر SSL Certificate…

غالبًا يتم تسجيله علنًا.


---

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

إذا أصدرت الشركة شهادة لـ:

admin-dev.example.com

قد يستطيع المهاجم رؤيتها.


---

🔥 إذن حتى الأنظمة “المخفية”

قد تُكشف بسبب الشهادات.


---

🧩 3️⃣ Search Engines

Google أحيانًا يفهرس:

staging pages

backups

APIs



---

🧩 4️⃣ Passive Sources

مثل:

VirusTotal

Shodan

Historical DNS



---

🔥 هذه تعطي:

> صورة تاريخية للبنية




---

🔹 Port Scanning

الكتاب يشرح:

> اكتشاف الخدمات والمنافذ جزء أساسي من Recon




---

🧠 ما هو Port فعليًا؟

Port:

> “باب منطقي” لخدمة معينة.




---

🔥 مثال

Port Service

80 HTTP
443 HTTPS
22 SSH
3306 MySQL



---

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

لأن:

> كل خدمة = كود إضافي = احتمال ثغرة إضافية




---

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

المهاجم لا يبحث فقط:

> “هل المنفذ مفتوح؟”



بل:

ما الإصدار؟

ما التقنية؟

هل قديمة؟

هل misconfigured؟



---

🔹 Fingerprinting

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

headers

errors

response patterns



---

🔥 ومنها يستطيع المهاجم معرفة:

Apache

Nginx

PHP

Express

Django



---

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

لأن:

> كل تقنية لها ثغرات معروفة.




---

🔹 Endpoint Discovery

التطبيقات الحديثة:

SPA

APIs

Mobile Backends

---

🔥 لذلك endpoints كثيرة:

مخفية

غير موثقة

قديمة



---

🔥 المهاجم يحاول:

استخراج routes

قراءة JS files

تحليل requests



---

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


---

🔥 سيناريو 1 — Forgotten Subdomain

الشركة تؤمن:

www.example.com

لكن يوجد:

old-admin.example.com


---

💣 النظام قديم وغير محدث


---

💥 المهاجم يخترقه

ثم يتحرك داخليًا.


---

🔥 سيناريو 2 — Exposed Dev Environment

dev-api.example.com


---

💣 غالبًا:

debugging enabled

weak auth

test credentials



---

🔥 سيناريو 3 — Open Port

22/tcp open SSH


---

💣 إذا كان:

weak password

outdated version



---

💥 نقطة دخول.


---

🔥 سيناريو 4 — JS File Disclosure

ملف JS يحتوي:

const API = "https://internal-api.example.com"


---

💥 endpoint مخفي انكشف.


---

🔥 سيناريو 5 — Cloud Storage Exposure

Bucket منسي:

backup.example.com


---

💥 يحتوي:

backups

credentials

source code



---

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


---

🔐 1) Asset Management

أهم شيء:

> اعرف ماذا تملك.




---

🔥 كثير من الاختراقات تحدث لأن:

الشركة نسيت أصلًا قديمًا.



---

🔐 2) إزالة الأنظمة القديمة

staging

backups

test systems



---

🔐 3) لا تكشف معلومات زائدة

banners

versions

debug messages



---

🔐 4) راقب Certificate Transparency

حتى تعرف:

ماذا انكشف للعالم



---

🔐 5) Hardening لكل الخدمات

حتى “الداخلية”.


---

🔐 6) لا تضع Secrets داخل JS


---

🔐 7) استخدم Segmentation

اختراق نظام ثانوي: ❌ لا يجب أن يعطي وصولًا كاملًا.


---

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


---

🧪 تمرين 1 — تحليل Attack Surface

اختر موقعًا كبيرًا.

اسأل:

كم subdomain؟

كم خدمة؟

هل يوجد APIs؟



---

🧪 تمرين 2 — DevTools Recon

راقب:

JS files

API calls

hidden endpoints



---

🧪 تمرين 3 — Fingerprinting

افحص:

headers

technologies

response patterns



---

🧪 تمرين 4 — Architecture Thinking

حاول رسم:

frontend

backend

APIs

auth flow



---

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

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

> “جمع معلومات”



بل عن:

> فهم البنية الحقيقية للنظام، واكتشاف الأجزاء التي لم تُصمم لتكون مرئية أصلًا.




---

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

> "في الاختبارات الحقيقية… الثغرة غالبًا لا تكون في النظام الذي تراه، بل في النظام الذي نسيه الجميع."

📅 اليوم 7 — Port Scanning + Service Enumeration + Fingerprinting

(كيف يرى المهاجم “الخدمات الحقيقية” خلف الموقع… وكيف تتحول المنافذ إلى خريطة اختراق كاملة)

> في اليوم السادس فهمنا:

Recon

Attack Surface

Subdomains


لكن اليوم سننزل أعمق.

لأن الموقع الذي تراه: ❌ ليس النظام الحقيقي.

خلفه توجد:

Services

Daemons

Admin Interfaces

Databases

SSH

Internal APIs

Monitoring Systems


واليوم ستتعلم:

🔥 كيف يكتشف المهاجم هذه الخدمات 🔥 وكيف يبني صورة داخلية للبنية التقنية

قبل أي استغلال فعلي.



الكتاب في قسم Recon يشرح:

Port Scanning

Service Enumeration

Banner Grabbing

Fingerprinting

اكتشاف التقنيات والخدمات والإصدارات



---

1) 🧠 الفهم النظري (Concept — كيف يرى المهاجم النظام؟)


---

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

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

> “رقم لخدمة”



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


---

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

Port هو:

> نقطة دخول منطقية (Logical Entry Point) لخدمة تعمل داخل النظام.




---

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

السيرفر قد يشغّل:

Web Server

SSH

Database

Mail Service

API Gateway


كلها على نفس الـ IP.


---

🔥 كيف يفرق النظام بينها؟

عبر:

Ports


---

🔥 مثال

Service Port

HTTP 80
HTTPS 443
SSH 22
MySQL 3306
Redis 6379



---

🔥 إذن عندما يفحص المهاجم المنافذ…

هو فعليًا يسأل:

> “ما الذي يعمل داخل هذا الجهاز؟”




---

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

لأن:

> كل Service = كود إضافي



وكل كود إضافي:

> احتمال ثغرات إضافية




---

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

المهاجم لا يبحث فقط:

> “هل المنفذ مفتوح؟”



بل:

ما نوع الخدمة؟

ما الإصدار؟

هل هناك misconfiguration؟

هل توجد واجهات إدارية؟

هل الخدمة داخلية لكنها مكشوفة؟

هل النسخة قديمة؟

هل الـ banner يكشف معلومات؟



---

🔹 الفرق بين Website وInfrastructure

المبتدئ يرى:

example.com

المحترف يرى:

Reverse Proxy

CDN

Load Balancer

Web Server

Backend Services

Internal APIs

Databases

Monitoring

SSH Access



---

🔥 إذن Port Scanning هو:

> محاولة رؤية “البنية الحقيقية” خلف الموقع.




---

🔹 لماذا كثير من الاختراقات تبدأ من Service وليس Web App؟

لأن:

الخدمات تُنسى

التحديثات تتأخر

الـ configs تكون سيئة

بعض الخدمات لم تُصمم للإنترنت أصلًا



---

🔥 أمثلة حقيقية

Redis مفتوح بدون Password

MongoDB مكشوف

Jenkins admin panel

Kibana exposed

Elasticsearch open

Docker API exposed



---

💣 وهذه ليست “ثغرات برمجية”

بل:

> أخطاء بنيوية في البنية التحتية




---

2) ⚙️ الآلية (How Port Scanning Works — Deep Network Mechanics)


---

🔹 كيف يعرف المهاجم أن Port مفتوح؟

لفهم هذا يجب فهم:

> TCP Handshake




---

🔥 تذكير سريع

TCP يعمل عبر:

SYN → SYN/ACK → ACK


---

🔹 ماذا يحدث أثناء Port Scan؟

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

SYN

إلى Port معين.


---

🔥 إذا رد السيرفر:

SYN/ACK

فهذا يعني:

> يوجد Service يستمع على هذا Port




---

🔥 إذا رد:

RST

فغالبًا:

> المنفذ مغلق




---

🔹 لماذا هذا مهم؟

لأن:

> مجرد الرد يكشف معلومات




---

🔹 Service Enumeration

بعد معرفة أن Port مفتوح…

المهاجم يريد معرفة:

> ما الخدمة؟




---

🔥 كيف؟

عبر:

Banners

Response Patterns

Protocol Behavior



---

🔹 Banner Grabbing

الكتاب يشرح فكرة:

> اكتشاف معلومات الخدمة من الردود والبنرات




---

🔬 مثال

السيرفر يرد:

SSH-2.0-OpenSSH_7.2p2


---

🔥 ماذا تعني هذه الجملة؟

ليست مجرد “ترحيب”.

بل:

نوع الخدمة

الإصدار

أحيانًا النظام



---

🔥 الآن يبدأ التفكير الهجومي

المهاجم يسأل:

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

هل له CVE؟

هل توجد Misconfigurations معروفة؟



---

🔹 Fingerprinting

حتى لو أخفى السيرفر الـ banner…

ما زال يمكن:

> استنتاج التقنية من السلوك.




---

🔥 كيف؟

مثلًا:

طريقة الرد

ترتيب الـ headers

أخطاء محددة

TLS behavior

response timing



---

🔥 وهذه تسمى:

Passive Fingerprinting


---

🔹 Web Fingerprinting

المهاجم يحاول معرفة:

Apache؟

Nginx؟

IIS؟

Express؟

Django؟

PHP؟

Node.js؟



---

🔥 لماذا؟

لأن:

> كل تقنية لها:



Weaknesses

CVEs

Misconfigurations



---

🔹 لماذا Version Detection مهم جدًا؟

لأن:

Apache 2.4.41

ليست مثل:

Apache 2.2


---

🔥 بعض الإصدارات:

قديمة

vulnerable

EOL



---

🔹 Internal vs External Services

أحيانًا الخدمة:

> لم تُصمم أصلًا للإنترنت



لكن تم كشفها بالخطأ.


---

💣 مثال

Redis 6379 open

Redis قد يسمح:

remote commands

data access



---

💥 لأن المطور افترض:

> “الخدمة داخلية”




---

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


---

🔥 سيناريو 1 — Exposed SSH

22/tcp open OpenSSH 7.2


---

💣 ماذا يفعل المهاجم؟

يبحث عن CVEs

يحاول weak credentials

يحلل الـ config



---

🔥 سيناريو 2 — Exposed Database

3306/tcp MySQL


---

💣 إذا لا توجد حماية:

data exposure

auth bypass

remote access



---

🔥 سيناريو 3 — Jenkins Panel

8080 Jenkins


---

💣 قد يسمح:

code execution

credential leakage



---

🔥 سيناريو 4 — Elasticsearch Open

9200 Elasticsearch


---

💥 قد يكشف:

logs

credentials

customer data



---

🔥 سيناريو 5 — Fingerprinting via Headers

Server: nginx/1.14


---

💣 الهاكر:

يبحث عن known exploits



---

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


---

🔐 1) Principle of Least Exposure

لا تكشف:

إلا ما تحتاجه فقط



---

🔐 2) أغلق الخدمات غير الضرورية


---

🔐 3) لا تترك الخدمات الداخلية مكشوفة

مثل:

Redis

MongoDB

Docker API



---

🔐 4) Hardening

strong auth

firewall

segmentation



---

🔐 5) Banner Reduction

قلل:

version disclosure

tech disclosure



---

🔐 6) Patch Management

حدّث الخدمات باستمرار.


---

🔐 7) Network Segmentation

اختراق Service: ❌ لا يجب أن يعطي الشبكة كلها.


---

🔐 8) Monitoring

راقب:

scans

unusual probes

recon activity



---

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


---

🧪 تمرين 1 — Fingerprinting Thinking

افتح أي موقع.

راقب:

headers

TLS

response patterns



---

🧪 تمرين 2 — Service Mapping

حاول رسم:

frontend

backend

reverse proxy

APIs



---

🧪 تمرين 3 — Banner Analysis

ابحث عن:

version disclosure

technology leakage



---

🧪 تمرين 4 — Attack Surface Thinking

اسأل:

ما الخدمات المحتملة خلف هذا الموقع؟

هل توجد admin interfaces؟

هل توجد internal APIs؟



---

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

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

> “فحص منافذ”



بل عن:

> رؤية البنية الحقيقية للنظام، والخدمات التي لم يكن المقصود أن يراها المستخدم أصلًا.




---

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

> "الموقع الذي تراه مجرد واجهة… أما الهجوم الحقيقي فيبدأ عندما ترى الخدمات التي خلفه."

📅 اليوم 8 — XSS (Cross-Site Scripting) — الجزء الأول

(كيف يتحول المتصفح إلى منفذ لكود المهاجم… ولماذا تعتبر XSS من أخطر ثغرات الويب)

> اليوم ندخل أول “ثغرة حقيقية” في الخطة.

لكن لفهم XSS بشكل احترافي… يجب أن تنسى الشرح السطحي:

> “حقن JavaScript”



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

XSS في العمق هي:

كسر نموذج الثقة الخاص بالمتصفح

وإقناع المتصفح أن:

> “كود المهاجم جزء موثوق من الموقع”





وهذا اليوم يعتمد مباشرة على:

HTTP

Browser Security Model

SOP

Cookies

Parsing

Encoding


التي درسناها سابقًا.

الكتاب يشرح XSS ضمن سياق:

Browser parsing

DOM interaction

Context handling

Trust boundaries

وكيف يؤدي خلط البيانات غير الموثوقة مع HTML/JS إلى تنفيذ كود داخل Origin موثوق



---

1) 🧠 الفهم النظري (Concept — What XSS REALLY Is)


---

🔹 أولًا: ما معنى “Cross-Site Scripting”؟

الاسم تاريخيًا مضلل قليلًا.

قديمًا كانت الفكرة:

> حقن Script من “موقع” داخل موقع آخر.



لكن اليوم: XSS لا يتعلق فقط بالـ Script.

بل يتعلق بـ:

> كسر حدود الثقة داخل المتصفح.




---

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

المتصفح يثق بأي JavaScript يأتي من:

bank.com

لأن SOP تعتبره:

> Same Origin Trusted Code




---

💣 المشكلة

إذا استطاع المهاجم جعل الموقع نفسه يرسل:

<script>ATTACKER CODE</script>

فإن المتصفح سيشغله:

> بنفس صلاحيات الموقع الحقيقي.




---

🔥 إذن XSS ليس:

> “تشغيل JavaScript”



بل:

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




---

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

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

“نية” الكود

من كتبه


بل يعرف فقط:

> من أي Origin جاء.




---

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

لأنها تعمل:

> داخل الحدود الموثوقة للموقع




---

🔥 لذلك XSS تستطيع:

✔ قراءة DOM
✔ سرقة Tokens
✔ إرسال Requests
✔ تنفيذ Actions
✔ قراءة بيانات حساسة
✔ التحكم بالواجهة
✔ استغلال Session المستخدم


---

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

XSS غالبًا: ❌ لا “تكسر” السيرفر

بل: ✔ تستغل ثقة المتصفح


---

🔹 لماذا تظهر XSS أصلًا؟

السبب الجوهري:

> خلط البيانات غير الموثوقة مع HTML/JavaScript بدون معالجة صحيحة.




---

🔥 بمعنى آخر

التطبيق يأخذ:

User Input

ثم يضعه داخل:

HTML

JavaScript

Attributes

DOM


بدون:

Encoding صحيح

Sanitization صحيح

Context awareness



---

🔥 هنا يبدأ المتصفح بتفسير البيانات:

> ككود




---

🔹 Parsing Problem

XSS ليست “ثغرة JavaScript” فقط.

بل:

> مشكلة Parsing وتفسير Context.




---

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

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

HTML Parser

JS Parser

CSS Parser



---

💣 وإذا استطعت الخروج من Context معين…

يمكنك إدخال Context جديد.


---

🔥 مثال

التطبيق:

<input value="USER_INPUT">

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

"><script>alert(1)</script>


---

🔥 ماذا يحدث؟

الـ HTML parser يرى:

<input value="">
<script>alert(1)</script>


---

💥 الآن:

خرجنا من attribute

دخلنا HTML context

ثم JavaScript context



---

🔥 إذن XSS كثيرًا ما تكون:

> Context Escape




---

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

المبتدئ:

> “أريد alert(1)”



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

ما الـ Context الحالي؟

كيف يفسر المتصفح هذه البيانات؟

هل أنا داخل HTML؟

Attribute؟

JavaScript؟

URL؟

DOM؟

هل يوجد encoding؟

هل أستطيع كسر الـ parser؟



---

🔥 XSS الحقيقية ليست:

> payloads



بل:

> فهم Parsing Rules




---

2) ⚙️ الآلية (How XSS Works — Deep Browser Parsing Mechanics)


---

🔹 كيف يفسر المتصفح الصفحة؟

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

Raw Text

بل يبدأ:

Parsing

Tokenization

DOM Construction



---

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

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

أين يبدأ Tag؟

أين ينتهي؟

هل هذا Attribute؟

هل هذا Script؟

هل هذا نص عادي؟



---

🔥 لذلك:

> تغيير صغير جدًا قد يغيّر التفسير بالكامل.




---

🔹 السيناريو الأساسي لـ XSS


---

🧩 المرحلة 1 — إدخال المستخدم

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

<script>alert(1)</script>


---

🧩 المرحلة 2 — التطبيق يعيده داخل الصفحة

بدون encoding:

<div>
<script>alert(1)</script>
</div>


---

🧩 المرحلة 3 — Browser Parsing

الـ HTML parser يرى:

> Tag Script حقيقي




---

🧩 المرحلة 4 — JavaScript Engine

ينفذ:

alert(1)


---

💥 انتهت اللعبة.


---

🔹 لماذا SOP تجعل XSS خطيرة جدًا؟

لأن الكود يعمل داخل:

trusted origin


---

🔥 إذن JavaScript المهاجم يحصل على:

✔ نفس الصلاحيات
✔ نفس Cookies
✔ نفس DOM access
✔ نفس Session context


---

🔥 لذلك:

> XSS = Trust Boundary Violation




---

🔹 Stored vs Reflected (بفهم معماري)


---

🔥 Reflected XSS

البيانات: