مجتمع أكتب كود

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

لو عندك متجر إلكتروني بيستقبل 100 أوردر يوميًا بنظام الدفع عند الاستلام (COD)، فممكن تكون بتخسر عشرات الآلاف من الجنيهات كل شهر بسبب طلبات العملاء اللي بيرفضوا الاستلام.
المشكلة مش بس في تكلفة الشحن والمرتجعات. الأخطر إنك ممكن تكون بتبعت بيانات شراء غير دقيقة لإعلانات Meta، وده بيخلي تقييم أداء حملاتك الإعلانية بعيد عن المبيعات اللي حققتها فعلًا.
خلينا نحسب الخسارة بالأرقام، ونشوف إزاي تقدر تقللها من غير ما تزود ميزانية الإعلانات.

---

💸 إزاي متجر بيستقبل 100 أوردر يوميًا ممكن يخسر أكتر من 200 ألف جنيه شهريًا؟​

هنفترض إن عندك متجر إلكتروني بالأرقام دي:

• عدد الطلبات اليومية: 100 أوردر.
• نسبة رفض الاستلام: 30%.
• عدد الطلبات المرفوضة: 30 أوردر يوميًا.
• متوسط تكلفة الشحن والمرتجع للطلب: 100 جنيه.
• متوسط تكلفة الحصول على طلب (CPP): 150 جنيه.

أولًا: خسائر الشحن والمرتجعات
30 أوردر مرفوض × 100 جنيه = 3,000 جنيه يوميًا.
يعني خلال 30 يوم:
90,000 جنيه خسائر شحن فقط!
ثانيًا: تكلفة الإعلانات المرتبطة بالطلبات المرفوضة
30 أوردر × 150 جنيه = 4,500 جنيه يوميًا.
يعني 135,000 جنيه شهريًا من تكلفة اكتساب الطلبات اللي لم تتحول لمبيعات فعلية.
إجمالي التكلفة المرتبطة بالطلبات المرفوضة:
90,000 + 135,000 = 225,000 جنيه شهريًا.
وده مثال افتراضي بافتراض ثبات الأرقام طوال الشهر، وإن تكلفة الحصول على الطلب متساوية في المتوسط بين الطلبات المقبولة والمرفوضة.
والرقم ده لسه مش شامل:

• 📦 المنتجات اللي بترجع مفتوحة أو تالفة.
• تكلفة موظفين خدمة العملاء وتأكيد الطلبات.
• المخزون المحجوز عند شركة الشحن.
• مصاريف التغليف والتجهيز.
• فرص البيع اللي بتضيع بسبب عدم توفر المنتج في المخزن.

مهم تعرف إن تكلفة الإعلان هنا مش بالضرورة فلوس كان ممكن تستردها بالكامل، لكنها بتوضح حجم الإنفاق المرتبط بطلبات لم تحقق إيرادًا فعليًا.

---

🎯 المشكلة الأكبر: هل إعلانات Meta بتتعلم من العملاء الغلط؟​

هنا بنوصل لجزء مهم جدًا ممكن أصحاب المتاجر الإلكترونية ميكونوش واخدين بالهم منه.
لما العميل يدخل متجرك ويعمل أوردر، غالبًا بيتم إرسال حدث Purchase إلى Meta Pixel أو Conversions API بمجرد إتمام الطلب.
لكن في حالة الدفع عند الاستلام، إتمام الطلب مش معناه إن العميل دفع فعلًا.
ممكن العميل:

• يعمل أوردر وميردش على مكالمة التأكيد.
• يأكد الطلب وبعدها يغير رأيه.
• يرفض استلام الشحنة.
• يكتب عنوان غير صحيح.
• يستلم المنتج ويرجعه بعد كده.

ومع ذلك، لو إعدادات التتبع عندك بتسجل Purchase بمجرد إنشاء الطلب، فالحدث بيكون اتبعت بالفعل.
إيه المشكلة في كده؟
لو حملتك بتستخدم حدث Purchase كهدف للتحسين، Meta ممكن تعتمد على الإشارات دي في تحسين عرض الإعلانات.
وبالتالي، أنت بتقيس نجاح الحملة بناءً على أشخاص عملوا أوردر، مش بالضرورة أشخاص استلموا ودفعوا.
وده ممكن يخلي خوارزمية الإعلانات تتحسن تجاه هدف مختلف عن هدفك التجاري الحقيقي.
مش معنى كده إن Meta بتستهدف عمدًا العملاء اللي بيرفضوا الاستلام، لكن جودة البيانات اللي بتبعتها بتأثر على جودة إشارات التحسين وقراءة النتائج.

---

📊 إزاي تعرف إن عندك مشكلة في تتبع مبيعات COD؟​

أول حاجة لازم تعملها هي مقارنة عدد عمليات الشراء المسجلة في Ads Manager بعدد الطلبات اللي اتسلمت واتدفعت بالفعل.
خلينا نفترض إن تقرير الشهر عندك بالشكل ده:
في المثال ده، عدد عمليات الشراء المسجلة في Meta أعلى من المبيعات الفعلية بنسبة واضحة.
لكن خلي بالك: المقارنة دي مؤشر مبدئي، مش دليل قاطع إن كل الفرق سببه رفض الاستلام.
لازم تراعي كمان اختلاف فترات الإسناد الإعلاني (Attribution)، وتأخر تسليم الطلبات، واحتمال تكرار أحداث التتبع أو وجود مبيعات من مصادر تانية.
الأفضل إنك تتابع 3 أرقام بشكل منفصل:

1. عدد الطلبات الجديدة.
2. عدد الطلبات المؤكدة.
3. عدد الطلبات المستلمة والمدفوعة.

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

