- بواسطة x32x01 ||
من فترة بدأت أتعمق أكتر في استخدام الذكاء الاصطناعي في Bug Hunting، وكنت مهتم بشكل خاص بفكرة مختلفة عن مجرد استخدام ChatGPT أو Claude كمساعد.
الفكرة كانت: ماذا لو خليت AI Agent هو اللي ينفذ جزء من عملية اختبار الـWeb Applications بدل ما أشرح له كل خطوة بنفسي؟
بدأت أجرب OpenCode، ومع شوية إعدادات وربطه بأدوات الـSecurity Testing، وصلت لتجربة كانت بالنسبة لي مثيرة جدًا.
النتيجة؟ الـAgent قدر يكتشف ثغرات فعلية في بيئة اختبار، وفي تجربة أخرى قدر يوصل إلى Open Redirect كنت قد اكتشفتها يدويًا من قبل، بدون ما أشرح له طريقة اكتشافها.
لكن قبل ما ندخل في التجربة، خلينا نفهم الأول الفرق بين الـAI Assistant والـAI Agent.
لو طلبت من ChatGPT مثلًا كتابة Email، فهو يستطيع كتابة الرسالة لك، لكن في الوضع التقليدي أنت من يقوم بنسخها وإرسالها.
أما الـAI Agent فالفكرة مختلفة.
الـAgent يمكنه استخدام مجموعة من Tools والتعامل مع Environment معينة لتنفيذ Workflow متعدد الخطوات.
بمعنى أبسط:
AI Assistant: يفهم طلبك ويعطيك إجابة أو اقتراحًا.
AI Agent: يفهم الهدف، يخطط للخطوات، ويستخدم الأدوات المتاحة لتنفيذ المهمة.
وده فرق مهم جدًا لما نتكلم عن Bug Hunting.
لأن اختبار Web Application غالبًا مش مجرد سؤال وإجابة.
أنت محتاج:
الـModel هو العقل الذي يقوم بعملية الـReasoning وفهم الـInstructions وتحديد الخطوة التالية.
ممكن تتخيل الموضوع بالشكل ده:
AI Model + Agent + Tools + Environment = Workflow قابل للتنفيذ
فالـModel هو الذي يفكر ويحلل، بينما الـAgent يوفر له القدرة على استخدام الأدوات وتنفيذ الخطوات داخل البيئة المتاحة له.
وده سبب مهم يخلي اختيار الـModel وحده مش كافي.
لأنك ممكن تستخدم Model قوي جدًا، لكن لو الـAgent مش قادر يتعامل مع الأدوات التي يحتاجها، فجزء كبير من الفائدة سيضيع.
الفكرة كانت إني أضيف له مجموعة من الـSkills والـInstructions المرتبطة باختبار تطبيقات الويب.
الـSkills هنا مهمة لأنها تساعد الـAgent على اتباع منهجية أكثر تنظيمًا بدل ما يتعامل مع المهمة بشكل عشوائي.
مثلًا، لو الهدف هو اختبار وجود XSS في بيئة مصرح باختبارها، فالـAgent يمكن توجيهه للبحث عن:
وده تحديدًا هو الجزء اللي كنت عايز أجربه.
لو أنا أصلًا بستخدم Burp Suite أثناء الـBug Hunting، ليه أفضل أنقل الـRequests يدويًا من Burp إلى الـAI؟
الـWorkflow التقليدي ممكن يكون بالشكل ده:
Browser → Burp → Copy Request → AI → Analysis → Burp → Test
وده مع عدد كبير من الـRequests ممكن يتحول لشغل يدوي متكرر جدًا.
فبدل ما أكون أنا حلقة الوصل بين الـAgent وBurp، قررت أخلي الـAgent يتعامل مع Burp مباشرة.
استخدمت MCP كحلقة وصل بين OpenCode وBurp Suite، بحيث أصبح الـAgent قادرًا على التعامل مع البيانات والأدوات التي يوفرها التكامل.
وهنا بدأت التجربة الحقيقية.
استخدمت Web Application تجريبية تحتوي على XSS، وشغلت Burp Suite وبدأت أتصفح الـApplication بشكل طبيعي حتى تظهر الـRequests داخل HTTP History.
بعدها أعطيت الـAgent المهمة بشكل عام:
حلل الـRequests الموجودة في Burp وابحث عن XSS.
اللي حصل كان مثير للاهتمام.
الـAgent بدأ يتعامل مع الـRequests الموجودة، ويستخدم الـSkills المتعلقة باختبار XSS، ويحلل نقاط الإدخال ويراجع النتائج.
الأهم بالنسبة لي أني لم أكن مضطرًا أن أمسك كل Request وأقول له:
وبعد فترة قصيرة تمكن من تحديد Reflected XSS في البيئة التجريبية، ثم قام بتوثيق النتيجة وكتابة تقرير يوضح نقطة الضعف وطريقة التحقق منها.
بالنسبة لي، كانت دي أول إشارة فعلية إن الفكرة مش مجرد Demo شكله حلو.
لكن طبعًا كان السؤال التالي:
هل يستطيع الـAgent اكتشاف شيء أكثر تعقيدًا بدون أن أشرح له أنا الثغرة؟
استخدمت Target لديه Bug Bounty Program وكنت قد اختبرته يدويًا من قبل.
وبالطبع، اختبار أي Target حقيقي لازم يكون داخل نطاق البرنامج ووفق الـScope والقواعد المسموح بها.
الثغرة التي كنت قد وجدتها سابقًا كانت Open Redirect.
وهي ثغرة قد تبدو بسيطة، وغالبًا يكون تأثيرها محدودًا، لكن أهميتها تعتمد بشكل كبير على طريقة استخدام الـRedirect داخل الـApplication.
وفي بعض الحالات، يمكن أن تدخل ضمن Chain أكبر مع ثغرات أخرى.
لكن في الحالة التي كنت أختبرها، لم أتمكن من الوصول إلى Impact أعلى، وبالتالي كانت النتيجة في النهاية Low.
من الأنماط التي أحب مراجعتها في التطبيقات التي تحتوي على Authentication هو Login Redirect Flow.
مثلًا، المستخدم يكون داخل صفحة تحتاج Authentication، وبعد تسجيل الخروج ومحاولة الوصول إليها مرة أخرى، يقوم الموقع بتحويله إلى Login Page مع الاحتفاظ بالمسار الذي كان يحاول الوصول إليه.
بشكل مبسط، الـFlow يكون:
Protected Page → Login → Authentication → العودة إلى الصفحة الأصلية
مثل:
ثم بعد تسجيل الدخول يعود المستخدم إلى:
وده سلوك طبيعي ومفيد جدًا في تجربة المستخدم.
لكن من منظور Security Testing، السؤال هنا هو:
هل الـRedirect destination يتم التحقق منه بشكل صحيح؟
فإذا كان الـApplication يقبل وجهة Redirect يمكن للمستخدم التحكم فيها، يجب التأكد من أنها لا تسمح بتحويل المستخدم إلى Domain خارجي غير موثوق.
وفي الاختبار اليدوي الذي قمت به، لاحظت أن الـApplication يحتفظ بالمسار في Parameter مشفر باستخدام Base64.
بعد فك القيمة، ظهر المسار الأصلي الذي كنت أحاول الوصول إليه.
وهنا أصبحت نقطة الاختبار واضحة:
هل الـApplication يتعامل مع القيمة باعتبارها مجرد Internal Path؟
أم يمكن التلاعب بها بحيث تصبح وجهة خارجية؟
في بيئة مصرح باختبارها، تم التحقق من أن تغيير قيمة الوجهة إلى عنوان خارجي يؤدي في النهاية إلى Redirect خارجي بعد إتمام عملية تسجيل الدخول.
وهكذا تأكدت من وجود Open Redirect.
المرة دي قررت ما أشرحش للـAgent الـPattern اللي أنا استخدمته.
وما قلتلوش:
ببساطة أعطيته الـTarget المسموح باختباره وطلبت منه البحث عن Open Redirect.
وبعدها سبته يشتغل.
وهنا كانت المفاجأة.
الـAgent قدر يوصل إلى نفس الثغرة التي كنت قد اكتشفتها يدويًا.
والأكثر إثارة للاهتمام أنه لم يتوقف عند إثبات الـOpen Redirect فقط.
بدأ أيضًا يحاول التفكير في احتمالات وجود Impact أكبر أو إمكانية عمل Chain مع سيناريوهات أخرى، مثل ATO أو SSRF، بحسب ما تسمح به طبيعة الـApplication.
في النهاية لم يكن هناك Impact أعلى في الحالة التي اختبرتها، وبالتالي تظل الثغرة Low.
لكن بالنسبة لي، قيمة التجربة لم تكن في Severity نفسها.
القيمة كانت في أن الـAgent وصل إلى النتيجة بدون أن أعطيه الـDiscovery Path الذي اتبعته أنا يدويًا.
الأقرب للواقع أنه Force Multiplier.
يعني بدل ما الباحث يقضي جزء كبير من وقته في المهام المتكررة، يقدر يخلي الـAgent يتولى جزءًا منها، بينما يركز هو على الأجزاء التي تحتاج فهمًا أعمق.
مثل:
لأن اكتشاف وجود Parameter قابل للـRedirect مثلًا شيء، وفهم هل الثغرة يمكن أن تتحول إلى Impact أكبر داخل Application معين شيء آخر تمامًا.
الـAgent ممكن يساعدك جدًا في الجزء الأول.
لكن الجزء الثاني قد يحتاج فهمًا بشريًا للـBusiness Logic وطريقة تصميم الـApplication.
مثل:
الـAgent ممتاز في تنفيذ Workflow متكرر، لكنه لا يمتلك بالضرورة الفهم الكامل للسياق الذي يمتلكه الباحث.
ممكن تديه نتيجة غريبة جدًا في الـResponse ويعتبرها غير مهمة.
بينما الباحث الذي فاهم الـApplication يعرف أن النتيجة دي مرتبطة بـBusiness Logic أخرى ويمكن أن تكون بداية لثغرة أكبر.
وكذلك ممكن الـAgent يجد Open Redirect، لكن تحديد هل هي مجرد Low أم جزء من Chain أخطر يحتاج تحليلًا أوسع.
لذلك أنا شايف أن أفضل نموذج حاليًا هو:
Human + AI Agent
وليس:
Human vs AI Agent
الفرق الحقيقي هو الوصول إلى الأدوات والبيئة.
لو كنت تستخدم ChatGPT بشكل تقليدي، غالبًا ستقوم أنت بجمع الـRequest ثم إرساله للـAI.
أما في Workflow يعتمد على Agent، فيمكن للـAgent استخدام الأدوات المتاحة له، قراءة النتائج، اتخاذ قرار بالخطوة التالية، ثم تنفيذها.
وبالتالي يصبح الـAI جزءًا من عملية الاختبار نفسها بدل ما يكون مجرد Chat Window بجانب Burp.
وده في رأيي هو الاتجاه الأكثر إثارة للاهتمام في استخدام الـAI داخل Security Testing.
لازم يكون عندك:
وفي النهاية الباحث هو المسؤول عن الـWorkflow والنتيجة.
الفكرة مش أني أقول للـAI:
الفكرة الأكبر هي إني أخليه جزء من الـTesting Workflow نفسه.
OpenCode + AI Model + Skills + Burp Suite + MCP
ممكن يحولوا مجموعة من المهام التي كانت تحتاج تدخل يدوي مستمر إلى Workflow شبه مستقل.
والتجربة الأهم بالنسبة لي كانت أن الـAgent قدر يكتشف Open Redirect كنت قد وجدتها يدويًا، بدون ما أشرح له الـPattern الذي استخدمته للوصول إليها.
هل ده معناه أن الـAI هيستبدل Bug Hunters ؟
أكيد لا.
لكن هل ممكن يوفر وقت ضخم في المهام التي تعتمد على التكرار؟
أعتقد أن الإجابة نعم.
وده بالضبط الجزء اللي شدني للموضوع.
لأن لو الـAgent يقدر يتولى جزء من الاختبارات المتكررة، الباحث يقدر يوفر طاقته للحاجات الأصعب: Business Logic، فهم الـApplication، الـChaining، وتحليل الـImpact الحقيقي.
وعشان كده، الموضوع ده ساحلني بقالي فترة، وناوي أدوس فيه أكتر الفترة الجاية. 🚀
الفكرة كانت: ماذا لو خليت AI Agent هو اللي ينفذ جزء من عملية اختبار الـWeb Applications بدل ما أشرح له كل خطوة بنفسي؟
بدأت أجرب OpenCode، ومع شوية إعدادات وربطه بأدوات الـSecurity Testing، وصلت لتجربة كانت بالنسبة لي مثيرة جدًا.
النتيجة؟ الـAgent قدر يكتشف ثغرات فعلية في بيئة اختبار، وفي تجربة أخرى قدر يوصل إلى Open Redirect كنت قد اكتشفتها يدويًا من قبل، بدون ما أشرح له طريقة اكتشافها.
لكن قبل ما ندخل في التجربة، خلينا نفهم الأول الفرق بين الـAI Assistant والـAI Agent.
ما الفرق بين AI Assistant وAI Agent؟
الفرق الأساسي هو القدرة على تنفيذ المهام.لو طلبت من ChatGPT مثلًا كتابة Email، فهو يستطيع كتابة الرسالة لك، لكن في الوضع التقليدي أنت من يقوم بنسخها وإرسالها.
أما الـAI Agent فالفكرة مختلفة.
الـAgent يمكنه استخدام مجموعة من Tools والتعامل مع Environment معينة لتنفيذ Workflow متعدد الخطوات.
بمعنى أبسط:
AI Assistant: يفهم طلبك ويعطيك إجابة أو اقتراحًا.
AI Agent: يفهم الهدف، يخطط للخطوات، ويستخدم الأدوات المتاحة لتنفيذ المهمة.
وده فرق مهم جدًا لما نتكلم عن Bug Hunting.
لأن اختبار Web Application غالبًا مش مجرد سؤال وإجابة.
أنت محتاج:
- تتصفح الـApplication.
- تجمع الـRequests.
- تحدد نقاط الـInput.
- تختبر سلوك الـParameters.
- تقارن الـResponses.
- تعيد الاختبار بأشكال مختلفة.
- وتحاول تربط النتائج ببعضها.
الـAI Model والـAI Agent: مين بيعمل إيه؟
بعد تثبيت OpenCode، كان عندي الـAgent، لكن كان ناقص أهم عنصر: الـAI Model.الـModel هو العقل الذي يقوم بعملية الـReasoning وفهم الـInstructions وتحديد الخطوة التالية.
ممكن تتخيل الموضوع بالشكل ده:
AI Model + Agent + Tools + Environment = Workflow قابل للتنفيذ
فالـModel هو الذي يفكر ويحلل، بينما الـAgent يوفر له القدرة على استخدام الأدوات وتنفيذ الخطوات داخل البيئة المتاحة له.
وده سبب مهم يخلي اختيار الـModel وحده مش كافي.
لأنك ممكن تستخدم Model قوي جدًا، لكن لو الـAgent مش قادر يتعامل مع الأدوات التي يحتاجها، فجزء كبير من الفائدة سيضيع.
تجهيز OpenCode للـBug Hunting
بعد كده بدأت أجرب استخدام OpenCode في Cybersecurity وBug Hunting.الفكرة كانت إني أضيف له مجموعة من الـSkills والـInstructions المرتبطة باختبار تطبيقات الويب.
الـSkills هنا مهمة لأنها تساعد الـAgent على اتباع منهجية أكثر تنظيمًا بدل ما يتعامل مع المهمة بشكل عشوائي.
مثلًا، لو الهدف هو اختبار وجود XSS في بيئة مصرح باختبارها، فالـAgent يمكن توجيهه للبحث عن:
- User Inputs.
- Parameters.
- أماكن انعكاس البيانات.
- اختلافات الـHTTP Responses.
- احتمالات الـClient-side وServer-side processing.
- السلوك الناتج عن المدخلات المختلفة.
ثم:
ثم:
يقدر الـAgent يتعامل مع سلسلة من الخطوات بنفسه، طالما الأدوات والصلاحيات اللازمة متاحة له.
وده تحديدًا هو الجزء اللي كنت عايز أجربه.
لماذا ربطت OpenCode مع Burp Suite؟
هنا ظهر عندي سؤال مهم:لو أنا أصلًا بستخدم Burp Suite أثناء الـBug Hunting، ليه أفضل أنقل الـRequests يدويًا من Burp إلى الـAI؟
الـWorkflow التقليدي ممكن يكون بالشكل ده:
Browser → Burp → Copy Request → AI → Analysis → Burp → Test
وده مع عدد كبير من الـRequests ممكن يتحول لشغل يدوي متكرر جدًا.
فبدل ما أكون أنا حلقة الوصل بين الـAgent وBurp، قررت أخلي الـAgent يتعامل مع Burp مباشرة.
استخدمت MCP كحلقة وصل بين OpenCode وBurp Suite، بحيث أصبح الـAgent قادرًا على التعامل مع البيانات والأدوات التي يوفرها التكامل.
وهنا بدأت التجربة الحقيقية.
تجربة AI Agent مع XSS
في البداية لم أرد اختبار الفكرة مباشرة على برنامج Bug Bounty حقيقي.استخدمت Web Application تجريبية تحتوي على XSS، وشغلت Burp Suite وبدأت أتصفح الـApplication بشكل طبيعي حتى تظهر الـRequests داخل HTTP History.
بعدها أعطيت الـAgent المهمة بشكل عام:
حلل الـRequests الموجودة في Burp وابحث عن XSS.
اللي حصل كان مثير للاهتمام.
الـAgent بدأ يتعامل مع الـRequests الموجودة، ويستخدم الـSkills المتعلقة باختبار XSS، ويحلل نقاط الإدخال ويراجع النتائج.
الأهم بالنسبة لي أني لم أكن مضطرًا أن أمسك كل Request وأقول له:
أو:
الـAgent كان يتعامل مع المهمة كـWorkflow متكامل.
وبعد فترة قصيرة تمكن من تحديد Reflected XSS في البيئة التجريبية، ثم قام بتوثيق النتيجة وكتابة تقرير يوضح نقطة الضعف وطريقة التحقق منها.
بالنسبة لي، كانت دي أول إشارة فعلية إن الفكرة مش مجرد Demo شكله حلو.
لكن طبعًا كان السؤال التالي:
هل يستطيع الـAgent اكتشاف شيء أكثر تعقيدًا بدون أن أشرح له أنا الثغرة؟
تجربة Open Redirect على Target ضمن Bug Bounty
هنا قررت أصعّد التجربة.استخدمت Target لديه Bug Bounty Program وكنت قد اختبرته يدويًا من قبل.
وبالطبع، اختبار أي Target حقيقي لازم يكون داخل نطاق البرنامج ووفق الـScope والقواعد المسموح بها.
الثغرة التي كنت قد وجدتها سابقًا كانت Open Redirect.
وهي ثغرة قد تبدو بسيطة، وغالبًا يكون تأثيرها محدودًا، لكن أهميتها تعتمد بشكل كبير على طريقة استخدام الـRedirect داخل الـApplication.
وفي بعض الحالات، يمكن أن تدخل ضمن Chain أكبر مع ثغرات أخرى.
لكن في الحالة التي كنت أختبرها، لم أتمكن من الوصول إلى Impact أعلى، وبالتالي كانت النتيجة في النهاية Low.
كيف اكتشفت الـOpen Redirect يدويًا؟
قبل ما أجرب الـAgent، خليني أوضح الفكرة العامة التي اتبعتها أثناء الاختبار اليدوي.من الأنماط التي أحب مراجعتها في التطبيقات التي تحتوي على Authentication هو Login Redirect Flow.
مثلًا، المستخدم يكون داخل صفحة تحتاج Authentication، وبعد تسجيل الخروج ومحاولة الوصول إليها مرة أخرى، يقوم الموقع بتحويله إلى Login Page مع الاحتفاظ بالمسار الذي كان يحاول الوصول إليه.
بشكل مبسط، الـFlow يكون:
Protected Page → Login → Authentication → العودة إلى الصفحة الأصلية
مثل:
/accountثم بعد تسجيل الدخول يعود المستخدم إلى:
/accountوده سلوك طبيعي ومفيد جدًا في تجربة المستخدم.
لكن من منظور Security Testing، السؤال هنا هو:
هل الـRedirect destination يتم التحقق منه بشكل صحيح؟
فإذا كان الـApplication يقبل وجهة Redirect يمكن للمستخدم التحكم فيها، يجب التأكد من أنها لا تسمح بتحويل المستخدم إلى Domain خارجي غير موثوق.
وفي الاختبار اليدوي الذي قمت به، لاحظت أن الـApplication يحتفظ بالمسار في Parameter مشفر باستخدام Base64.
بعد فك القيمة، ظهر المسار الأصلي الذي كنت أحاول الوصول إليه.
وهنا أصبحت نقطة الاختبار واضحة:
هل الـApplication يتعامل مع القيمة باعتبارها مجرد Internal Path؟
أم يمكن التلاعب بها بحيث تصبح وجهة خارجية؟
في بيئة مصرح باختبارها، تم التحقق من أن تغيير قيمة الوجهة إلى عنوان خارجي يؤدي في النهاية إلى Redirect خارجي بعد إتمام عملية تسجيل الدخول.
وهكذا تأكدت من وجود Open Redirect.
هل يستطيع الـAI Agent اكتشاف نفس الثغرة؟
وده كان الجزء الذي كنت متحمس له فعلًا.المرة دي قررت ما أشرحش للـAgent الـPattern اللي أنا استخدمته.
وما قلتلوش:
ولا قلت له:
ولا أعطيته الـRequest الذي يحتوي على الثغرة.
ببساطة أعطيته الـTarget المسموح باختباره وطلبت منه البحث عن Open Redirect.
وبعدها سبته يشتغل.
وهنا كانت المفاجأة.
الـAgent قدر يوصل إلى نفس الثغرة التي كنت قد اكتشفتها يدويًا.
والأكثر إثارة للاهتمام أنه لم يتوقف عند إثبات الـOpen Redirect فقط.
بدأ أيضًا يحاول التفكير في احتمالات وجود Impact أكبر أو إمكانية عمل Chain مع سيناريوهات أخرى، مثل ATO أو SSRF، بحسب ما تسمح به طبيعة الـApplication.
في النهاية لم يكن هناك Impact أعلى في الحالة التي اختبرتها، وبالتالي تظل الثغرة Low.
لكن بالنسبة لي، قيمة التجربة لم تكن في Severity نفسها.
القيمة كانت في أن الـAgent وصل إلى النتيجة بدون أن أعطيه الـDiscovery Path الذي اتبعته أنا يدويًا.
ماذا تعلمت من التجربة؟
أعتقد أن أهم نقطة خرجت بها هي أن الـAI Agent مش بالضرورة بديل عن الباحث الأمني.الأقرب للواقع أنه Force Multiplier.
يعني بدل ما الباحث يقضي جزء كبير من وقته في المهام المتكررة، يقدر يخلي الـAgent يتولى جزءًا منها، بينما يركز هو على الأجزاء التي تحتاج فهمًا أعمق.
مثل:
- Business Logic.
- فهم الـApplication Architecture.
- تحليل الـAuthentication والـAuthorization.
- اكتشاف العلاقات بين أكثر من Feature.
- فهم الـWorkflows المعقدة.
- تحليل الـImpact الحقيقي للثغرة.
- التفكير في Attack Chains.
- التعامل مع الحالات التي تحتاج Context كبير.
لأن اكتشاف وجود Parameter قابل للـRedirect مثلًا شيء، وفهم هل الثغرة يمكن أن تتحول إلى Impact أكبر داخل Application معين شيء آخر تمامًا.
الـAgent ممكن يساعدك جدًا في الجزء الأول.
لكن الجزء الثاني قد يحتاج فهمًا بشريًا للـBusiness Logic وطريقة تصميم الـApplication.
أين يمكن أن يكون AI Agent مفيدًا في Bug Hunting؟
من واقع التجربة، أكثر الأماكن التي أرى أن الـAgents يمكن أن توفر فيها وقتًا هي المهام التي تحتوي على تكرار كبير.مثل:
Reconnaissance
جمع المعلومات الأولية وتنظيمها وتحليل النتائج.Request Analysis
مراجعة عدد كبير من HTTP Requests والبحث عن Patterns أو Parameters مثيرة للاهتمام.Parameter Testing
اختبار المدخلات المختلفة ومقارنة الـResponses في بيئة مصرح بها.Vulnerability Triage
المساعدة في ترتيب النتائج وتحديد الأشياء التي تستحق تحقيقًا أعمق.Repetitive Testing
إعادة نفس مجموعة الاختبارات على Endpoints أو Parameters متعددة.Documentation
تحويل النتائج إلى تقرير مرتب يحتوي على:- Description.
- Steps to Reproduce.
- Evidence.
- Expected Behavior.
- Actual Behavior.
- Security Impact.
لكن هل الـAI Agent يستطيع استبدال Bug Hunter؟
لا، وده مش الاستنتاج اللي خرجت به من التجربة.الـAgent ممتاز في تنفيذ Workflow متكرر، لكنه لا يمتلك بالضرورة الفهم الكامل للسياق الذي يمتلكه الباحث.
ممكن تديه نتيجة غريبة جدًا في الـResponse ويعتبرها غير مهمة.
بينما الباحث الذي فاهم الـApplication يعرف أن النتيجة دي مرتبطة بـBusiness Logic أخرى ويمكن أن تكون بداية لثغرة أكبر.
وكذلك ممكن الـAgent يجد Open Redirect، لكن تحديد هل هي مجرد Low أم جزء من Chain أخطر يحتاج تحليلًا أوسع.
لذلك أنا شايف أن أفضل نموذج حاليًا هو:
Human + AI Agent
وليس:
Human vs AI Agent
ما الذي يجعل هذه التجربة مختلفة عن استخدام ChatGPT؟
الفرق مش في أن الـAI أصبح "أذكى" فقط.الفرق الحقيقي هو الوصول إلى الأدوات والبيئة.
لو كنت تستخدم ChatGPT بشكل تقليدي، غالبًا ستقوم أنت بجمع الـRequest ثم إرساله للـAI.
أما في Workflow يعتمد على Agent، فيمكن للـAgent استخدام الأدوات المتاحة له، قراءة النتائج، اتخاذ قرار بالخطوة التالية، ثم تنفيذها.
وبالتالي يصبح الـAI جزءًا من عملية الاختبار نفسها بدل ما يكون مجرد Chat Window بجانب Burp.
وده في رأيي هو الاتجاه الأكثر إثارة للاهتمام في استخدام الـAI داخل Security Testing.
أهم شيء: لا تثق في الـAgent بشكل أعمى
رغم أن التجربة كانت ناجحة، إلا أن وجود AI Agent في الـSecurity Testing لا يعني أنك تسيبه يعمل بدون رقابة.لازم يكون عندك:
- Target مصرح باختباره.
- Scope واضح.
- Rate Limits مناسبة.
- بيئة اختبار عندما يكون ذلك ممكنًا.
- مراجعة بشرية للنتائج.
- عدم تنفيذ اختبارات قد تسبب ضررًا للـApplication أو بيانات المستخدمين.
- التأكد من النتائج قبل إرسال أي Bug Report.
وفي النهاية الباحث هو المسؤول عن الـWorkflow والنتيجة.
الخلاصة
التجربة دي غيرت بالنسبة لي طريقة التفكير في استخدام الـAI في Bug Hunting.الفكرة مش أني أقول للـAI:
وأستنى الإجابة.
الفكرة الأكبر هي إني أخليه جزء من الـTesting Workflow نفسه.
OpenCode + AI Model + Skills + Burp Suite + MCP
ممكن يحولوا مجموعة من المهام التي كانت تحتاج تدخل يدوي مستمر إلى Workflow شبه مستقل.
والتجربة الأهم بالنسبة لي كانت أن الـAgent قدر يكتشف Open Redirect كنت قد وجدتها يدويًا، بدون ما أشرح له الـPattern الذي استخدمته للوصول إليها.
هل ده معناه أن الـAI هيستبدل Bug Hunters ؟
أكيد لا.
لكن هل ممكن يوفر وقت ضخم في المهام التي تعتمد على التكرار؟
أعتقد أن الإجابة نعم.
وده بالضبط الجزء اللي شدني للموضوع.
لأن لو الـAgent يقدر يتولى جزء من الاختبارات المتكررة، الباحث يقدر يوفر طاقته للحاجات الأصعب: Business Logic، فهم الـApplication، الـChaining، وتحليل الـImpact الحقيقي.
وعشان كده، الموضوع ده ساحلني بقالي فترة، وناوي أدوس فيه أكتر الفترة الجاية. 🚀
التعديل الأخير: