أمن برمجة Vibe: المشكلات التي نتحقق منها في التطبيقات التي تم إنشاؤها بواسطة الذكاء الاصطناعي

أمن برمجة Vibe يتعلق في الغالب بما تغفله التطبيقات التي تم إنشاؤها بواسطة الذكاء الاصطناعي: التفويض من جانب الخادم على كل سجل، والأسرار التي لا تظهر للعميل، وقواعد البيانات المحكمة، والمدخلات المعتمدة، وخطافات الويب الآمنة للمدفوعات، وحدود المعدل. راجع حدود الثقة هذه قبل الإطلاق، لأن التطبيق قد يبدو مكتملًا بينما يمكن لأي مستخدم مسجل الدخول قراءة بيانات الجميع.

هذا هو مستوى قائمة المراجعة لعملنا من النموذج الأولي إلى الإنتاج. لترتيب التحصين العام، راجع كيفية تحويل نموذج أولي Lovable أو v0 إلى تطبيق إنتاجي. بالنسبة للوكلاء على وجه التحديد، راجع حدود بناء الوكلاء فقط من أدوات Vibe-code. هنا ندرج المشكلات الملموسة التي نبحث عنها في تطبيقات الويب والجوال المبنية بواسطة الذكاء الاصطناعي، استنادًا إلى أنماط حدود الثقة الشائعة وتطبيق بوابة ImadDhin. لا يوجد هنا أي ادعاء حول إحصائيات الاختراق.

لماذا تحتوي التطبيقات التي تم إنشاؤها بواسطة الذكاء الاصطناعي على فجوات متوقعة

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

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

يرث الكود الذي تم إنشاؤه أيضًا أنماطًا من البرامج التعليمية والقوالب الأولية، حيث توجد المفاتيح في تكوين العميل وتُترك قواعد البيانات مفتوحة للراحة. هذه الأنماط جيدة للعرض التوضيحي وخاطئة للعملاء.

ما الذي تخطئ فيه الفرق بشأن أمان الكود الذي تم إنشاؤه بواسطة الذكاء الاصطناعي؟

تتعامل معظم الأخطاء مع المنصة أو الواجهة أو أداة الذكاء الاصطناعي نفسها كمراجعة أمنية. الأخطاء الشائعة:

• افتراض أن منصة مستضافة أو خدمة خلفية تجعل التطبيق آمنًا افتراضيًا
• إخفاء الأزرار في الواجهة والتعامل مع ذلك كتفويض
• سؤال نفس أداة الذكاء الاصطناعي عما إذا كان الكود آمنًا وقبول الإجابة كمراجعة
• تخفيف قواعد البيانات لإصلاح خطأ في الأذونات بدلاً من إصلاح الاستعلام
• التخطيط لمراجعة الأمان بعد الإطلاق

توفر المنصات كتل بناء جيدة، ولكن التكوين ومنطق التفويض يخصك. يجب أن تتم المراجعة من قبل شخص يبحث عن الفشل، وليس من قبل الأداة التي كتبت الكود.

ما الذي تتضمنه قائمة مراجعة أمن برمجة Vibe؟

تغطي قائمة المراجعة ثمانية حدود ثقة، من المصادقة إلى العمليات، ويحدد كل عنصر حدًا يجب التحقق منه عمدًا. يأتي التفويض أولاً لسبب: التحكم في الوصول المعطل يتصدر قائمة OWASP Top 10.

المصادقة والحسابات

• لا يمكن إعادة تشغيل أو تخطي تدفقات إعادة تعيين كلمة المرور والتحقق من البريد الإلكتروني
• عناوين URL لإعادة توجيه OAuth مقيدة بالنطاقات المعروفة
• الأدوار مثل المسؤول تأتي من مصدر يتحكم فيه الخادم، وليس أبدًا من حقل ملف تعريف يمكن للمستخدم تعديله
• تنتهي صلاحية الجلسات ويؤدي تسجيل الخروج إلى إبطال ما يجب إبطاله

التفويض على كل سجل

• يتحقق كل قراءة وكتابة من الملكية أو الإيجار على الخادم أو في قواعد البيانات
• لا يمكن لتغيير معرف في طلب إرجاع أو تعديل سجل مستخدم آخر
• يتم حماية مسارات المسؤول ونقاط نهاية API من جانب الخادم، وليس فقط إخفاؤها في التنقل
• تقوم نقاط نهاية القائمة بالتصفية حسب المستخدم الحالي أو المستأجر، وليس فقط حسب ما تعرضه الصفحة

قواعد البيانات والتخزين

• يتم تمكين أمان مستوى الصف أو قواعد مكافئة على كل جدول أو مجموعة مكشوفة
• لا تسمح أي قاعدة بقراءات أو كتابات غير مقيدة للراحة
• تقوم قواعد الإنشاء بالتحقق من شكل وملكية السجلات الجديدة
• تحتوي حاويات تخزين الملفات على قواعدها الخاصة ولا تسمح بالإدراج العام