---

🛠️ إزاي تقلل خسائر الدفع عند الاستلام في 3 خطوات؟​

الحل مش بالضرورة إنك تعمل Campaign جديدة أو تزود ميزانية الإعلانات.
الأهم إنك تحسن دورة الطلب بالكامل، من لحظة تسجيل الأوردر لحد ما العميل يستلم ويدفع.

1. أكد الأوردر أوتوماتيك على WhatsApp قبل الشحن​

متشحنش كل أوردر بمجرد وصوله للمتجر.
اعمل نظام تأكيد تلقائي باستخدام WhatsApp Business Platform أو إحدى خدمات الربط المعتمدة.
مثلًا، بمجرد ما العميل يعمل أوردر، توصله رسالة:
أهلًا بيك 👋
شكرًا لطلبك من متجرنا.
طلبك رقم #1250 بإجمالي 850 جنيه.
من فضلك أكد إنك جاهز لاستلام الطلب على العنوان المسجل.
هل تحب نبدأ تجهيز الشحنة؟
ويكون قدامه اختيارين:

• تأكيد الطلب.
• تعديل أو إلغاء الطلب.

الخطوة دي بتساعدك تكتشف جزء من الطلبات غير الجادة قبل ما تتحمل تكلفة الشحن.
لكن متعتبرش عدم الرد رفضًا نهائيًا؛ ممكن تعمل محاولة متابعة إضافية قبل إلغاء الطلب وفق سياسة واضحة.

2. ابعت بيانات المبيعات الفعلية إلى Meta باستخدام Conversions API​

دي من أهم الخطوات لتحسين جودة قياس أداء إعلانات الدفع عند الاستلام.
بدل ما تعتمد على عدد الطلبات الجديدة فقط، اربط نظام إدارة الطلبات (OMS) أو المتجر بحالة الشحن والتسليم.
لما شركة الشحن تأكد إن العميل استلم ودفع، تقدر تبعت إشارة مناسبة إلى Meta باستخدام Conversions API، حسب تصميم التتبع عندك.
لكن فيه نقطة تقنية مهمة:
متبعتش حدث Purchase مرة عند إنشاء الطلب ومرة تانية عند التسليم على إنهم عمليتا شراء مختلفتان.
لازم تحدد استراتيجية واضحة للتتبع، وتمنع تكرار احتساب نفس العملية باستخدام آلية Deduplication عند إرسال نفس الحدث من المتصفح والسيرفر.
ولو هتعتمد على تسجيل الشراء عند التسليم فقط، لازم تراعي تأخر وصول الحدث، ومتطلبات توقيت الأحداث في Meta، وتأثير ده على الإسناد والتحسين.
ممكن كمان تستخدم حدثًا مخصصًا لتمييز الطلبات المستلمة والمدفوعة، وتراجع مدى إتاحته كهدف للتحسين داخل حسابك.
الهدف الأساسي: إنك تفرق بين مجرد إنشاء أوردر وبين عملية بيع حققت إيرادًا فعليًا، وتستخدم البيانات المناسبة لكل تقرير أو حملة.

3. اعمل نظام لمتابعة العملاء اللي بيرفضوا الاستلام​

مش كل عميل بيرفض الاستلام يبقى عميل غير جاد.
ممكن يكون السبب تأخر الشحن، أو مشكلة في المنتج، أو خطأ من شركة التوصيل.
لكن لو نفس العميل بيرفض الاستلام بشكل متكرر ومن غير سبب واضح، لازم يكون عندك إجراء يقلل احتمالية تكرار الخسارة.
تقدر تعمل الآتي:

• تسجيل حالات رفض الاستلام وأسبابها داخل نظام إدارة الطلبات.
• مراجعة سجل الطلبات السابقة قبل تجهيز شحنة جديدة.
• طلب تأكيد إضافي للعملاء أصحاب حالات الرفض المتكررة.
• إتاحة الدفع المسبق كاختيار مناسب لبعض الحالات.
• تحديث بيانات العملاء بشكل آمن ومنع الوصول غير المصرح به إليها.

ومتعتمدش على رقم الموبايل وحده للحظر التلقائي؛ الأرقام ممكن تتغير أو تنتقل لأشخاص تانيين.
كمان لازم تراعي قوانين حماية البيانات وسياسة الخصوصية عند الاحتفاظ ببيانات العملاء أو استخدامها في الاستهداف الإعلاني.

---

📈 إيه المؤشرات اللي لازم تتابعها بدل عدد الأوردرات فقط؟​

لو عايز تعرف هل متجرك بيحقق أرباح فعلًا، متخليش عدد الطلبات الجديدة هو المؤشر الوحيد لنجاحك.
تابع المؤشرات دي باستمرار:
مثال عملي:
لو صرفت 15,000 جنيه إعلانات وجالك 100 أوردر، يبقى تكلفة الحصول على الطلب 150 جنيه.
لكن لو 70 أوردر بس اتسلموا واتدفعوا، يبقى تكلفة الإعلان لكل طلب مستلم:
15,000 ÷ 70 = 214.29 جنيه تقريبًا.
يعني تكلفة اكتساب البيع الفعلي أعلى بكتير من الرقم اللي ممكن تكون بتبص عليه في تقرير الطلبات الجديدة.
وده قبل حساب تكلفة المنتج والشحن والعمولات وباقي المصاريف.

---

❓ الأسئلة الشائعة​

