أدت أداة أتمتة مبنية على Safari MCP إلى إغلاق علامة تبويب لوحة تحكم المطور أثناء قراءتها. كشف الحادث عن خلل خفي في نظام الحماية (guard) الذي كان من المفترض أن يمنع الوكلاء المدفوعين بالذكاء الاصطناعي من المساس بأي علامة تبويب لا تخصهم، وهو ما يوضح لماذا يمكن أن تكون فئات "الآمن افتراضياً" (safe-by-default) عبئاً.
نظام الحماية الذي عمل—حتى توقف عن العمل
تقوم الأداة بتمييز كل علامة تبويب تنشئها بمعرّف داخلي. قبل أن يصدر الوكيل أي أمر، يتحقق نظام الحماية من وجود تلك العلامة؛ وإذا كانت العلامة مفقودة، يرفض النظام اتخاذ أي إجراء. من الناحية العملية، منع نظام الحماية الوكيل من قراءة صفحة لم يقم بفتحها—وهذا هو بالضبط ما صُمم من أجله.
أثناء ملء نموذج ما، تم إعادة توجيه الصفحة إلى نطاق مختلف. أدت عملية إعادة التوجيه هذه إلى تجريد العلامة، مما ترك علامة التبويب بدون تسمية. رأى نظام الحماية العلامة المفقودة وأبلغ: "لا يمكنني التحقق من الملكية، لذا لن أقرأ علامة التبويب هذه". في تلك اللحظة، تصرف فحص السلامة كما هو مخطط له.
كود التنظيف الذي تجاوز الحدود
تلا ذلك روتين تنظيف يدوي مخصص لإغلاق علامات التبويب اليتيمة—تلك التي لا تملك علامة. طلب الروتين من الأداة "إغلاق علامة تبويب" دون التأكد أولاً من الملكية. ولأن نظام الحماية لم يستطع إثبات أن علامة التبويب تخصه، عادت الأداة إلى الإجراء الافتراضي: "إغلاق علامة التبويب الحالية". كانت علامة التبويب الحالية هي لوحة التحكم التي كان المطور يقرأها، وليست علامة تبويب يتيمة.
كانت النتيجة عملية تدميرية تم إطلاقها عبر مسار سلامة كان ينبغي أن يكون طريقاً مسدوداً.
ثلاث طبقات تعاملت مع "عدم وجود ملكية" كإذن
- تصنيف الأوامر – القائمة التي جمعت الأوامر وضعت
close_tabتحت فئة واسعة تسمى "إدارة علامات التبويب" (tab management). افترض المطور أن كل شيء في تلك الفئة غير ضار لأن الأوامر الأخرى (مثلlist tabs) تقرأ المعلومات فقط. لم تشر أي ملاحظة صريحة إلى أنclose_tabأمر تدميري، لذا ورث السلامة المتصورة لأوامره المجاورة. - السياسة على مستوى الإضافة – سمحت إضافة Safari التي تتوسط جميع إجراءات المتصفح بأي عملية عندما لا تملك الجلسة أي شيء. تعمل هذه القاعدة مع إجراءات القراءة فقط، ولكنها فتحت الباب أيضاً لتنفيذ
close_tabدون التحقق من المصدر. - عدم تطابق المنطق – تحقق روتين التنظيف من علامة الملكية في علامة تبويب واحدة، ولكنه استدعى بعد ذلك وظيفة الإغلاق على علامة التبويب التي أبلغ المتصفح أنها "الحالية". سمح هذا عدم التطابق لفشل نظام الحماية في العثور على علامة بتجاوز أمر الإغلاق وإعادة توجيهه إلى الهدف الخاطئ.
افترضت كل طبقة أن "عدم تسجيل ملكية" يعني "من الآمن التصرف"، وأنتجت هذه الطبقات مجتمعة أمراً لإغلاق علامة التبويب تم تنفيذه دون أي دليل على شرعيته.
الإصلاح: إثبات الملكية إلزامي للإجراءات التدميرية
يفصل المنطق المعدل بين مسارات القراءة فقط والمسارات التدميرية. الآن، قبل تنفيذ أمر close_tab ، يجب على الأداة تقديم علامة صالحة لعلامة التبويب المستهدفة. إذا كانت العلامة مفقودة، يطلق الأمر خطأً بدلاً من الرجوع إلى علامة التبويب الحالية. لم يعد نظام الحماية يعود إلى فرع "افعل شيئاً" عام.
يزيل هذا التغيير الحالة الغامضة حيث يمكن تفسير العلامة المفقودة إما على أنها "لا يوجد شيء للقيام به" أو "استمر وقم بالتصرف". من خلال فرض فشل صريح، تحمي الأداة عمل المستخدم من الفقدان العرضي.
ما يجب على المطورين مراقبته
- لا تدع اسم الفئة يملي مستوى السلامة – تسمية مثل "إدارة علامات التبويب" لا تقول شيئاً عن تأثير كل أمر بداخلها. سجل تكلفة كل عملية (قراءة مقابل تدمير) بجانب الأمر نفسه.
- يجب أن تتناسب شروط الحماية مع خطورة الإجراء – الفحص الذي يكفي لطلب القراءة ليس كافياً لأمر يمكنه حذف البيانات. قم ببناء خطوط أنابيب تحقق منفصلة لكل فئة من فئات التأثير.
- تجنب الخيارات البديلة الضمنية – عندما لا يستطيع نظام الحماية التحقق من الملكية، فإن الرد الأكثر أماناً هو الإلغاء، وليس اختيار هدف افتراضي. الإجراءات الافتراضية هي مصدر شائع لثغرات تصعيد الامتيازات.
- تدقيق افتراضات التجاور – راجع أي قائمة أو قائمة منسدلة حيث توضع الأوامر بجانب بعضها البعض. يمكن لأمر غير ضار أن يرث الثقة الممنوحة لجيرانه إذا لم يقم الكود بإعادة تقييم السلامة صراحةً.
الخلاصة
إن غياب نظام حماية الملكية ليس مجرد خطأ برمجياً؛ بل هو فجوة في التصميم. تعامل مع كل أمر تدميري كنطاق أمني منفصل يتطلب إثباتاً صريحاً للسلطة، ولا تسمح أبداً بتفسير "عدم وجود علامة" على أنه "استمر في العمل". عندها فقط يمكن لأدوات الأتمتة حماية علامات التبويب التي صُممت لإدارتها.