- بواسطة x32x01 ||
هل ممكن تكتشف ثغرة Critical في منصة زي HackerOne، رغم وجود فريق أمني متخصص وآلاف الباحثين اللي بيختبروا المنصة باستمرار؟
الإجابة أيوه، وده بالضبط اللي حصل مع ثغرة IDOR/Broken Access Control تم الإبلاغ عنها في HackerOne، واللي انتهت بمكافأة وصلت إلى 15,000 دولار.
الأسبوع اللي فات، ناس كتير شافت تقرير الثغرة، لكن أنا عايز أتكلم عنها من منظور مختلف شوية. مش مجرد شرح تقني للبج، لكن عن طريقة التفكير اللي خلت باحث أمني يكتشف حاجة ممكن تكون عدّت على باحثين كتير من غير ما ياخدوا بالهم منها.
والأهم، إزاي القصة دي بتثبت إن الـ Manual Hunting لسه ليه مكانه، حتى مع انتشار أدوات الذكاء الاصطناعي في مجال الأمن السيبراني.
لو أنت Bug Bounty Hunter وبتستخدم HackerOne، فأكيد عارف إحساس إنك تبلغ عن ثغرة، وبعد فترة تكتشف إن تقريرك اتقفل باعتباره Duplicate.
طبيعي وقتها يبقى عندك فضول تشوف التقرير الأصلي اللي سبقك، وتعرف الباحث التاني اكتشف إيه أو وصل للثغرة إزاي.
لكن لما بتحاول تفتح تقرير مش مسموح لك تشوفه، بتقابل رسالة الخطأ الشهيرة:
وده معناه إنك مش قادر توصل للمحتوى المطلوب بالطريقة دي.
معظمنا بيشوف الرسالة، وبيعتبر إن الموضوع انتهى، ويكمل شغله عادي.
لكن الباحث اللي اكتشف الثغرة دي قرر ميقفش عند النقطة دي.
اكتشف إنه يقدر ينشئ حساب VDP على HackerOne، وهو نوع من الحسابات المرتبطة بالمشاركة في برامج Vulnerability Disclosure Program.
بعد إنشاء الحساب، رجع لنفس الـ Endpoint وحاول الوصول للتقرير مرة تانية.
النتيجة الظاهرة كانت تقريبًا زي ما هي، لكن المرة دي الباحث كان بيراقب الاتصال باستخدام Burp Suite.
وهنا ظهرت المفاجأة.
رغم إن واجهة المستخدم كانت بتعرض رسالة خطأ، لاحظ الباحث إن الـ HTTP Response بيحتوي على بيانات التقرير نفسه داخل الحقل:
بمعنى إن التطبيق كان بيمنع عرض المحتوى في الواجهة، لكن البيانات الحساسة كانت لسه موجودة في الاستجابة اللي وصلت للعميل.
وده جوهر المشكلة الأمنية: منع المستخدم من مشاهدة البيانات في الواجهة مش معناه بالضرورة إن السيرفر منعه من استلامها.
الثغرة تم الإبلاغ عنها، واتقبلت بتصنيف Critical، ووصلت مكافأتها إلى 15,000 دولار.
لما مستخدم يطلب مورد معين، السيرفر المفروض يتحقق من هويته وصلاحياته قبل ما يرجع أي بيانات خاصة بالمورد ده.
مش كفاية إن التطبيق يعرض صفحة خطأ أو يخفي البيانات باستخدام JavaScript.
لو البيانات وصلت بالفعل داخل الـ Response، فإخفاؤها من واجهة المستخدم مش هيحميها من شخص بيفحص حركة الشبكة.
وده بيوضح الفرق بين حاجتين:
ومن المهم كمان نفهم إن ظهور كود
إحنا بنتكلم عن HackerOne، واحدة من أشهر منصات الـ Bug Bounty، واللي بيستخدمها عدد ضخم من الباحثين الأمنيين.
أكيد مش أنا الوحيد اللي حاول قبل كده يفتح تقرير مش بتاعه، وشاف رسالة الخطأ، وبعدها قرر يسيب الموضوع.
لكن السؤال هنا:
ليه أحيانًا بنفترض إن أي حاجة بسيطة في منصة كبيرة أكيد اتعملها Testing قبل كده؟
الفكرة دي كانت بتيجي في بالي كتير.
يعني منصة بالحجم ده، وعندها فريق Security، وبيستخدمها باحثون أمنيون محترفون، ومع وجود أدوات AI وعمليات Security Testing وCode Review، هل منطقي إني أكون الشخص اللي هيكتشف فيها ثغرة؟
أكيد كل حاجة اتجربت قبل كده، صح؟
لكن الحقيقة إن الافتراض ده ممكن يكون واحد من أكبر العوائق اللي بتمنعك تكتشف ثغرات جديدة.
لما اتكلمت مع أكتر من باحث أمني أقدم مني، وعندهم خبرة وبروفايلات محترمة في المجال، كانت نصيحتهم واضحة:
لو هتكمل بنفس طريقة التفكير دي، لازم تغير الـ Methodology بتاعتك.
لأنك كده بتستبعد احتمالات قبل حتى ما تجربها.
الفكرة الأساسية اعتمدت على كام نقطة:
وده خلاني أفكر في سؤال مهم:
هل أدوات الـ AI المستخدمة في الاختبارات الأمنية كانت هتكتشف نفس المشكلة؟ وهل مراجعة الكود كانت ممكن تكشف إن فيه بيانات حساسة بتترجع قبل التحقق الصحيح من الصلاحيات؟
ممكن طبعًا، لكن وجود الأدوات أو عمليات المراجعة مش ضمان لاكتشاف كل ثغرة.
أحيانًا تغيير بسيط في زاوية الاختبار بيكشف مشكلة كانت مستخبية وسط سلوك يبدو طبيعيًا.
لقيت إن حسابه موجود من سنة 2023، وإن الثغرة دي كانت التقرير الوحيد الظاهر على البروفايل وقت ما راجعته.
وده في حد ذاته لفت نظري.
مش شرط يكون عندك مئات التقارير المقبولة أو بروفايل مليان Badges علشان تكتشف ثغرة مؤثرة.
كمان، بحسب التسلسل الزمني اللي ظهر في التقرير:
وده درس مهم لأي حد بيكتب Bug Bounty Reports.
جودة التقرير مش بعدد السطور، لكن بوضوح الثغرة، وإمكانية إعادة إنتاجها، وإثبات تأثيرها الأمني.
مش مطلوب تكتب موضوع تعبير علشان تثبت إنك اكتشفت مشكلة حقيقية.
وفي المقابل، مش معنى إن التقرير قصير إنه بالضرورة أفضل. بعض الثغرات بتحتاج تفاصيل تقنية أكتر، أو خطوات واضحة، أو أدلة إضافية علشان فريق الأمن يقدر يتحقق منها.
المهم إنك تقدم المعلومات المطلوبة من غير حشو.
الذكاء الاصطناعي بقى أداة مهمة جدًا في مجال اختبار الاختراق، وممكن يساعدك في حاجات كتير، زي:
الثغرة دي مثال كويس على قيمة الفضول البشري.
الباحث شاف رسالة خطأ، لكنه قرر يسأل نفسه: طب إيه اللي ممكن يحصل لو جربت حساب مختلف؟ وهل الاستجابة نفسها بتحتوي على حاجة مش ظاهرة في الصفحة؟
النوع ده من التفكير مهم جدًا في الـ Business Logic وAccess Control Testing.
وده مش معناه إن أدوات الذكاء الاصطناعي مستحيل تكتشف ثغرات مشابهة، لكن معناه إن الاعتماد على الأتمتة وحدها ممكن يخليك تفوّت سيناريوهات مهمة.
استخدم AI كأداة بتقوّي شغلك، مش كبديل عن فهمك للتطبيق وطريقة تفكيرك كباحث أمني.
1. متستبعدش هدف لمجرد إنه مشهور
كبر حجم الشركة أو وجود فريق أمني قوي مش معناه إن التطبيق خالي من الثغرات.
2. افهم التطبيق قبل ما تبدأ تختبره
كل ما فهمت أنواع الحسابات والصلاحيات وطريقة تعامل التطبيق مع البيانات، هتقدر تبني سيناريوهات اختبار أفضل.
3. متعتمدش على واجهة المستخدم فقط
في الاختبارات المصرح بها، راجع الـ Requests والـ Responses، وافهم الفرق بين النتيجة اللي بتظهر للمستخدم والبيانات اللي بيرجعها السيرفر.
4. جرّب سيناريوهات مختلفة للصلاحيات
اختلاف نوع الحساب أو الدور الوظيفي ممكن يكشف مشاكل في تطبيق قواعد الـ Authorization. وطبعًا لازم كل الاختبارات تكون داخل النطاق المسموح به في البرنامج.
5. متقيسش قيمة اكتشافك بتعقيد الثغرة
مش كل ثغرة Critical محتاجة سلسلة استغلال معقدة. أحيانًا خطأ بسيط في التحكم بالصلاحيات بيكون تأثيره كبير جدًا.
6. اكتب تقرير واضح بدل ما تكتب تقرير طويل
وضح المشكلة، وخطوات إعادة إنتاجها، والنتيجة المتوقعة والفعلية، والتأثير الأمني، مع الالتزام بسياسات البرنامج.
آه، اكتشاف الثغرات مش بنفس سهولة زمان، والمنافسة بقت أكبر، لكن ده مش معناه إن الفرص انتهت.
أحيانًا كل اللي محتاجه إنك تبص على حاجة مألوفة من زاوية مختلفة، أو تسأل سؤال محدش فكر يسأله، أو متكتفيش بالنتيجة الظاهرة قدامك.
متشغلش بالك بإن غيرك أكيد اختبر كل حاجة قبلك.
ذاكر، واشتغل على الـ Methodology بتاعتك، وافهم التطبيقات اللي بتختبرها، واستخدم الأدوات الحديثة علشان تطور شغلك من غير ما تتخلى عن تفكيرك.
وافتكر دايمًا:
مش لازم تكون أقدم Hunter في المجال علشان تكتشف ثغرة حقيقية. المهم إنك متبطلش تفكر وتجرب وتتعلم.
ربنا يوفق كل واحد بيجتهد في المجال، وإن شاء الله تعبك يجيب نتيجة.
📎 رابط تقرير الثغرة الأصلي على HackerOne:
https://hackerone.com/reports/3862641
ملحوظة: أي اختبار متعلق بالتحكم في الصلاحيات أو الوصول للبيانات لازم يتم داخل نطاق مصرح به، مع تجنب الاطلاع على بيانات الآخرين أو الاحتفاظ بها دون إذن.
الإجابة أيوه، وده بالضبط اللي حصل مع ثغرة IDOR/Broken Access Control تم الإبلاغ عنها في HackerOne، واللي انتهت بمكافأة وصلت إلى 15,000 دولار.
الأسبوع اللي فات، ناس كتير شافت تقرير الثغرة، لكن أنا عايز أتكلم عنها من منظور مختلف شوية. مش مجرد شرح تقني للبج، لكن عن طريقة التفكير اللي خلت باحث أمني يكتشف حاجة ممكن تكون عدّت على باحثين كتير من غير ما ياخدوا بالهم منها.
والأهم، إزاي القصة دي بتثبت إن الـ Manual Hunting لسه ليه مكانه، حتى مع انتشار أدوات الذكاء الاصطناعي في مجال الأمن السيبراني.
🔍 إيه قصة ثغرة HackerOne؟
خلينا نبدأ من الأول.لو أنت Bug Bounty Hunter وبتستخدم HackerOne، فأكيد عارف إحساس إنك تبلغ عن ثغرة، وبعد فترة تكتشف إن تقريرك اتقفل باعتباره Duplicate.
طبيعي وقتها يبقى عندك فضول تشوف التقرير الأصلي اللي سبقك، وتعرف الباحث التاني اكتشف إيه أو وصل للثغرة إزاي.
لكن لما بتحاول تفتح تقرير مش مسموح لك تشوفه، بتقابل رسالة الخطأ الشهيرة:
422 Unprocessable Entityوده معناه إنك مش قادر توصل للمحتوى المطلوب بالطريقة دي.
معظمنا بيشوف الرسالة، وبيعتبر إن الموضوع انتهى، ويكمل شغله عادي.
لكن الباحث اللي اكتشف الثغرة دي قرر ميقفش عند النقطة دي.
⚙️ إزاي الباحث اكتشف ثغرة Broken Access Control؟
الفكرة الأساسية كانت بسيطة: بدل ما الباحث يكتفي برسالة الخطأ اللي ظهرت قدامه، قرر يجرب الوصول لنفس المورد باستخدام نوع مختلف من الحسابات.اكتشف إنه يقدر ينشئ حساب VDP على HackerOne، وهو نوع من الحسابات المرتبطة بالمشاركة في برامج Vulnerability Disclosure Program.
بعد إنشاء الحساب، رجع لنفس الـ Endpoint وحاول الوصول للتقرير مرة تانية.
النتيجة الظاهرة كانت تقريبًا زي ما هي، لكن المرة دي الباحث كان بيراقب الاتصال باستخدام Burp Suite.
وهنا ظهرت المفاجأة.
رغم إن واجهة المستخدم كانت بتعرض رسالة خطأ، لاحظ الباحث إن الـ HTTP Response بيحتوي على بيانات التقرير نفسه داخل الحقل:
context.subjectبمعنى إن التطبيق كان بيمنع عرض المحتوى في الواجهة، لكن البيانات الحساسة كانت لسه موجودة في الاستجابة اللي وصلت للعميل.
وده جوهر المشكلة الأمنية: منع المستخدم من مشاهدة البيانات في الواجهة مش معناه بالضرورة إن السيرفر منعه من استلامها.
الثغرة تم الإبلاغ عنها، واتقبلت بتصنيف Critical، ووصلت مكافأتها إلى 15,000 دولار.
🛡️ ليه الثغرة دي مهمة من الناحية التقنية؟
الثغرة بتوضح مشكلة أساسية في تطبيق آليات التحكم في الصلاحيات (Access Control).لما مستخدم يطلب مورد معين، السيرفر المفروض يتحقق من هويته وصلاحياته قبل ما يرجع أي بيانات خاصة بالمورد ده.
مش كفاية إن التطبيق يعرض صفحة خطأ أو يخفي البيانات باستخدام JavaScript.
لو البيانات وصلت بالفعل داخل الـ Response، فإخفاؤها من واجهة المستخدم مش هيحميها من شخص بيفحص حركة الشبكة.
وده بيوضح الفرق بين حاجتين:
- UI Restriction: منع المستخدم من مشاهدة المحتوى داخل واجهة التطبيق.
- Server-Side Authorization: التحقق من صلاحية المستخدم على السيرفر قبل إرسال المحتوى.
ومن المهم كمان نفهم إن ظهور كود
422 لوحده مش دليل على وجود ثغرة. المشكلة الحقيقية هنا كانت في البيانات اللي رجعت داخل الاستجابة رغم عدم امتلاك الحساب صلاحية الوصول إليها.💡 الدرس الأهم: ليه بنستبعد اكتشاف ثغرات في المنصات الكبيرة؟
بعيدًا عن التفاصيل التقنية، فيه نقطة تانية في القصة دي شايف إنها تستحق التفكير.إحنا بنتكلم عن HackerOne، واحدة من أشهر منصات الـ Bug Bounty، واللي بيستخدمها عدد ضخم من الباحثين الأمنيين.
أكيد مش أنا الوحيد اللي حاول قبل كده يفتح تقرير مش بتاعه، وشاف رسالة الخطأ، وبعدها قرر يسيب الموضوع.
لكن السؤال هنا:
ليه أحيانًا بنفترض إن أي حاجة بسيطة في منصة كبيرة أكيد اتعملها Testing قبل كده؟
الفكرة دي كانت بتيجي في بالي كتير.
يعني منصة بالحجم ده، وعندها فريق Security، وبيستخدمها باحثون أمنيون محترفون، ومع وجود أدوات AI وعمليات Security Testing وCode Review، هل منطقي إني أكون الشخص اللي هيكتشف فيها ثغرة؟
أكيد كل حاجة اتجربت قبل كده، صح؟
لكن الحقيقة إن الافتراض ده ممكن يكون واحد من أكبر العوائق اللي بتمنعك تكتشف ثغرات جديدة.
لما اتكلمت مع أكتر من باحث أمني أقدم مني، وعندهم خبرة وبروفايلات محترمة في المجال، كانت نصيحتهم واضحة:
لو هتكمل بنفس طريقة التفكير دي، لازم تغير الـ Methodology بتاعتك.
لأنك كده بتستبعد احتمالات قبل حتى ما تجربها.
🧠 الثغرة مكانتش محتاجة فكرة معقدة
لما تبص على القصة من بعيد، هتلاحظ إن الباحث معملش حاجة خارقة.الفكرة الأساسية اعتمدت على كام نقطة:
- لاحظ سلوك التطبيق لما حاول يوصل لتقرير غير مصرح له بمشاهدته.
- فكر يجرب نوع حساب مختلف.
- رجع يختبر نفس المورد.
- فحص الـ HTTP Response بدل ما يعتمد على النتيجة الظاهرة في المتصفح.
- اكتشف إن البيانات بترجع رغم وجود رسالة خطأ.
وده خلاني أفكر في سؤال مهم:
هل أدوات الـ AI المستخدمة في الاختبارات الأمنية كانت هتكتشف نفس المشكلة؟ وهل مراجعة الكود كانت ممكن تكشف إن فيه بيانات حساسة بتترجع قبل التحقق الصحيح من الصلاحيات؟
ممكن طبعًا، لكن وجود الأدوات أو عمليات المراجعة مش ضمان لاكتشاف كل ثغرة.
أحيانًا تغيير بسيط في زاوية الاختبار بيكشف مشكلة كانت مستخبية وسط سلوك يبدو طبيعيًا.
📋 تقرير قصير ومكافأة 15,000 دولار
الفضول خلاني أدخل أبص على بروفايل الباحث اللي اكتشف الثغرة.لقيت إن حسابه موجود من سنة 2023، وإن الثغرة دي كانت التقرير الوحيد الظاهر على البروفايل وقت ما راجعته.
وده في حد ذاته لفت نظري.
مش شرط يكون عندك مئات التقارير المقبولة أو بروفايل مليان Badges علشان تكتشف ثغرة مؤثرة.
كمان، بحسب التسلسل الزمني اللي ظهر في التقرير:
- تم إرسال التقرير يوم 14.
- بدأ التعامل معاه في مرحلة Triage يوم 15.
- الباحث تلقى طلب Need More Info مرتين.
- الثغرة اتقبلت في النهاية بتصنيف Critical.
- المكافأة وصلت إلى 15,000 دولار.
وده درس مهم لأي حد بيكتب Bug Bounty Reports.
جودة التقرير مش بعدد السطور، لكن بوضوح الثغرة، وإمكانية إعادة إنتاجها، وإثبات تأثيرها الأمني.
مش مطلوب تكتب موضوع تعبير علشان تثبت إنك اكتشفت مشكلة حقيقية.
وفي المقابل، مش معنى إن التقرير قصير إنه بالضرورة أفضل. بعض الثغرات بتحتاج تفاصيل تقنية أكتر، أو خطوات واضحة، أو أدلة إضافية علشان فريق الأمن يقدر يتحقق منها.
المهم إنك تقدم المعلومات المطلوبة من غير حشو.
🤖 هل الذكاء الاصطناعي هيحل محل Manual Bug Bounty Hunting؟
من وجهة نظري، لأ.الذكاء الاصطناعي بقى أداة مهمة جدًا في مجال اختبار الاختراق، وممكن يساعدك في حاجات كتير، زي:
- فهم الـ Application Logic وتحليل سلوك التطبيق.
- مراجعة أجزاء من الكود والبحث عن أخطاء محتملة.
- اقتراح Test Cases وسيناريوهات اختبار مختلفة.
- تحليل الاستجابات ومقارنة النتائج.
- تنظيم الملاحظات والمساعدة في كتابة التقارير.
الثغرة دي مثال كويس على قيمة الفضول البشري.
الباحث شاف رسالة خطأ، لكنه قرر يسأل نفسه: طب إيه اللي ممكن يحصل لو جربت حساب مختلف؟ وهل الاستجابة نفسها بتحتوي على حاجة مش ظاهرة في الصفحة؟
النوع ده من التفكير مهم جدًا في الـ Business Logic وAccess Control Testing.
وده مش معناه إن أدوات الذكاء الاصطناعي مستحيل تكتشف ثغرات مشابهة، لكن معناه إن الاعتماد على الأتمتة وحدها ممكن يخليك تفوّت سيناريوهات مهمة.
استخدم AI كأداة بتقوّي شغلك، مش كبديل عن فهمك للتطبيق وطريقة تفكيرك كباحث أمني.
🎯 إيه اللي ممكن تتعلمه من القصة دي كـ Bug Bounty Hunter؟
لو أنت لسه بتبدأ في المجال، أو حتى بقالك فترة وحاسس إن كل حاجة اتجربت قبل كده، فيه شوية دروس تستحق تفتكرها:1. متستبعدش هدف لمجرد إنه مشهور
كبر حجم الشركة أو وجود فريق أمني قوي مش معناه إن التطبيق خالي من الثغرات.
2. افهم التطبيق قبل ما تبدأ تختبره
كل ما فهمت أنواع الحسابات والصلاحيات وطريقة تعامل التطبيق مع البيانات، هتقدر تبني سيناريوهات اختبار أفضل.
3. متعتمدش على واجهة المستخدم فقط
في الاختبارات المصرح بها، راجع الـ Requests والـ Responses، وافهم الفرق بين النتيجة اللي بتظهر للمستخدم والبيانات اللي بيرجعها السيرفر.
4. جرّب سيناريوهات مختلفة للصلاحيات
اختلاف نوع الحساب أو الدور الوظيفي ممكن يكشف مشاكل في تطبيق قواعد الـ Authorization. وطبعًا لازم كل الاختبارات تكون داخل النطاق المسموح به في البرنامج.
5. متقيسش قيمة اكتشافك بتعقيد الثغرة
مش كل ثغرة Critical محتاجة سلسلة استغلال معقدة. أحيانًا خطأ بسيط في التحكم بالصلاحيات بيكون تأثيره كبير جدًا.
6. اكتب تقرير واضح بدل ما تكتب تقرير طويل
وضح المشكلة، وخطوات إعادة إنتاجها، والنتيجة المتوقعة والفعلية، والتأثير الأمني، مع الالتزام بسياسات البرنامج.
❤️ كلمة أخيرة لكل حد بيشتغل في الـ Bug Bounty
الـ Manual Hunting أو الـ Old School Style لسه ليه مكانه، وهيفضل مهم حتى مع تطور أدوات الذكاء الاصطناعي.آه، اكتشاف الثغرات مش بنفس سهولة زمان، والمنافسة بقت أكبر، لكن ده مش معناه إن الفرص انتهت.
أحيانًا كل اللي محتاجه إنك تبص على حاجة مألوفة من زاوية مختلفة، أو تسأل سؤال محدش فكر يسأله، أو متكتفيش بالنتيجة الظاهرة قدامك.
متشغلش بالك بإن غيرك أكيد اختبر كل حاجة قبلك.
ذاكر، واشتغل على الـ Methodology بتاعتك، وافهم التطبيقات اللي بتختبرها، واستخدم الأدوات الحديثة علشان تطور شغلك من غير ما تتخلى عن تفكيرك.
وافتكر دايمًا:
مش لازم تكون أقدم Hunter في المجال علشان تكتشف ثغرة حقيقية. المهم إنك متبطلش تفكر وتجرب وتتعلم.
ربنا يوفق كل واحد بيجتهد في المجال، وإن شاء الله تعبك يجيب نتيجة.
📎 رابط تقرير الثغرة الأصلي على HackerOne:
https://hackerone.com/reports/3862641
ملحوظة: أي اختبار متعلق بالتحكم في الصلاحيات أو الوصول للبيانات لازم يتم داخل نطاق مصرح به، مع تجنب الاطلاع على بيانات الآخرين أو الاحتفاظ بها دون إذن.