-----------------
هل الدفع عند الاستلام (COD) بيزود المرتجعات؟
ممكن يزود احتمالية رفض الاستلام مقارنة ببعض نماذج الدفع المسبق، لكن النتيجة بتختلف حسب نوع المنتج والسوق وسرعة التوصيل وجودة تأكيد الطلبات.
هل الأفضل ألغي الدفع عند الاستلام من المتجر؟
مش بالضرورة. الدفع عند الاستلام ممكن يكون وسيلة مهمة لزيادة ثقة العملاء، خصوصًا في الأسواق اللي لسه فيها اعتماد كبير على الدفع النقدي. الأفضل تقيس ربحيته وتحسن عملية التأكيد والشحن قبل اتخاذ قرار بإلغائه.
هل Conversions API بيمنع خسائر الطلبات المرفوضة؟
لا. هو بيساعدك تبعت بيانات الأحداث من السيرفر إلى Meta، لكن تقليل الخسائر محتاج كمان تحسين تأكيد الطلبات، وإدارة الشحن، ومتابعة أسباب رفض الاستلام.

---

الخلاصة​

لو متجرك بيعتمد على الدفع عند الاستلام، متقيسش نجاح الإعلانات بعدد الناس اللي ضغطت على زر تأكيد الطلب فقط.
الأهم هو عدد العملاء اللي استلموا ودفعوا، والتكلفة الحقيقية للحصول على كل عملية بيع ناجحة.
ابدأ بمراجعة الفرق بين الطلبات المسجلة والمبيعات الفعلية، وبعدها حسّن تأكيد الطلبات على WhatsApp، واضبط تتبع التحويلات في Meta، وراجع أسباب رفض الاستلام باستمرار.
ممكن تكتشف إن تحسين العمليات الحالية أوفر وأنفع من زيادة ميزانية الإعلانات.

واقعة اختراق شاشة إعلانية على محور 26 يوليو في اتجاه مدينة 6 أكتوبر، وعرض محتوى إباحي عليها، أثارت تساؤلات مهمة عن مدى أمان شاشات الإعلانات الرقمية، وإزاي ممكن شخص يتحكم في شاشة موجودة في الشارع ويغيّر المحتوى المعروض عليها من غير تصريح.

لكن السؤال الأهم هنا: هل المخترق محتاج يوصل للشاشة بنفسه، ولا ممكن يتحكم فيها عن بُعد من خلال الإنترنت؟

الإجابة إن شاشات الإعلانات الحديثة مش مجرد شاشة بتعرض صور وفيديوهات. في حالات كتير، بتكون جزء من نظام رقمي متكامل، متصل بسيرفرات وبرمجيات بتسمح بإدارة عشرات أو حتى مئات الشاشات من مكان واحد.

وده بيخلي تأمين أنظمة الإدارة بنفس أهمية تأمين الشاشة نفسها.

تنويه: التفاصيل التقنية الدقيقة لواقعة محور 26 يوليو غير مؤكدة في المعلومات المتاحة هنا. الشرح التالي تحليل تقني لطرق اختراق شاشات الإعلانات المحتملة، وليس تأكيدًا للطريقة المستخدمة في الواقعة.

---

🖥️ إزاي بيتم التحكم في شاشات الإعلانات الرقمية؟​

علشان نفهم إزاي ممكن شاشة إعلانات تتعرض للاختراق، محتاجين الأول نعرف إزاي الشركات بتتحكم في المحتوى اللي بيظهر عليها.
طريقة الإدارة بتختلف حسب نوع الشاشة، والبرمجيات المستخدمة، وعدد الشاشات التابعة للشركة.
وفيه 3 طرق منتشرة:

1. التحكم المباشر باستخدام USB وHDMI​

دي من أبسط طرق تشغيل شاشات الإعلانات.
بيتم توصيل وحدة تخزين USB أو جهاز تشغيل بالشاشة من خلال HDMI، وبعدها بيبدأ عرض الصور والفيديوهات المحفوظة عليه.
الطريقة دي مناسبة للشاشات الفردية أو الأماكن اللي مش محتاجة تغيير الإعلانات باستمرار.
مميزاتها:

• مش محتاجة اتصال دائم بالإنترنت.
• سهلة في التشغيل والإدارة.
• بتقلل فرص الهجمات اللي بتستهدف أنظمة التحكم عن بُعد.

لكنها مش محصنة بالكامل؛ لأن الوصول الفعلي للجهاز أو استخدام وحدة تخزين مصابة ممكن يشكل خطر أمني.

2. التحكم من خلال Web Application أو Mobile Application​

دي واحدة من أهم طرق إدارة شبكات الإعلانات الرقمية، خصوصًا لما شركة تكون مسؤولة عن عدد كبير من الشاشات في أماكن مختلفة.
بدل ما الموظف يروح لكل شاشة علشان يغيّر الإعلان، بيستخدم لوحة تحكم مركزية من خلال المتصفح أو تطبيق الموبايل.
من خلال النظام ده، المسؤول يقدر:

• يرفع صور وفيديوهات جديدة.
• يحدد المحتوى اللي هيظهر على كل شاشة.
• يجدول الإعلانات حسب اليوم والساعة.
• يتحكم في مجموعة كبيرة من الشاشات مرة واحدة.
• يتابع حالة الأجهزة المتصلة بالنظام.

النوع ده بيُعرف باسم Digital Signage Management System أو نظام إدارة الشاشات الرقمية.
المشكلة إن اختراق حساب إداري بصلاحيات واسعة ممكن يسمح للمهاجم بتغيير المحتوى على أكتر من شاشة في نفس الوقت.

3. التحكم باستخدام Media Players​