بالنسبة لمشاريع Supabase، هذا موضوع خاص به، يتم تغطيته في أخطاء أمان مستوى الصف في Supabase في التطبيقات المبنية بواسطة الذكاء الاصطناعي.

الأسرار والتكوين

• لا توجد مفاتيح سرية لخدمة الدور أو المسؤول أو الدفع في كود العميل أو متغيرات البيئة العامة
• لا توجد أسرار في الملفات الملتزم بها، بما في ذلك التاريخ
• لا تكشف خرائط المصدر الإنتاجية عن منطق الخادم أو المفاتيح
• CORS مقيد ويتم تعيين رؤوس الأمان

المدخلات والمخرجات وميزات الذكاء الاصطناعي

• التحقق من صحة المدخلات من جانب الخادم على كل مدخل، وليس فقط في النموذج
• يتم تنظيف محتوى المستخدم المعروض كـ Markdown أو HTML
• تتحقق عمليات تحميل الملفات من النوع والحجم ويتم تخزينها خارج جذر الويب
• لا يمكن للميزات التي تجلب عناوين URL الوصول إلى عناوين الشبكة الداخلية، وهو خطر تزوير طلب من جانب الخادم الكلاسيكي
• يتم التعامل مع مخرجات النموذج على أنها غير موثوق بها ولا يمكنها تشغيل الإجراءات بدون فحوصات
• تُستخدم مفاتيح مزود النموذج على الخادم فقط

المدفوعات والاستحقاقات

• يتم تعيين الأسعار ومعرفات الخطة على الخادم، ولا يتم أخذها أبدًا من العميل
• يتم التحقق من توقيعات خطاف الويب قبل أي معالجة
• معالجات خطاف الويب متطابقة، بحيث لا يمنح حدث معاد المحاولة الوصول مرتين
• يتم منح الوصول من حدث الدفع الذي تم التحقق منه، وليس من الوصول إلى صفحة نجاح

إساءة الاستخدام والتكلفة

• حدود المعدل على تسجيل الدخول، والتسجيل، وإعادة تعيين كلمة المرور، ونقاط نهاية الذكاء الاصطناعي
• يتم تحديث عدادات الحصص والائتمان بشكل ذري
• تحتوي النماذج العامة على حماية من الروبوتات تتناسب مع مخاطرها

التبعيات والعمليات

• كل حزمة مضافة موجودة، وهي المقصودة، ويتم صيانتها
• تتم إزالة مسارات التصحيح، ونقاط نهاية البذور، وحسابات الاختبار
• لا تتضمن الأخطاء المعروضة للمستخدمين تتبعات المكدس أو الاستعلامات
• يتم تسجيل الأحداث المتعلقة بالأمان، مثل تسجيلات الدخول، وتغييرات الأدوار، وإجراءات المسؤول، بدون أسرار أو بيانات شخصية غير ضرورية

كيف تجري مراجعة أمنية على تطبيق مبني بواسطة الذكاء الاصطناعي؟

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

ثم اختبر كشخص خارجي. أنشئ حسابين عاديين وحاول قراءة وتغيير وحذف بيانات بعضكما البعض من خلال الواجهة ومباشرة من خلال API. استعلم عن قاعدة البيانات باستخدام مفتاح العميل العام أثناء تسجيل الخروج. ابحث في حزمة العميل المبنية عن أي شيء يبدو وكأنه مفتاح. أعد تشغيل خطاف دفع الويب. أرسل نفس الطلب عدة مرات بسرعة. تجد هذه الاختبارات مشكلات حقيقية أكثر من مجرد قراءة الكود وحده.

أصلح بترتيب نطاق الانفجار: الأسرار المكشوفة وقواعد البيانات المفتوحة أولاً، لأنها تؤثر على كل مستخدم في وقت واحد؛ ثم فجوات التفويض؛ ثم المدفوعات؛ ثم حدود إساءة الاستخدام والتحصين. قم بتدوير أي سر تم كشفه على الإطلاق، حتى لفترة وجيزة، بدلاً من إزالته من الكود فقط.

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

تكلفة المراجعة الأمنية ومتى يجب أن تكون أخف

تكلف المراجعة بضعة أيام قبل الإطلاق وبعض الميزات التي اعتمدت على الوصول المفتوح، ويجب أن يتناسب عمقها مع البيانات والأموال المعنية. أحيانًا تؤدي قواعد البيانات المحكمة إلى تعطيل الميزات التي اعتمدت على الوصول المفتوح. هذا التعطيل مفيد: فهو يوضح أي الاستعلامات كانت تعتمد على الثغرة. إصلاح الاستعلام يتطلب عملًا أكثر من استعادة القاعدة المفتوحة، وهو الإصلاح الوحيد الذي يصمد.

