تدقيق الأمان في Cursor يكشف عن أربع ثغرات في محرر الأكواد، لكن التفويض يبقى آمناً

كشفت عملية تدقيق أمان Cursor عن نتيجة نادرة لأدوات الذكاء الاصطناعي: لم يتمكن الباحث من تجاوز المصادقة على جانب الخادم والوصول إلى النماذج المتميزة من خلال ثغرة على جانب العميل، لكنه وجد أربع مشاكل ملحوظة في محيط الأمان على الطريق. يثير الفحص الاهتمام بالضبط لأنه ليس قصة عن "كل شيء انهار"، بل هو فحص مفصل لكيفية بناء محرر أكواد الذكاء الاصطناعي—أداة تمرر كميات كبيرة من الأكواد والطلبات من المطورين عبر خوادمها. بدأ البحث بفك تجميع عميل Cursor الإلكتروني، المبني على أساس VS Code.

في ملف JavaScript واحد مضغوط يتجاوز 1.1 مليون سطر، استرجع المؤلف أوصاف protobuf وخريطة API ومنطق OAuth وقائمة feature gates. على حدة، أظهر أن الرمز المميز JWT للمستخدم لا يحتوي على مطالبات حول الاشتراك أو الخطة: يتم فحص حقوق الوصول إلى النماذج ليس على جانب العميل وليس من خلال محتويات الرمز المميز، بل على الخادم، بناءً على بيانات قاعدة البيانات.

بالنسبة لمنتج SaaS مع نماذج لغة كبيرة مكلفة، هذا خيار معماري أساسي، لأن مثل هذا النظام يمنع مستخدماً "مجانياً" من ببساطة تزوير المعاملات المحلية وفتح Claude 4 Opus أو نموذج متميز آخر. بعد الهندسة العكسية للـ API، انتقل الباحث إلى الهجمات على الـ API. أول اكتشاف—تلوث النموذج الأولي في نقاط نهاية JSON المتعلقة بالاشتراك والعروض الترويجية.

إذا تمت إضافة حقول مثل __proto__ أو constructor.prototype إلى نص الطلب، يرد الخادم برسالة خطأ 500 Internal Server Error بدلاً من الرفض المتوقع. لا يمنح هذا ترقيات خطة تلقائية، لكنه يوضح أن تلوث سلسلة النموذج الأولي يحدث قبل فحوصات المنطق التجاري ويمكن أن يغير مسار التحقق.

المشكلة الثانية—حقل مخفي devRawModelSlug في AgentRunRequest. لا يوجد في مخطط العميل، لكن خوادم الإنتاج تقبل هذا الحقل وتتعرف على اسمه وترد برسالة خطأ منفصلة تكشف أن النظام يحتوي على آلية dev لتحديد نموذج backend مباشرة، متجاوزة التوجيه القياسي. حالياً هذا المسار معطل، لكن وجوده وحده في محيط الإنتاج يزيد من خطر أخطاء التكوين.

هناك ثغرتان أخريان لا تنشآن من تجاوز الاشتراك، بل من الكشف غير الضروري للهندسة الداخلية والتحقق غير الكامل. تجيب إحدى الطرق الداخلية برسالة "Invalid internal service header"، من خلالها يمكنك استنتاج أن نقطة النهاية موجودة، محمية بمصادقة منفصلة من خدمة إلى خدمة، وتتوقع رأس خاص. بالنسبة للعميل الخارجي، مثل هذه التفاصيل غير ضرورية: سيكون من الأفضل الرد برسالة 404 أو 401 عامة بدون تلميحات داخلية.

بالإضافة إلى ذلك، كشفت عملية المراجعة أن بعض حقول protobuf لسيناريوهات subagent تقبل روابط إلى نماذج متميزة بدون فحص خطة منفصل. في الواقع العملي، هذا لا يغير نموذج الرد الفعلي ولا يفتح أي تجاوز، لأن التوجيه يتجاهل هذه الحقول على أي حال، لكن منطق كهذا يوسع سطح الهجوم ويمكن أن يصبح مشكلة بعد تغييرات المنتج المستقبلية. جزء مهم من المراجعة—قائمة بالمتجهات التي لم تنجح.

اختبر المؤلف force brute لأسماء النماذج وتزوير مطالبات JWT وحقن OAuth callback وإعادة تشغيل webhook Stripe والالتباس بين requested_model و model_details وتضاربات أنواع wire في protobuf وظروف التسابق حول الاشتراك. لم ينجح أي تجاوز كبير في أي مكان. يرفض الخادم علامات protobuf غير الصحيحة ولا يثق ببيانات JWT ويتحقق من توقيعات Stripe ويحافظ على فحوصات الخطة المركزية.

هذا يجعل الخلاصة أقوى: المشاكل موجودة فعلاً، لكن نموذج الأمان الأساسي لـ Cursor يبدو ناضجاً ومدروساً مقارنة بخدمات الذكاء الاصطناعي العديدة التي تثق بالعميل بشكل كبير جداً. الأهمية العملية لهذه القصة تتجاوز Cursor نفسه. بالنسبة لمطوري AI SaaS، هذه قائمة تحقق جيدة: لا تخزن الامتيازات في الرموز المميزة، تحقق من الخطة على الخادم مع كل طلب، تحقق من صحة protobuf بدقة، ولا تترك حقول dev في مخططات الإنتاج.

بالنسبة للمستخدمين، إنها إشارة إلى أن حتى بيئات التطوير المتكاملة المتقدمة للذكاء الاصطناعي لها سطح عرضة للهجوم حول الفواتير والخدمات الداخلية وآليات توجيه النماذج. والأهم من ذلك: اليوم، تُعرّف أمان منتج الذكاء الاصطناعي ليس بعدد النماذج التي يدعمها، بل بمدى انضباط فصله للعميل عن حقوق الوصول الحقيقية على الخادم.