فيه شاشات بتكون متوصلة بجهاز صغير مسؤول عن تشغيل المحتوى، وده بنسميه Media Player.
الجهاز ممكن يكون كمبيوتر صغير أو وحدة تشغيل مخصصة للإعلانات الرقمية.
بعض الأنظمة بتسمح بإدارة الأجهزة دي عن بُعد باستخدام أدوات زي:

• RDP - Remote Desktop Protocol.
• VNC - Virtual Network Computing.
• AnyDesk.
• TeamViewer.

الأدوات دي مش ثغرات أمنية في حد ذاتها، لكنها ممكن تتحول لنقطة دخول خطيرة لو اتساب الوصول ليها مكشوفًا على الإنترنت أو كانت محمية بكلمات مرور ضعيفة.

---

🔓 إزاي بيتم اختراق شاشات الإعلانات؟​

اختراق شاشة إعلانية مش بالضرورة معناه إن المخترق اخترق الشاشة نفسها.
في سيناريوهات كتير، الهدف الحقيقي بيكون السيرفر المسؤول عن إدارة الإعلانات، أو الحساب الإداري، أو جهاز تشغيل المحتوى المتصل بالشاشة.
وفيه أكتر من طريقة ممكن تؤدي لاختراق الأنظمة دي.

1. كلمات المرور الضعيفة Weak Passwords​

من أشهر المشاكل الأمنية استخدام كلمات مرور افتراضية أو سهلة التخمين.
زي مثلًا:

• استخدام اسم المستخدم وكلمة المرور الافتراضيين للجهاز.
• الاعتماد على كلمات مرور شائعة زي P@ssw0rd.
• استخدام نفس كلمة المرور لأكتر من جهاز.
• عدم تفعيل المصادقة متعددة العوامل MFA.

لو المهاجم قدر يحصل على بيانات حساب إداري، ممكن يتمكن من الدخول للوحة التحكم وتغيير الإعلانات، حسب الصلاحيات المتاحة للحساب.

2. خدمات التحكم عن بُعد المكشوفة على الإنترنت​

بعض الشركات بتسمح بالوصول لأجهزة الإدارة من خارج الشبكة الداخلية.
وده مش بالضرورة يكون خطأ، لكن المشكلة بتبدأ لما الخدمات دي تكون متاحة بشكل مباشر من الإنترنت، من غير قيود وصول أو حماية مناسبة.
مثلًا، وجود خدمة RDP أو VNC مكشوفة بكلمة مرور ضعيفة ممكن يسهّل محاولات الوصول غير المصرح به.

3. الثغرات الأمنية في برمجيات الإدارة​

أنظمة إدارة الإعلانات غالبًا بتعتمد على تقنيات ويب معروفة، زي PHP وقواعد البيانات وواجهات API.
ولو النظام بيستخدم إصدارًا قديمًا أو مكوّنًا برمجيًا مصابًا بثغرة أمنية، ده ممكن يفتح الباب لهجمات مختلفة.
لكن مهم نفرّق بين حاجتين:
استخدام PHP مش معناه إن السيرفر قابل للاختراق.
وجود ثغرة في إصدار معين من PHP أو إحدى المكتبات المستخدمة لا يثبت إن كل الأنظمة المبنية عليها مصابة.
لازم نعرف الإصدار المستخدم، وإعدادات التشغيل، وطبيعة الثغرة، وهل شروط استغلالها متوفرة فعلًا.

---

🔍 إيه علاقة محرك Shodan باختراق شاشات الإعلانات؟​

محرك Shodan واحد من أشهر محركات البحث المتخصصة في اكتشاف الأجهزة والخدمات المتصلة بالإنترنت.
على عكس Google، اللي بيركز على فهرسة صفحات الويب، Shodan بيساعد الباحثين الأمنيين في التعرف على الخدمات والأجهزة الظاهرة للعامة على الإنترنت.
ومن ضمن الأنظمة اللي ممكن تظهر في نتائج البحث:

• خوادم الويب.
• أجهزة الشبكات.
• خدمات الوصول عن بُعد.
• بعض أنظمة إدارة الشاشات الرقمية.

وده معناه إن أي شركة بتستخدم نظام إدارة إعلانات متصل بالإنترنت لازم تراجع الخدمات المكشوفة للعامة، وتتأكد إن الوصول ليها مقتصر على الأشخاص المصرح لهم.
ملحوظة مهمة: ظهور سيرفر في نتائج Shodan مش دليل على اختراقه أو وجود ثغرة فيه، لكنه ممكن يكشف معلومات مفيدة لتقييم مستوى تعرضه للهجمات.

---

🎯 ليه حد يخترق شاشة إعلانات ويعرض محتوى غير لائق؟​

مش كل الهجمات الإلكترونية هدفها سرقة الأموال أو البيانات.
أحيانًا بيكون هدف المهاجم تغيير المحتوى الظاهر للجمهور، سواء على موقع إلكتروني أو شاشة رقمية.
النوع ده من الهجمات بيُعرف باسم Defacement.
وفي حالة شاشات الإعلانات، ممكن يظهر على هيئة استبدال الإعلان الأصلي بصورة أو رسالة أو فيديو غير مصرح بعرضه.

الدوافع المحتملة بتختلف من حالة للتانية، ومنها:

• لفت الانتباه: محاولة الحصول على شهرة من خلال تنفيذ هجوم ظاهر للجمهور.
• إثبات القدرة التقنية: استعراض القدرة على الوصول لنظام محمي.
• دوافع سياسية: عرض رسائل أو محتوى دعائي بدل المحتوى الأصلي.
• التخريب: تعطيل الخدمة أو الإضرار بسمعة الشركة المسؤولة عن الإعلانات.

