ما هو هذا المستودع؟

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

هذه مسودة

هذه الوثيقة مسودة، ولم يتم تنفيذها بعد من قبل أي من منصات مكافآت الاختراق. في هذه المرحلة، أطلب التعليقات من جميع الأطراف المهتمة.

كيفية المساهمة

يرجى المساهمة عن طريق فتح قضايا GitHub. ستبقى جميع القضايا المعقولة المقدمة مفتوحة للتعليقات لمدة 30 يوماً على الأقل.

يجب أن تعرض قضيتك رأياً، على سبيل المثال:

أرى أنه ينبغي إضافة سيناريو للحالة التي يتواصل فيها هاكر مباشرة مع البرنامج بدلاً من الإبلاغ عبر المنصة المقدمة.
أرى أنه ينبغي إضافة سيناريو لإساءة أحد الأطراف إلى طرف آخر.
أرى أنه ينبغي تغيير الحل للسيناريو 4 إلى "يُسمح للهاكر بالكشف العلني عن الثغرة بعد 120 يوماً من عدم الاستجابة".

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

الجدول

ID	الموقف	الحل
1	يقدّم الهاكر ثغرة مع دليل على الاستغلال. يتم إصلاح الثغرة قبل فرز التقديم.	يجب على المنصة تقديم دليل على أن البرنامج لم يطّلع على التقديم قبل إصلاح الثغرة. إذا كان البرنامج قد اطّلع على التقديم، فيجب عليه دفع المكافأة المناسبة، وإلا فسيتم وضع علامة مكرر (duplicate) على التقديم.
2	يقدّم الهاكر ثغرة، ويرد البرنامج قائلاً إنه كان يعرف عنها بالفعل داخلياً.	يجب على البرنامج تقديم دليل على أن هذه كانت مشكلة معروفة مسبقاً، على سبيل المثال، لقطة شاشة لتذكرة Jira تتضمن تاريخ الإنشاء. إذا تعذّر على البرنامج تقديم الدليل، فيجب عليه دفع المكافأة، وإلا فينبغي وضع علامة مكرر على التقديم.
3	يقدّم الهاكر ثغرة، ويتم تصنيفها كمكرر لتقديم آخر لم يستكشف تأثير الثغرة بشكل كامل. على سبيل المثال، يقدّم هاكر ثغرة XSS كاملة تسمح بالاستيلاء على الحساب، ويتم اعتبارها مكررة لتقديم آخر أبلغ فقط عن حقن HTML.	يحصل المبلّغ الأول على مكافأة بناءً على تأثير تقديمه، ويحصل المبلّغ الثاني على مكافأة بناءً على تأثير تقديمه مطروحاً منها المكافأة التي حصل عليها المبلّغ الأول.
4	يقدّم الهاكر ثغرة، ولا يرد البرنامج أبداً.	تقوم المنصة بدفع المكافأة.
5	يقدّم الهاكر ثغرة، ويتم تصنيف تقديمه بشكل غير صحيح كمكرر لتقرير أحدث.	تغيّر المنصة حالة التقريرين لتكون دقيقة. إذا كان الدفع قد تم بالفعل بشكل غير صحيح، فإن المؤسسة التي أجرت الفرز بشكل غير صحيح هي التي تدفع المكافأة. بالنسبة لبرامج المكافآت المُدارة، سيكون هذا عموماً هو المنصة، أما بالنسبة للبرامج غير المُدارة فسيكون هو البرنامج.
6	يعترض الهاكر على تقييم الخطورة المعيّن.	يقدّم الهاكر أسباب اعتراضه إلى التذكرة. إذا لم يكن هناك رد خلال 14 يوماً، يقدّم الهاكر الأسباب إلى قناة دعم المنصة. يتم البت في رفع مستوى الخطورة على أساس كل تقديم على حدة.
7	يكشف الهاكر علناً عن ثغرة تم تقديمها مسبقاً إلى المنصة، دون إذن صريح من مالك البرنامج.	يجب أن يكون الباحث قادراً على الكشف العلني عن الثغرة في الحالات التالية: أ) لم يتم قبول الثغرة كصحيحة، أي تم وضع علامة N/A أو Informative عليها. ب) كانت الثغرة في حالة محلولة لمدة 30 يوماً أو أكثر. ج) حصل الباحث على إذن صريح من البرنامج بالكشف العلني. في الحالات الأخرى، يتلقى الهاكر حظراً لمدة 30 يوماً من المنصة، ويتم إرسال بريد إلكتروني إليه يتضمن كامل الأسباب وراء الحظر. تكرار المخالفة يؤدي إلى الحظر الدائم.
8	يقدّم الهاكر ثغرة تقع ضمن نطاق البرنامج، ولكنها في الواقع ثغرة في خدمة تابعة لطرف ثالث.	يجب على كل برنامج أن يحدد في موجزه ما إذا كان يقبل الثغرات على أنظمة الأطراف الثالثة. إذا لم يوجد تحديد، فمن المفترض أن جميع الأنظمة المدرجة في النطاق ستكون صالحة للدفع، بما في ذلك أنظمة الأطراف الثالثة.
9	يقدّم الهاكر ثغرة من نوع zero-day لا توجد لها استغلالات أو كشف علني، وتؤثر على الأنظمة الواقعة ضمن النطاق.	إذا تم إجراء أي تغييرات نتيجة للتقرير، أي تغييرات في الإعدادات، أو إخراج الأنظمة من الخدمة، أو تطبيق قواعد WAF، فيجب قبول التقرير ومكافأته. يجب إجراء تمييز بين استغلالات zero-day العلنية، واستغلالات zero-day التي لم يكن فريقك ليعرف عنها لولا تقرير مكافآت الاختراق.

bug-bounty-standards

الأكثر شعبية