مقدمة عن الـ Requests والـ Origin

دلوقتى لما بتيجى تتصفح اى موقع ع النت او تطلب منه يعمل حاجه معينه او تستخدم Function معينه بيتم ده عن طريق Request بيتبعت للموقع ولازم يوافق على الـ Request ده عشان يبعتلك Response باللى انت عايزه.

طيب هو بيقبل الـ Request ده بناءا على ايه اصلا ؟

فى حالتنا دى وفى موضعنا عن CORS هو بيقبله او يرفضه بناءا على الـ Origin اللى اتبعت منه الطلب.

ما هو الـ CORS؟

هنا بقا يجى دور الـ CORS “Cross-Origin Resource Sharing”.

اللى من اسمها كده نقدر نقول هى اللى بتسمح او تمنع استقبال الـ Request من الدومينات المختلفه.

ولو تم ضبط اعدادات الـ CORS بشكل خاطئ يحصل هنا بقا ما يعرف بـ CORS Misconfiguration Attack.

كيفية استغلال الـ Misconfiguration من الـ Attackers (خطوة بخطوة)

طيب خلينا نقول ازاى الـ Misconfiguration بيستغل من الـ Attackers ونقسمها خطوات:

1. اللينك بيتبعت من الـ Attacker الـى الـ Victim.
2. الـ Victim هيفتح الرابط يقوم الـ Browser ينفذ كود الـ JS الضار اللى موجود جوا اللينك.
3. الكود ده وظيفته انه بيبعت Request للموقع المصاب بالمشكله دى وبناءا عليه الموقع بيقبل الطلب عادى ومبيرفضوش بالرغم انه جاى من دومين خارجى بتاع الـ Attacker.
4. هنا بقا الـ Attacker يقدر يوصل للى هو عايزه ايا كانن هو ايه، زى مثلا:
   • الـ Session Tokens, Cookies
   • اسم، عنوان، رقم موبايل الضحيه
   • ممكن يوصل لمعلومات عن الـ Credit Card وغيرها كتير

طيب كده عرفنا ايه هو الـ CORS وايه اللى ممكن يحصل لو فى Misconfiguration.

ما هي قاعدة الـ SOP (Same-Origin Policy)؟

نيجى بقا للـ Misconfiguration نفسها ازاى بتتم ؟

الموضوع كله بيبدأ لما الديفيلوبر يكون شغال على API أو ويب سيرفر وعايز يسمح لمواقع تانية إنها تبعت Requests للسيرفر بتاعه. هنا بقى لازم يحدد مين اللي مسموح له يطلب بيانات من السيرفر ومين لأ.

خلينا نقف هنا كده شوية ونفهم هو لو اصلا مزبطش الـ CORS دى وساب الـ Response بالوضع الافتراضى بتاعه ايه اللى بيتم او ايه اللى بيحصل مع الـ Request.

عندنا حاجه اسمها SOP وده اختصار لــ Same-Origin Policy، اللى اصلا الـمتصفح بيطبقها بشكل افتراضى لو مفيش اعدادت للـ CORS.

ودى قاعدة أمنية افتراضية في المتصفحات، وظيفتها إنها تمنع أي موقع من الوصول لبيانات موقع آخر لو مش من نفس الـ Origin.

والقاعده دى ليها شروط لازم تتطبق على الاتنين Origin اللى مبعوت منه الـ Request واللى بيستقبله:

• يكونو متتطابقين فى البروتوكول “HTTP, HTTPS”
• يكونو متتطابقين فى الدومين
• يكونو متتطابقين فى البورت اللى مفتوح عليه الدومين هتقولى مهو لو HTTP هيكون البورت 80 ولو HTTPS هيكون البورت 443 .. كلامك صح بس ده الوضوع الافتراضى للبورتات وممكن عادى تغير البورتات دى زى ما تحب “ابحث لو عايز تفهم اكتر”

كيف تحدث الـ Misconfiguration؟

نرجع بقا لموضوعنا الـ Misconfiguration.

بعض الديفيلوبرز عشان يريح دماغه، أو عشان يخلّي الموضوع شغال بسرعة أثناء التطوير، بيكتب حاجة زي كده في السيرفر:

Access-Control-Allow-Origin: *

ده معناه إن أي موقع في الدنيا يقدر يبعت Request للسيرفر وياخد منه Response عادي جدا وده غلط طبعا.

او انه بدال ما يكتب * يعمل حاجة تانية: يقرا الـ Origin اللي جاي في الطلب ويرجعه هو هو في الـ Response (عشان يسهل على نفسه بدل ما يعمل Whitelist)، فتقوم الدومينات الخارجية تبعت الطلب والسيرفر يرجع كود زي كده:

Access-Control-Allow-Origin: [https://attacker.com](https://attacker.com)
Access-Control-Allow-Credentials: true

وهنا بقى مش بس بيسمح للدومين الخارجي ده إنه يبعت للسيرفر ويقرأ الـ Response، لاء ده كمان بيسمح للكوكيز والـ Credentials إنها تروح مع الطلب عادي!

يعني لو حد فاتح الأكونت بتاعه على الموقع اللي فيه المشكلة ده واتبعتله لينك وداس عليه، كود الـ JS هينفذ الطلب مع وجود الكوكيز بتاعته ويقرأ البيانات بصلاحياته هو.

فالأخطاء دي بتفتح باب للهجمات وتسمح للمهاجمين بسرقة بيانات المستخدمين بسهولة.

عشان كده، لازم دايمًا يتم ضبط إعدادات CORS بدقة اكتر من كده.

📌 ملخص سريع