وده يفسر ليه بعض الهجمات بتستهدف شاشات موجودة في شوارع رئيسية أو أماكن مزدحمة؛ لأن تأثيرها بيكون واضحًا لعدد كبير من الناس.
لكن تحديد الدافع الحقيقي لأي واقعة محتاج أدلة، ومينفعش نستنتجه من شكل المحتوى المعروض وحده.

---

هل اختراق شاشة محور 26 يوليو مرتبط بهجمات في دول تانية؟​

بحسب الرواية المتداولة عن الواقعة، ظهر حساب على تيليجرام منسوب للمهاجمين، ونُشرت من خلاله مواد تشير إلى تنفيذ حوادث مشابهة في دول أخرى، من بينها العراق وتايلاند.
لكن وجود منشورات بتدّعي المسؤولية عن أكتر من حادثة مش كفاية لإثبات إن نفس الشخص أو المجموعة نفذوا جميع الهجمات.
إثبات العلاقة بين الوقائع محتاج تحليل الأدلة الرقمية، ومقارنة أساليب الهجوم، والتحقق من صحة المواد المنشورة.
كمان مش بالضرورة يكون المهاجم شخصًا محترفًا أو تابعًا لمجموعة منظمة.
بعض الهجمات ممكن ينفذها أشخاص بيعتمدوا على أدوات جاهزة أو ثغرات معروفة، وده أحد السياقات اللي بيُستخدم فيها مصطلح Script Kiddies.
لكن مينفعش نصنف المسؤولين عن الواقعة دي تحديدًا من غير معلومات موثوقة عن طريقة تنفيذ الهجوم.

---

📱 هل ممكن تتبع المخترق من حساب تيليجرام؟​

ظهور حساب تيليجرام منسوب للمهاجم، أو نشر رقم هاتف مرتبط بيه، مش معناه بالضرورة إن البيانات دي بتكشف هويته الحقيقية.
فيه احتمالات مختلفة، زي استخدام رقم غير شخصي، أو بيانات تخص طرفًا آخر، أو حتى انتحال هوية شخص ملوش علاقة بالواقعة.
لكن في المقابل، النشاط الرقمي ممكن يسيب آثارًا تساعد جهات التحقيق، ومنها:

• سجلات الوصول للأنظمة المستهدفة.
• توقيتات تسجيل الدخول والتغييرات.
• البيانات المرتبطة بالحسابات المستخدمة.
• سجلات الأجهزة والخوادم.
• الأدلة الرقمية اللي يتم جمعها بالطرق القانونية.

علشان كده، مجرد نشر رقم هاتف أو اسم مستخدم مش دليل كافي على هوية المسؤول عن الهجوم.

---

🛡️ إزاي شركات الإعلانات تحمي شاشاتها من الاختراق؟​

الواقعة بتوضح أهمية التعامل مع شاشات الإعلانات باعتبارها أنظمة تقنية محتاجة حماية مستمرة، مش مجرد أجهزة لعرض الفيديوهات.

ولتقليل فرص تكرار النوع ده من الحوادث، فيه مجموعة إجراءات مهمة:

1. تغيير كلمات المرور الافتراضية: واستخدام كلمات مرور قوية وفريدة لكل حساب إداري.
2. تفعيل MFA: خصوصًا للحسابات المسؤولة عن نشر المحتوى وإدارة الأجهزة.
3. تقييد الوصول عن بُعد: وعدم كشف خدمات RDP وVNC مباشرة على الإنترنت، مع استخدام VPN أو حلول وصول آمنة عند الحاجة.
4. تحديث البرمجيات: تثبيت التحديثات الأمنية لنظام التشغيل وبرامج إدارة الإعلانات.
5. تقسيم الشبكة: عزل أجهزة الإعلانات عن الأنظمة الداخلية الحساسة للشركة.
6. تقليل الصلاحيات: عدم منح كل الموظفين القدرة على تعديل المحتوى المنشور على جميع الشاشات.
7. تفعيل سجلات المراقبة: تسجيل عمليات الدخول وتغيير المحتوى، والتنبيه عند حدوث نشاط غير معتاد.
8. وضع خطة للاستجابة للحوادث: تتيح إيقاف المحتوى غير المصرح به بسرعة، مع الاحتفاظ بالأدلة اللازمة للتحقيق.

ومن الإجراءات المفيدة كمان وجود آلية لمراجعة الإعلانات قبل نشرها، خصوصًا على الشاشات الموجودة في الأماكن العامة.

---

الخلاصة: إيه اللي نقدر نستنتجه من الواقعة؟​

اختراق شاشات الإعلانات الرقمية بيوضح إن أي جهاز متصل بنظام إدارة عن بُعد ممكن يتحول لهدف لهجوم إلكتروني لو إجراءات الحماية مش كافية.
لكن بالنسبة لواقعة شاشة محور 26 يوليو، لسه مينفعش نجزم إن السبب كان كلمة مرور ضعيفة، أو ثغرة في PHP، أو اختراقًا لخدمة تحكم عن بُعد، من غير نتائج فحص فني موثوقة.
كل دي سيناريوهات تقنية محتملة، مش حقائق مثبتة عن الحادث.
والدرس الأهم هنا إن حماية البنية التحتية الرقمية مش مقتصرة على البنوك والمواقع الحكومية. حتى شاشة إعلانات موجودة في الشارع محتاجة تحديثات أمنية، وإدارة صلاحيات، ومراقبة مستمرة.

---

الأسئلة الشائعة​

-----------------

هل ممكن اختراق شاشة إعلانات من غير الوصول ليها فعليًا؟​

أيوه، لو الشاشة متصلة بنظام إدارة عن بُعد، ونجح المهاجم في الوصول غير المصرح به للنظام أو لأحد الحسابات المسؤولة عنه، ممكن يقدر يغيّر المحتوى من غير لمس الشاشة نفسها.

