برنامج Bug Bounty

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

التزامنا

عندما تشارك في برنامج Bug Bounty لدينا، نعدك بما يلي:

• الإقرار بتقريرك وتقييمه في وقت مناسب
• معالجة الثغرات المؤكدة بالسرعة المناسبة
• تقديرك ومكافأتك على الثغرات الفريدة وغير المبلغ عنها سابقاً التي تؤدي إلى تحسينات أمنية

نطاق البرنامج

ينطبق برنامج Bug Bounty هذا على منصات Appbox التالية:

• Appbox Primary Website [https://www.appbox.co]
• Appbox Control Panel [https://www.appbox.co/login]
• Appbox Hosting Infrastructure [username.appboxes.co] - البنية التحتية فقط، وليس تطبيقات العملاء

ملاحظة: رغم أن بنية hosting التحتية لدينا (username.appboxes.co) ضمن النطاق، فإن الثغرات في تطبيقات الجهات الخارجية التي ينشرها العملاء ليست كذلك. راجع الاستثناءات أدناه.

ما الذي يُعد ثغرة صالحة

للتأهل لبرنامج Bug Bounty لدينا، يجب أن يستوفي التقرير كل المعايير التالية:

1. إظهار استغلال فعلي

• تضمين proof of concept عامل يوضح إمكانية استغلال الثغرة
• إظهار أثر أمني واضح؛ الثغرات النظرية دون ضرر مثبت لا تتأهل
• إثبات أن مهاجماً يستطيع فعلاً تعريض بيانات المستخدمين أو حساباتهم أو سلامة النظام للخطر

2. التأثير في أنظمة ضمن النطاق

• يجب أن تكون الثغرة موجودة في كود Appbox المملوك أو بنيتها التحتية
• يجب أن تؤثر في أنظمة مذكورة صراحة في "نطاق البرنامج" أعلاه
• يجب أن تكون قابلة لإعادة الإنتاج على بيئات production أو staging لدينا

3. أن تكون غير مبلغ عنها سابقاً

• يجب أن تكون الثغرة مكتشفة حديثاً وغير معروفة لدينا مسبقاً
• لا تتأهل التقارير المكررة أو تنويعات المشكلات المعروفة

المجالات والمشكلات المستثناة

تُعد الأمور التالية خارج نطاق برنامج Bug Bounty لدينا:

أنظمة وتكاملات الجهات الخارجية

• WHMCS Client Area [https://billing.appbox.co] - أبلغ WHMCS Security
• Chatwoot chat widget - أبلغ Chatwoot Security
• التطبيقات التي ينشرها العملاء [app.username.appboxes.co] - يجب الإبلاغ عن الثغرات في تطبيقات الجهات الخارجية (WordPress وNextcloud وغيرها) المستضافة على بنيتنا التحتية إلى موردي التطبيقات المعنيين
• أي خدمات أو plugins أو تكاملات أخرى لجهات خارجية نستخدمها
• عناوين IP أو نطاقات لا تخضع مباشرة لسيطرة Appbox
• الأنظمة القديمة أو المهملة التي لم تعد قيد الاستخدام النشط

خارج نطاق بنية hosting التحتية:

• الثغرات داخل كود التطبيقات التي ينشرها العملاء (WordPress وNextcloud وغيرها)
• الإعدادات الافتراضية لتطبيقات الجهات الخارجية
• مشكلات الأمان الخاصة بإصدار تطبيق محدد

Security Headers والتحصين

• غياب security headers (X-Frame-Options وCOOP وCOEP وMTA-STS وغيرها) ما لم تثبت استغلالاً فعلياً يؤدي إلى اختراق بيانات
• غياب خصائص rel="noopener" أو rel="noreferrer"
• كشف إصدار الخادم أو تسريب معلومات HTTP header
• خصائص cookies غير الحساسة (analytics والتفضيلات وغيرها)

إفصاح معلومات منخفض الأثر

• رسائل خطأ مطولة لا تكشف بيانات حساسة (كلمات مرور، tokens، PII)
• كشف المسارات دون إثبات path traversal أو وصول إلى الملفات
• تحديد مكدس التقنية (إصدار PHP، اكتشاف framework، وغيرها)
• استجابات أو سلوكيات عامة للتطبيق

قرارات تصميمية ومشكلات نظرية

• Login CSRF (لا يمنح المهاجم وصولاً إلى حسابات الضحايا)
• تعداد المستخدمين عبر timing attacks أو الاستجابات التفاضلية (ما لم يكن جزءاً من سلسلة هجوم أكبر)
• Clickjacking دون استغلال مثبت لوظيفة حساسة
• إعدادات CORS على endpoints غير حساسة
• غياب rate limiting ما لم تثبت إساءة استخدام فعلية (لا يزال DoS مستثنى)

متطلبات مسبقة للهجوم

• مشكلات أمان لا تؤثر في إعدادات التطبيق الافتراضية لدينا
• ثغرات تتطلب إعدادات غير قياسية
• ثغرات في حاوياتنا تتطلب إعدادات مخصصة أو معدّلة
• مشكلات تتطلب اختراقاً على مستوى الشبكة (MITM، DNS poisoning، ARP spoofing)

طرق اختبار محظورة

• هجمات إفصاح معلومات مبنية على التوقيت
• تقنيات تعداد العمليات
• أي شكل من denial of service أو الهجمات عالية الحجم
• تقنيات الهندسة الاجتماعية وphishing
• الفحص الأمني الآلي الذي يولد حركة مرور أو أحمالاً مفرطة
• اختبار ميزات أو صفحات غير عاملة (مثل صفحات signup غير الموجودة بعد في production)

أنواع تقارير غير صالحة

• تقارير مبنية فقط على مخرجات ماسحات آلية دون تحقق يدوي
• توصيات عامة دون إظهار ثغرات فعلية
• اقتراحات أفضل الممارسات دون أثر أمني
• ملاحظات امتثال (PCI-DSS وGDPR وغيرها) دون إثبات قابلية الاستغلال

هيكل المكافآت

الموقع الرئيسي ولوحة التحكم

بنية hosting التحتية

سيُكرّم المساهمون الذين يبلغون عن ثغرات صالحة في Security Researchers Hall of Fame لدينا كعربون تقدير.

جودة التقرير المطلوبة

يجب أن تتضمن كل تقارير الثغرات:

• وصفاً واضحاً للثغرة - اشرح ماهية الثغرة ولماذا تهم
• النظام/URL المتأثر - حدد بدقة مكان وجود الثغرة
• خطوات إعادة الإنتاج خطوة بخطوة - خطوات مفصلة تسمح لنا بإعادة إنتاج المشكلة
• proof of concept عامل - عرض عملي للاستغلال (كود، لقطات شاشة، فيديو)
• أثراً أمنياً فعلياً - أظهر ما يمكن للمهاجم إنجازه، لا احتمالات نظرية
• اختبارك الخاص - تحقق من النتائج يدوياً، ولا تمرر فقط مخرجات ماسح آلي

التقارير التي تفتقر إلى هذه العناصر أو تتكون من توصيات أمنية عامة لن تتأهل للمكافآت.

المطالبة بمكافأتك

• يمكنك الاختيار بين خيارين للمكافأة:
  • دفعة PayPal مباشرة (تتطلب حساب PayPal صالحاً)
  • أرصدة خدمات Appbox (تنطبق على أي خدمة Appbox، غير قابلة للتحويل)

إرشادات المشاركة

• التزم بهذه السياسة، وشروط الخدمة، وكل القوانين المعمول بها
• أبلغ عن الثغرات بسرعة بعد اكتشافها
• احترم خصوصية المستخدمين وسلامة النظام أثناء بحثك
• أرسل كل تقارير الثغرات حصرياً عبر نموذج التواصل معنا
• حافظ على سرية الثغرات المكتشفة حتى حلها
• احصر اختباراتك في الأنظمة المذكورة صراحة ضمن هذا البرنامج
• إذا حصلت على وصول غير متوقع إلى بيانات حساسة: لا تصل إلا إلى الحد الأدنى اللازم لإثبات المشكلة، وأوقف الاختبار فوراً، وأبلغ عن الثغرة بسرعة
• استخدم حسابات الاختبار الخاصة بك فقط لأي تفاعل مع أنظمتنا
• لا تحاول أبداً ابتزاز Appbox بناءً على نتائجك
• تحقق من نتائجك - اختبر أن proof of concept يعمل فعلاً قبل الإرسال
• ركز على الأثر - أعط الأولوية للثغرات التي قد تسبب ضرراً حقيقياً على المشكلات النظرية

الحماية القانونية

يمكن لباحثي الأمن الذين يتبعون هذه السياسة توقع:

• الحماية من الإجراءات القانونية بسبب بحث أمني حسن النية يُجرى ضمن هذه الإرشادات
• الإعفاء من دعاوى مكافحة التحايل القانونية عندما يكون ذلك ضرورياً لبحث أمني مشروع
• التنازل عن بعض قيود السياسات التي كانت ستمنع الاختبار الأمني
• الاعتراف بأن البحث الأمني المتوافق مفيد ويُجرى بحسن نية

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

عملية الإبلاغ

للإبلاغ عن ثغرة، أنشئ تذكرة مفصلة عبر نموذج التواصل معنا.

• يجب أن يتضمن تقريرك خطوات شاملة لإعادة إنتاج الثغرة. يمكنك استخدام هذا القالب كدليل: https://github.com/ZephrFish/BugBountyTemplates/blob/master/Example.md
• يجب أن تمر كل اتصالات البرنامج عبر Support Ticket Platform الرسمية لدينا
• الإفصاح العام عن أي ثغرة دون إذن كتابي صريح من Appbox ينتهك شروط هذا البرنامج وسيحرمك من تلقي مكافأة

ماذا يحدث بعد الإبلاغ

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

نقدّر البحث عالي الجودة والمساهمات البنّاءة في أمننا. شكراً لمساعدتك في الحفاظ على أمان Appbox.