اختبار OpenAI Daybreak Blue: اكتشاف أمني حقيقي في موقع إلكتروني
اكتشف اختبار OpenAI Daybreak Blue الذي أجريته مشكلة أمنية في موقعي الإلكتروني الإنتاجي، وتمكنت من إعادة إنتاجها في متصفح جديد: ظلت صفحة تسجيل الدخول تستخدم HTTP بدلًا من إعادة التوجيه إلى HTTPS. كما حمّلت الصفحة 20 موردًا من الطرف الأول عبر الاتصال غير المشفر نفسه.
كانت النتيجة مفيدة لسبب واضح. لم يحتج النموذج إلى استغلال معقد لإنتاج اكتشاف ذي قيمة. فقد حدد خللًا أساسيًا في النقل، وصنّفه، وقدم ادعاءً محددًا يمكنني التحقق منه. كما وجد اختبار مستقل مرجعي المشكلة الأساسية نفسها.
كان هذا تقييمًا مصرحًا به وغير تدميري لخدمة Mixanalytic التي أملكها. لم أرسل بيانات اعتماد، ولم أسجل الدخول، ولم أستغل الموقع، ولم أغيّر البيانات، ولم أحاول إنشاء آلية استمرار.
لماذا اختبرت Daybreak Blue على موقع إلكتروني حقيقي
غالبًا ما تستخدم عروض نماذج الأمان عينات برمجية مُعدّة مسبقًا أو مختبرات معروفة الثغرات. هذه الاختبارات مضبوطة، لكنها لا توضح كيفية تعامل النموذج مع نظام إنتاج عادي ذي سياق غير مكتمل.
أردت إجراء اختبار أضيق نطاقًا مع شرط نجاح واضح: هل يستطيع النموذج فحص السطح العام لموقع أملكه، والعثور على مشكلة قابلة لإعادة الإنتاج، والفصل بين الأدلة والتكهنات؟
كما أردت مقارنة نتيجته باختبار مرجعي مستقل. لقد اختبرت أنظمة AI أخرى باستخدام نهج مشابه يركز على الأدلة في اختبار أمان روبوت الدردشة AI الخاص بالحجوزات→، حيث كانت النتيجة المفيدة تغييرًا هندسيًا تم التحقق منه، لا قصة هجوم درامية.
ما النموذج الذي شغّلته فعليًا؟
أُجري التقييم الأول في عامل Codex منفصل مخصص لمعرّف النموذج `gpt-daybreak-blue-latest`. وتطلق وثائق OpenAI على العرض المعتمد اسم GPT-Daybreak-Blue.
هذا التمييز مهم. فتغيير النموذج المحدد في محادثة لاحقة لا يحوّل بأثر رجعي تشغيلًا سابقًا إلى اختبار Daybreak. يجب أن يستخدم التنفيذ الذي يجري التقييم نموذج Daybreak المعتمد وواجهة المنتج المعتمدة.
تصف OpenAI نموذج Daybreak Blue بأنه نقطة البداية لمعظم الأعمال الدفاعية المصرح بها، بما في ذلك اكتشاف الثغرات، ومراجعة الكود الآمن، ونمذجة التهديدات، وهندسة الكشف، والاستجابة للحوادث، والتحقق من التصحيحات. كما توصي الشركة بالبيئات المضبوطة، وصلاحيات أقل امتيازًا، ونطاق محدد، ومراجعة بشرية للإجراءات الحساسة (Models and Trusted Access).
إعداد اختبار OpenAI Daybreak Blue ونطاقه
منحت النموذج إذنًا لفحص Mixanalytic وملفات المشروع المحلية. وأبقيت الفحوصات الخارجية غير تدميرية:
لم يُسمح للنموذج بإرسال نموذج تسجيل الدخول، أو اختبار بيانات اعتماد حقيقية، أو إنشاء حسابات، أو رفع حمولات، أو استغلال ضعف مشتبه به، أو تعديل بيئة الإنتاج.
جعل هذا الحد النتيجة أسهل في التفسير. إذ كان يجب أن يستند كل اكتشاف إلى سلوك عام أو أدلة مصدر للقراءة فقط.
الاكتشاف الرئيسي: ظلت صفحة تسجيل الدخول تستخدم HTTP
أظهر الفحص بالصندوق الأسود أن كلًا من جذر الموقع ومسار تسجيل الدخول أعادا `200 OK` عبر HTTP. ولم تُعد أي من الاستجابتين توجيه المتصفح إلى HTTPS.
ثم فتحت صفحة تسجيل الدخول في سياق Chromium جديد. ظل المتصفح على عنوان URL يبدأ بـ `http://` أثناء عرض حقلي اسم المستخدم وكلمة المرور. وخلال تحميل الصفحة، استخدمت أيضًا 20 طلبًا من الطرف الأول لملفات JavaScript وCSS والصور والمستندات بروتوكول HTTP.
| الفحص | النتيجة المرصودة |
|---|---|
| --- | --- |
| إعادة توجيه HTTP | لم تحدث إعادة توجيه إلى HTTPS على الجذر أو صفحة تسجيل الدخول اللذين تم اختبارهُما |
| متصفح جديد | ظل Chromium على صفحة تسجيل الدخول عبر HTTP |
| موارد الطرف الأول | حُمّلت 20 طلبًا عبر HTTP خلال تشغيل المتصفح |
| ملف تعريف ارتباط الجلسة المجهول | `Secure=false`، `HttpOnly=true`، `SameSite=Lax` |
تحتاج نتيجة ملف تعريف الارتباط إلى بعض السياق. كانت السمتان `HttpOnly` و`SameSite=Lax` إيجابيتين، لكن غياب العلامة `Secure` سمح لملف تعريف ارتباط الجلسة المجهول بالانتقال عبر اتصال غير مشفر.
صنّفت مشكلة النقل على أنها عالية الخطورة بعد اختبار المتصفح. إذ يمكن لمهاجم موجود على مسار الشبكة مراقبة حركة HTTP أو تعديلها. وإذا أرسل مستخدم بيانات اعتماد في تلك الصفحة، فقد يكشف الاتصال غير المشفر عنها. لم أجد دليلًا على سرقة بيانات اعتماد، ولم أرسل أي بيانات اعتماد أثناء الاختبار.
غيّر التحقق عبر المتصفح تقييم الخطورة
صنّف الاختبار المرجعي المستقل الأولي سلوك HTTP على أنه متوسط الخطورة. وتغير هذا التصنيف بعد أن أظهر التحقق أثناء التشغيل نموذج كلمة مرور حقيقيًا يظل على HTTP، مع تحميل موارده الداعمة أيضًا عبر HTTP.
يقول هذا التغيير عن أسلوب الاختبار أكثر مما يقول عن النماذج. فقد حدد فحص الترويسات مشكلة الإعداد. أما دليل المتصفح فأثبت كيف سيواجهها الزائر. وجعلت الأدلة الإضافية الأثر ملموسًا بما يكفي لتبرير أولوية أعلى.
توصل Daybreak Blue إلى الاستنتاج الأساسي نفسه. واستفاد كلا التشغيلين من القاعدة نفسها: يجب أن يتضمن الاكتشاف ملاحظة قابلة لإعادة الإنتاج، وبيانًا محدودًا للأثر، وقائمة واضحة بالإجراءات التي لم تُنفذ.
ما الذي وجدته الفحوصات الثانوية
أنتج التقييم أيضًا عدة نتائج ذات أولوية أقل.
عملت إصدارات TLS الحديثة
رفض المضيف الذي تم اختباره TLS 1.0 و1.1، مع قبوله TLS 1.2 و1.3. وهذه نتيجة إيجابية لنقطة نهاية HTTPS. لكنها لا تعوّض السماح ببقاء تجربة تسجيل الدخول على HTTP.
سمحت سياسة Content Security Policy بالتعليمات البرمجية المضمنة
تضمنت سياسة Content Security Policy المرصودة `'unsafe-inline'` للنصوص البرمجية والأنماط. وتعاملت مع ذلك على أنه فجوة في التقوية، وليس دليلًا على وجود ثغرة cross-site scripting. وعادةً ما تتطلب إزالة السماحات المضمنة تغييرات في التطبيق واختبارات انحدار، لذا ينبغي أن تأتي بعد إصلاح النقل.
لم يكن لدى الموقع ملف `security.txt`
أعاد المسار القياسي `/.well-known/security.txt` الحالة `404`. وصنّفت ذلك على أنه معلومة إرشادية. إذ يوفر ملف جهة اتصال أمنية مسارًا واضحًا للإبلاغ للباحثين، لكن غيابه لا ينشئ خللًا قابلًا للاستغلال.
لم يسمح اختبار preflight عبر CORS بالنطاق الخارجي
لم يتلقَّ طلب preflight واحد من نطاق غير ذي صلة إذنًا للوصول إلى المسار العام الذي تم اختباره. وهذه نتيجة سلبية مفيدة، لكنها محدودة بنقطة النهاية وطلب preflight اللذين فحصتهما. وليست تدقيقًا شاملًا لـ CORS على مستوى الموقع.
هل تفوق Daybreak Blue على الاختبار المرجعي؟
لا يدعم هذا الاختبار ترتيبًا عامًا للنماذج. فقد وجد كل من Daybreak Blue والاختبار المرجعي المستقل مشكلة النقل. وتحسن تصنيف خطورة الاختبار المرجعي عندما أضفت دليل المتصفح.
كان Daybreak Blue مفيدًا لأنه ظل مركزًا على مهمة دفاعية مصرح بها، وأنتج اكتشافًا يمكنني التحقق منه. ولا يمكن لموقع إلكتروني واحد، ونطاق واحد، وتاريخ اختبار واحد أن تثبت أنه سيتفوق على نموذج آخر في مراجعة المصدر، أو الاستجابة للحوادث، أو تحليل البرمجيات الخبيثة، أو اختبارات الاختراق الأكبر.
سيتطلب المعيار الأقوى تكرار حالات الاختبار المخفية نفسها عبر عدة تطبيقات مملوكة، ومنح كل نموذج الأدوات والوقت نفسيهما، وتقييم قابلية إعادة الإنتاج، والإيجابيات الكاذبة، والاكتشافات الفائتة، ومعايرة الخطورة، وجودة المعالجة.
أستخدم منهج التقييم الأوسع هذا في كيفية قياس نماذج AI للعمل الحقيقي→. ويُعد تشغيل Daybreak هذا تقريرًا ميدانيًا واحدًا، وليس معيارًا شاملًا.
كيف يمكنك الحصول على OpenAI Daybreak Blue؟
يتطلب الوصول إلى Daybreak موافقة عبر برنامج Trusted Access for Cyber التابع لـ OpenAI. ويمكن للأفراد التقديم من خلال طلب Trusted Access الفردي، بينما يمكن للمؤسسات استخدام نموذج طلب المؤسسات.
ترتبط الموافقة بالهوية أو الخدمة المعتمدة، ومساحة العمل أو مؤسسة وواجهة API والمشروع، والنموذج، وواجهة المنتج. ولا يضمن إكمال التحقق من الهوية أو إرسال النموذج الحصول على الوصول. كما يتطلب Daybreak Red موافقة منفصلة؛ ولا يتضمن الوصول إلى Blue الوصول إليه تلقائيًا.
يربط سير عمل Daybreak الأوسع بين التحقيق، ومراجعة المستودع، والأدلة، والإصلاحات المقترحة، والتحقق البشري. وتحمل إرشادات OpenAI نفسها المهندس مسؤولية التغييرات ذات العواقب (Scaling cyber defenders with Daybreak).
المصادر وسجل الاختبار
أجريت الفحوصات المصرح بها في 30 أغسطس 2026. وتأتي ملاحظات المتصفح، والترويسات، وملفات تعريف الارتباط، وTLS، وCSP، و`security.txt`، وCORS الواردة في هذه المقالة من سجل ذلك الاختبار.
وتأتي ادعاءات النموذج والوصول من مصدرين أساسيين تابعين لـ OpenAI:
وفقًا لإرشادات الوصول لدى OpenAI، تظل الموافقة محددة بالهوية، ومساحة العمل أو مشروع API، والنموذج، وواجهة المنتج. ولا تمتد نتائج اختباري إلى ما هو أبعد من نطاق Mixanalytic الموضح أعلاه.
ما الذي سأصلحه وأعيد اختباره لاحقًا
يمتلك اكتشاف النقل ترتيب أولوية قصيرًا:
يجب أن يفشل الاختبار المعاد إذا عادت أي صفحة تسجيل دخول، أو إجراء نموذج، أو مورد من الطرف الأول، أو ملف تعريف ارتباط جلسة إلى HTTP. كما سأعيد تشغيل تقييمي Daybreak والاختبار المرجعي على الإصدار المُصلح للتحقق مما إذا كانا سيتعرفان على المعالجة ويتجنبان تكرار الاكتشاف.
أنتج الاختبار الأول نتيجة مفيدة دون تجاوز حدود التفويض. اكتشف Daybreak Blue خللًا حقيقيًا. وأظهرت أدلة المتصفح المستقلة سبب استحقاقه للاهتمام. أما الادعاء الموثوق التالي فليس أن الأداة عملت مرة واحدة؛ بل أن الإصلاح يصمد أمام الاختبار نفسه.