هل كل شاشات الإعلانات متصلة بالإنترنت؟​

لأ. فيه شاشات بتشتغل بمحتوى محفوظ محليًا، وفيه شاشات بتعتمد على أنظمة إدارة سحابية أو شبكات خاصة.

هل اختراق سيرفر واحد ممكن يؤثر على شاشات كتير؟​

أيوه، لو السيرفر بيدير مجموعة كبيرة من الشاشات، والحساب أو النظام المخترق عنده صلاحيات تسمح بتغيير المحتوى عليها.

هل استخدام Shodan معناه إن الشخص بيخترق الأجهزة؟​

لأ. Shodan محرك بحث بيعرض معلومات عن الخدمات والأجهزة المتصلة بالإنترنت، واستخدامه في البحث الأمني مش معناه اختراق الأنظمة اللي بتظهر في نتائجه.

هل ممكن وظيفة بسيطة لتغيير البريد الإلكتروني تسمح للمستخدم بتغيير صلاحيات حسابه
والوصول إلى لوحة تحكم المدير (Admin Panel) ؟
الإجابة: أيوه، لو التطبيق مش بيتحقق بشكل صحيح من الحقول اللي المستخدم مسموح له يعدّلها، ممكن المهاجم يستغل وظيفة عادية زي تغيير الإيميل علشان يغيّر صلاحيات حسابه. وده أحد السيناريوهات المهمة في ثغرات Broken Access Control.

في الفيديو ده، هنحل اللاب الرابع من PortSwigger Web Security Academy، وهنشوف عمليًا إزاي نستخدم Burp Suite لتحليل الطلبات، واكتشاف الحقول غير المتوقعة، واختبار إمكانية تنفيذ هجوم Privilege Escalation.

---

🎥 شرح عملي: Broken Access Control - Lab 4​

هنبدأ بتحليل وظيفة تغيير البريد الإلكتروني، وبعدها هنختبر إذا كان السيرفر بيسمح بتعديل بيانات إضافية ممكن تؤثر على صلاحيات المستخدم.

🔍 هنتعلم إيه في الفيديو؟​

الشرح بيركز على فهم طريقة اكتشاف الثغرة، مش مجرد تغيير قيمة معينة علشان نحل اللاب.
هنغطي النقاط التالية:

• فهم مفهوم Roles وPermissions والفرق بينهم.
• تحديد الـ Endpoints المسؤولة عن تعديل بيانات الحساب.
• تحليل HTTP Requests وResponses باستخدام Burp Suite.
• اختبار وظيفة تغيير البريد الإلكتروني ومعرفة إذا كانت بتقبل حقول إضافية غير متوقعة.
• فهم دور الباراميتر roleid وتأثيره المحتمل على صلاحيات الحساب.
• اختبار إمكانية الوصول إلى Admin Panel بعد تعديل صلاحيات المستخدم.
• بناء منهجية واضحة لاختبار Broken Access Control أثناء اختبار اختراق تطبيقات الويب.

---

إزاي تغيير الإيميل ممكن يؤدي إلى Privilege Escalation؟​

المشكلة بتحصل لما التطبيق يعتمد على البيانات اللي المستخدم بيبعتها من المتصفح، من غير ما يتحقق على مستوى السيرفر من صلاحية تعديل كل حقل.
على سبيل المثال، وظيفة تغيير البريد الإلكتروني المفروض تسمح للمستخدم بتعديل عنوان الإيميل فقط.
لكن ماذا لو السيرفر بيقبل حقول إضافية ضمن نفس الطلب؟
هنا ممكن نختبر إذا كان إرسال باراميتر زي roleid بيؤدي لتغيير دور المستخدم داخل التطبيق.

مثال توضيحي:
لو التطبيق بيستقبل بيانات الحساب بصيغة JSON، ممكن الطلب الطبيعي يكون بالشكل التالي:
أثناء الاختبار، بنحاول نعرف إذا كان السيرفر بيقبل حقلًا إضافيًا متعلقًا بصلاحيات المستخدم:
القيمة 2 هنا مجرد مثال توضيحي، ومش بالضرورة تمثل صلاحيات المدير في أي تطبيق.
لو السيرفر سمح بتعديل دور المستخدم من خلال وظيفة تغيير البريد الإلكتروني، من غير التحقق من صلاحية تنفيذ التعديل، فده ممكن يؤدي إلى ثغرة Privilege Escalation.

مهم: قبول الطلب أو ظهور استجابة ناجحة مش دليل كافي على وجود الثغرة. لازم نتحقق إن صلاحيات الحساب اتغيرت فعلًا، وإن المستخدم بقى قادر ينفذ إجراءات مكانش مسموح له ينفذها قبل كده.

---

🛠️ استخدام Burp Suite لاكتشاف الثغرة​

خلال الفيديو، هنستخدم Burp Suite علشان نفهم التطبيق بيتعامل إزاي مع طلبات تعديل بيانات الحساب.
منهجية الاختبار بتعتمد على الخطوات التالية:

1. تسجيل الدخول بحساب مستخدم عادي داخل بيئة اللاب.
2. اعتراض طلب تغيير البريد الإلكتروني باستخدام Burp Proxy.
3. إرسال الطلب إلى Burp Repeater لتحليله.
4. مراجعة الباراميترات اللي بيستقبلها السيرفر.
5. اختبار إضافة أو تعديل الحقول المرتبطة بصلاحيات الحساب.
6. مقارنة استجابة السيرفر قبل التعديل وبعده.
7. التحقق من تأثير التغيير على صلاحيات المستخدم وإمكانية الوصول إلى Admin Panel.