مراجعة شاملة تبطئ الإطلاق بأيام، وليس أشهر، لمعظم النماذج الأولية. البديل هو اكتشاف نفس المشكلات بعد أن يثق العملاء في التطبيق ببياناتهم، عندما تتطلب الإصلاحات أيضًا إشعارًا وتدويرًا وتنظيفًا.

ليس كل اكتشاف يبرر نفس الجهد. النموذج الأولي المستخدم داخليًا ببيانات اختبار يحتاج إلى أقل من تطبيق عام يتلقى مدفوعات. طابق عمق المراجعة مع البيانات والأموال المعنية.

الأنماط التي نراها في قواعدنا وفي مراجعات الكود

هذه ملاحظات على مستوى الكود من تكوين بوابة ImadDhin واقتراحات فحوصات المراجعة، وليست ادعاءات حول حوادث العملاء.

ترفض قواعد بيانات البوابة الوصول افتراضيًا، بدون قاعدة شاملة. يتم رفض جلسات الدردشة والرسائل والذاكرة المحفوظة وسجلات الاستخدام للعملاء بالكامل ويتم التعامل معها فقط بواسطة مسارات الخادم. تسمح العديد من مجموعات الإدخال العامة بالإنشاء ولكن ليس القراءة أو التحديث أو الحذف، مع وظائف التحقق من صحة شكل كل سجل جديد.

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

عدادات الاستخدام هي النمط الثاني. العداد الذي يقرأ العدد الحالي ثم يكتب القيمة المتزايدة في خطوة منفصلة، خارج المعاملة، يسمح لطلبين متزامنين بتجاوز فحص الحد. بالنسبة لمبلغ مجاني صغير، يكون التعرض طفيفًا، ولكن نفس النمط الذي يحمي رصيد ائتمان مدفوع هو ثغرة أمنية حقيقية، وهو بالضبط نوع الكود الذي يجتاز مراجعة سريعة.

يتم حل أسرار الخادم في وقت التشغيل على الخادم، أولاً من تكوين البيئة ثم من مدير الأسرار، ولا يستخدم أي منها بادئة عامة. قواعد تجاهل النشر هي دعم مفيد، ولكن العادة الأقوى هي الاحتفاظ بملفات الاعتماد خارج المستودع تمامًا، بحيث لا يمكن لقاعدة واحدة خاطئة التكوين كشفها.

ما هي الاختبارات التي تجد الثغرات الأمنية في تطبيق مبني بواسطة الذكاء الاصطناعي؟

• سجل الدخول كمستخدم B واطلب سجلات المستخدم A بواسطة المعرف من خلال API
• استعلم عن كل جدول أو مجموعة باستخدام مفتاح العميل العام أثناء تسجيل الخروج
• ابحث في حزمة الإنتاج وخرائط المصدر عن سلاسل تبدو سرية
• أعد تشغيل خطاف دفع الويب وتأكد من منح الوصول مرة واحدة فقط
• قم بتحرير ملفك الشخصي لإضافة دور مسؤول وتأكد من عدم وجود تأثير له
• أرسل طلبات متوازية عند حد الحصص وتأكد من أنها تصمد
• الصق علامة نصية في حقل نصي يتم عرضه في مكان آخر

متى يكون إعداد أمان أخف كافيًا؟

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

إذا كان التطبيق يحتاج فقط إلى تسجيل الدخول وعدد قليل من الصفحات، فاستخدم المصادقة المدارة لمنصتك والقواعد الافتراضية الأكثر تقييدًا، وتجنب الأدوار المخصصة حتى تحتاج إليها. تعني الميزات الأقل عددًا أقل من حدود الثقة للمراجعة. أحيانًا يكون أفضل إصلاح أمني هو إزالة ميزة لا يستخدمها أحد.

قم بالمراجعة قبل أن يكتشف العملاء الثغرات

قم بتشغيل قائمة المراجعة، واختبر بحسابين وعميل غير مسجل الدخول، وأصلح حسب نطاق الانفجار. إذا كنت تفضل أن تتم المراجعة والإصلاحات نيابة عنك، فراجع ممارسة ImadDhin إنقاذ Vibe-code، أرسل تفاصيل المستودع الخاص بك من خلال ملخص المشروع، أو احجز مكالمة لمدة 30 دقيقة.

كيف يمكنك استكشاف مخاطر الأمن السيبراني قبل التقييم؟

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

Xion في معرض الأمن السيبراني هو عرض توضيحي لمفهوم قرارات السماح والحظر والموافقة. لا يراقب أو يحمي تطبيقك. بالنسبة لمنصتك، يجب أن تأتي الأدلة من اختبارات محددة لحدود التفويض والدفع والبيانات الفعلية. استخدم المختبر لتحديد أسئلة المراجعة، ثم تحقق من التنفيذ في البيئة ذات الصلة.