الهدف من الخطوات دي إننا نفهم هل التطبيق بيفرض قواعد الصلاحيات على السيرفر فعلًا، ولا بيسمح للمستخدم بتعديل بيانات المفروض تكون محمية.

---

💡 إيه الدرس الأمني من اللاب؟​

أثناء اختبار Broken Access Control، متكتفيش بفحص صفحات الإدارة أو محاولة الوصول إلى روابط محمية.
وظائف تعديل بيانات الحساب نفسها ممكن تكشف مشاكل أمنية مهمة، خصوصًا لو التطبيق بيسمح بتعديل حقول إضافية غير مخصصة للمستخدم.

علشان كده، من المهم اختبار:

• وظائف تعديل الملف الشخصي (Profile).
• طلبات تغيير البريد الإلكتروني.
• الحقول المرتبطة بالأدوار والصلاحيات.
• التحقق من صلاحية تعديل كل حقل على مستوى السيرفر.

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

---

🎯 مين يستفيد من الفيديو؟​

الفيديو مناسب لأي شخص بيتعلم Web Penetration Testing أو مهتم بمجال Bug Bounty، خصوصًا لو عنده معرفة أساسية بطلبات HTTP وعايز يتدرب على اكتشاف ثغرات التحكم في الوصول بشكل عملي.

الأدوات المستخدمة:

• Burp Suite.
• PortSwigger Web Security Academy.

جميع التجارب الموضحة مخصصة للتعلم داخل بيئة تدريبية أو أثناء اختبارات أمنية مصرح بها.
الهدف مش مجرد حل اللاب الرابع، لكن إنك تتعلم طريقة تفكير وتحليل تقدر تستخدمها بعد كده في اكتشاف ثغرات مشابهة.

💬 سؤال للنقاش:
وأنت بتختبر Broken Access Control، هل بتراجع وظائف تعديل بيانات الحساب وبتختبر إمكانية إضافة Parameters غير متوقعة، ولا بتركز بشكل أساسي على صفحات الإدارة والـ Endpoints المحمية؟
شاركنا تجربتك في التعليقات.

لو بتستخدم Claude لمجرد إنك تسأله سؤال، تنسخ الإجابة، وبعد كده تكمل شغلك بنفسك، فأنت غالبًا مش بتستفيد من كل إمكانياته.
Claude مش مجرد شات للرد على الأسئلة. تقدر تستخدمه في فهم الملفات، تلخيص المحاضرات، البحث عن معلومات، تجهيز التقارير، تنظيم البيانات، والمساعدة في تنفيذ مهام كاملة بدل ما تعمل كل خطوة يدويًا.
في الكراش كورس ده هتتعلم استخدام Claude من الصفر، بداية من إنشاء الحساب وكتابة أول طلب، لحد استخدامه في تجهيز ملفات Word وExcel وPowerPoint، وربطه بأدواتك اليومية.
والشرح مناسب ليك سواء كنت طالب، موظف، مدرس، أو حتى بتستخدم أدوات الذكاء الاصطناعي لأول مرة.

🤖 إيه هو Claude AI وإزاي تستفيد منه؟​

Claude هو مساعد ذكاء اصطناعي من تطوير شركة Anthropic، تقدر تتكلم معاه بلغة طبيعية وتطلب منه مساعدتك في مهام مختلفة.
بدل ما تكتفي بسؤاله عن معلومة، ممكن تديله ملف أو مجموعة تعليمات وتطلب منه نتيجة محددة.

على سبيل المثال:

• 📚 طالب: يرفع محاضرة ويطلب تلخيصها وتجهيز أسئلة للمراجعة.
• 💼 موظف: يطلب تحليل بيانات وتجهيز تقرير منظم.
• 👩‍🏫 مدرس: يستخدمه في تحضير درس أو إعداد أسئلة للطلاب.
• 📊 صاحب مشروع: يستعين بيه في تنظيم البيانات وتجهيز عرض تقديمي.

الفكرة الأساسية إنك تتعامل مع Claude كمساعد في تنفيذ الشغل، مش مجرد محرك بحث.

---

📚 هتتعلم إيه في كورس Claude؟​

الكورس بيبدأ معاك من الأساسيات، وبعدها بينتقل تدريجيًا لاستخدام الملفات والأدوات وتنفيذ المهام الأكثر تعقيدًا.

1. إنشاء الحساب والتعرف على واجهة Claude​

في البداية هتتعرف على طريقة الوصول إلى Claude، وإنشاء حساب، والفرق بين الخطط المتاحة، وإزاي تتعامل مع واجهة المحادثة.
تقدر تبدأ من الموقع الرسمي: https://claude.ai/
مش لازم تكون عندك خبرة سابقة في أدوات الذكاء الاصطناعي علشان تتابع الشرح.

2. إزاي تكتب طلب واضح وتحصل على نتيجة أفضل؟​

جودة النتيجة بتعتمد بدرجة كبيرة على وضوح التعليمات اللي بتقدمها.
مثلًا، بدل ما تكتب:

اشرح لي الشبكات

أنقر للتوسيع...

ممكن تطلب:

اشرح أساسيات شبكات الكمبيوتر لشخص مبتدئ، مع أمثلة بسيطة وجدول يوضح الفرق بين LAN وWAN، وفي النهاية أضف 5 أسئلة للمراجعة.

أنقر للتوسيع...

الطلب التاني بيوضح الموضوع، ومستوى الشرح، وشكل النتيجة المطلوبة.
وده بيساعد Claude يفهم أنت محتاج إيه بالضبط.

3. التعامل مع الملفات بدل النسخ واللصق​

من الاستخدامات المهمة لـ Claude إنك تقدر ترفع ملفات وتطلب منه التعامل مع محتواها.
مثلًا، ممكن ترفع مستند وتطلب منه:

• تلخيص أهم المعلومات.
• استخراج النقاط الأساسية.
• شرح الأجزاء الصعبة.
• مقارنة المعلومات الموجودة في أكثر من ملف.
• تجهيز أسئلة وإجابات للمذاكرة.

نصيحة: لما تطلب إجابة مبنية على ملف، اطلب من Claude الاعتماد على محتوى الملف نفسه، وتوضيح أي معلومة مش موجودة فيه بدل ما يفترضها.

4. البحث عن معلومات حديثة مع المصادر​

مش كل سؤال ينفع تعتمد في إجابته على المعرفة السابقة لنموذج الذكاء الاصطناعي.
لو بتبحث عن تحديث تقني، خبر جديد، أو معلومة قابلة للتغيير، تقدر تستخدم إمكانيات البحث المتاحة في Claude وتطلب منه عرض المصادر.
وده بيساعدك تراجع المعلومات بنفسك بدل الاعتماد على الإجابة بشكل أعمى.

5. تحويل الإجابات إلى ملفات جاهزة​

هنا بتبدأ تستفيد من Claude بشكل أكبر.
بدل ما تطلب منه كتابة محتوى وتفضل تنسخه وتنسقه يدويًا، ممكن تطلب منه تجهيز مخرجات عملية، زي:

• تقرير منظم.
• عرض تقديمي PowerPoint.
• جدول بيانات Excel.
• مستند Word.
• ملخص دراسي قابل للاستخدام.

إمكانية إنشاء الملفات أو تعديلها بتختلف حسب الأدوات والخطة المتاحة، وطبيعة المهمة المطلوبة.

6. تنظيم الشغل المتكرر​

لو عندك مهام بتعملها باستمرار، الكورس بيوضح إزاي تنظم طريقة استخدام Claude علشان متضطرش تبدأ من الصفر كل مرة.
الفكرة إنك تحتفظ بسياق الشغل والتعليمات المهمة، وتستخدم الإمكانيات التنظيمية المتاحة لتسهيل متابعة المشاريع والمهام المتشابهة.

7. ربط Claude بأدواتك اليومية​

مش لازم كل شغلك يكون داخل نافذة المحادثة.
الكورس بيتناول فكرة توصيل Claude بالأدوات والخدمات الأخرى، وإزاي التكاملات المدعومة ممكن تساعدك تتعامل مع المعلومات وتنجز المهام من مكان واحد.
لكن مهم تعرف إن بعض عمليات الربط بتحتاج صلاحيات أو إعدادات إضافية، ومش كل التكاملات متاحة لجميع الحسابات.

8. تسليم Claude مهمة كاملة​

بدل ما تقسم الشغل بنفسك إلى عشرات الأسئلة الصغيرة، هتتعرف على فكرة تكليف Claude بمهمة لها هدف واضح ومخرجات محددة.
مثلًا: جهز تقريرًا من البيانات المرفقة، واستخرج أهم النتائج، ثم أنشئ عرضًا تقديميًا يلخص التقرير في 8 شرائح.
كل ما كانت المهمة واضحة، ومعاها الملفات والتعليمات المناسبة، زادت فرص الحصول على نتيجة مفيدة.
ومع ذلك، لازم تراجع المخرجات قبل استخدامها، خصوصًا لو فيها أرقام أو معلومات مهمة.

---

🎬 شاهد كورس Claude AI كاملًا بالعربي​

الفيديو بيشرح الخطوات بشكل تدريجي، مع أمثلة تطبيقية باستخدام شخصيات كريم ومس منى وسلمى، علشان تشوف إزاي ممكن استخدام Claude في الدراسة والشغل والتدريس.
مدة الكورس: حوالي 20 دقيقة.

⏱️ فهرس الفيديو: انتقل مباشرة للجزء اللي محتاجه​

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

🔐 إزاي تستخدم Claude بأمان؟​

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

1. متشاركش كلمات المرور أو مفاتيح API أو البيانات السرية.
2. راجع الملفات قبل رفعها، خصوصًا لو بتحتوي على معلومات تخص أشخاص آخرين.
3. اتأكد من الأرقام والمعلومات المهمة من مصادرها الأصلية.
4. راجع أي تقرير أو ملف تم إنشاؤه قبل إرساله أو نشره.
5. متمنحش أي أداة صلاحيات أكبر من اللي محتاجاها لتنفيذ المهمة.

افتكر: Claude ممكن يوفر عليك وقت ومجهود كبير، لكنه مش بديل عن مراجعتك للنتيجة النهائية.

---

هل كورس Claude مناسب للمبتدئين؟​

أيوه، الكورس بيبدأ من أول التعامل مع الواجهة وكتابة الطلبات، وبعدها بينتقل تدريجيًا للتعامل مع الملفات والمهام الأكثر تقدمًا.
ولو أول مرة تستخدم Claude، الأفضل تشاهد الفيديو بالترتيب وتطبق كل جزء بنفسك.
ابدأ بمهمة بسيطة، زي تلخيص ملف أو تنظيم بيانات، وبعد ما تتعود على طريقة كتابة التعليمات، جرّب تكليفه بمهمة أكبر.
الهدف مش إنك تحفظ مجموعة أوامر جاهزة، لكن إنك تتعلم إزاي تحول أي شغل عندك إلى تعليمات واضحة تقدر تستفيد فيها من الذكاء الاصطناعي.