لكل لغة فجوة بين ما هو صحيح حاليًا وما كُتب عنه أكثر. في PHP هذه الفجوة واسعة جدًا، لأن اللغة تغيرت بشكل كبير بين 5.x و8.x بينما احتفظ الإنترنت بكل الدروس المكتوبة على طول الطريق.
العاقبة على التطوير المدعوم بالذكاء الاصطناعي محددة وقابلة للتوقع: يميل PHP المولّد إلى التعبيرات من الحقبة التي تحتوي على أكبر كمية من المواد المنشورة، والتي ليست الحقبة التي تعمل فيها. المخرجات تبدو تقليدية — وهذا هو بالضبط المشكلة — وأحيانًا تحمل افتراضات توقفت عن كونها آمنة منذ عدة إصدارات رئيسية.
هذا ليس حجة ضد استخدام هذه الأدوات. بل هو حجة لمعرفة ما يجب البحث عنه، والذي في PHP هو قائمة قصيرة ومستقرة.
لماذا PHP تحديداً
ثلاثة أمور تتفاقم.
- كمية المواد القديمة هائلة. كانت PHP لغة الويب الافتراضية لأكثر من عقد، وخلالها كُتبت كمية هائلة من الدروس، وإجابات المنتديات، والمقالات — معظمها لم يُحدّث.
- اللغة تغيرت أكثر من معظم اللغات. أنواع البيانات البسيطة، وأنواع الإرجاع، والعدادات، والخصائص للقراءة فقط، وترقية المُنشئ، والوظائف القابلة للاستدعاء من الدرجة الأولى، ونموذج الأخطاء الأكثر صرامة كلها ظهرت بعد كتابة معظم تلك المواد.
- الكود القديم لا يزال يعمل. على عكس اللغات التي أجبرت إصداراتها المدمرة النظام البيئي على التقدم، لا يزال الكثير من كود PHP من عصر 5 يعمل اليوم، مما يحافظ على وجود الأنماط القديمة في المواد الحالية والتاريخية.
النتيجة هي توزيع يميل نحو أنماط صحيحة نحويًا، قابلة للتشغيل فورًا، ولم يعد أحد يكتب PHP بها.
الأنماط التي يجب مراقبتها
1. الاستعلامات المبنية كسلاسل نصية
الأكثر تأثيرًا. عقد من الدروس بيّنت الوصول إلى قاعدة البيانات عن طريق دمج المتغيرات في سلسلة الاستعلام، وهذا النمط ممثل بعمق. غالبًا ما يستخدم الكود المولّد منشئ استعلام بشكل صحيح ثم ينتقل إلى التضمين النصي الخام للحالة الوحيدة التي يجعل فيها المنشئ الأمر معقدًا — ORDER BY ديناميكي، قائمة أعمدة محسوبة، أو شرط IN.
يعمل، يمر بالاختبارات، وهو نقطة دخول للحقن. راجع أي استعلام خام في الكود المولّد كما لو كان مكتوبًا بواسطة غريب، لأنه فعليًا كذلك.
2. المقارنات غير الصارمة ومزج الأنواع
PHP 8 أصلحت أسوأ سلوكيات المقارنة بين النص والرقم، لكن الكود المولّد لا يزال يستخدم == حيث يجب أن يستخدم ===، خصوصًا في فحوصات المصادقة والتفويض حيث العواقب أكبر. المواد القديمة استخدمت المقارنة الفضفاضة بحرية لأنها عادة ما كانت تعمل.
3. الهروب اليدوي بدلاً من مرافق الإطار
الهروب اليدوي، تعيين الرؤوس يدويًا، دوال التنقية المخصصة. كانت ضرورية في عصر ما قبل الأُطُر والآن هي طريقة لتجاوز الحمايات التي يوفرها الإطار بشكل صحيح. الكود المولّد الذي يهرب المخرجات بنفسه، في قاعدة كود قالبها يهرب بالفعل، هو إشارة إلى أن النموذج استخدم تعبيرًا قديمًا.
4. التشفير ومعالجة كلمات المرور القديمة
أي شيء يتعلق بالتجزئة، الرموز أو العشوائية يستحق اهتمامًا خاصًا. المواد القديمة تعرض طرقًا كانت نصائح قياسية في ذلك الوقت والآن هي خاطئة فعليًا. PHP الحديثة لديها أدوات صحيحة وبسيطة لكل ذلك؛ الكود المولّد لا يعتمد عليها بشكل موثوق.
5. الوصول إلى المتغيرات الفائقة Superglobals دون تحقق
قراءة بيانات الطلب مباشرة واستخدامها بدون تحقق، في إطار يوفر طبقة تحقق. هذا النمط هو الأكثر دلالة على أن المخرجات جاءت من مواد ما قبل الإطار.
6. توقيعات دوال غير موصوفة بالأنواع
ليس ثغرة، بل تآكل هادئ. الكود المولّد غالبًا ما يحذف أنواع المعاملات والإرجاع، وكل حذف يزيل تحققًا كان سيجريه التحليل الثابت. عبر مئات الدوال المولدة، تفقد قاعدة الكود تغطية الأنواع بشكل ملحوظ دون أن يبدو أي تغيير خاطئ.
لماذا ينجو من المراجعة
الفشل ليس في أن الكود يبدو مريبًا. بل في أنه يبدو عاديًا.
- إنه متسق من الناحية الأسلوبية. الكود المولّد تقليدي بطبيعته، وهذا بالضبط ما لا يكون المراجع مهيأ لاكتشافه عند البحث عن الشذوذ.
- إنه يعمل. السلوك صحيح للمدخلات التي اختبرها المطور.
- المراجع يراجع الفرق، وليس التصميم. خطر الحقن في دالة من خمسة عشر سطرًا يقرأ كسطر عادي من خمسة عشر سطرًا.
- الحجم يفوق الانتباه. يُنتج المزيد من الكود لكل ساعة مراجعة مقارنة بالسابق، وتتدهور جودة المراجعة مع زيادة الكمية كما هو متوقع.
الخطر المتفاقم: هذا أكثر حدة في قواعد الكود القديمة، وهي بالضبط حيث تلجأ الفرق للمساعدة بالذكاء الاصطناعي أكثر، لأن الكود غير مألوف. ينتج النموذج كودًا بأسلوب قديم معقول يتطابق مع الأسلوب المحيط، ولا يبدو أي شيء غريبًا على الإطلاق.
كيفية الدفاع ضده
كل هذا تقريبًا يمكن اكتشافه آليًا، مما يعني أن الدفاع يجب أن يكون مفروضًا آليًا بدلاً من الاعتماد على انتباه المراجع.
- التحليل الثابت على مستوى عالٍ، والحظر في CI. PHPStan أو Psalm يكتشفان الأنواع المفقودة، والافتراضات غير الآمنة، وجزءًا كبيرًا من مشكلة المقارنة الفضفاضة قبل أن يراها الإنسان.
- تحليل التلوث أو مجموعة قواعد تركز على الأمان، مصممة خصيصًا لاكتشاف نمط الاستعلام المبني من نصوص.
- declare(strict_types=1) في كل مكان، حتى تفشل عمليات تبديل الأنواع بصوت عالٍ بدلًا من الصمت.
- فحص الاعتمادات والثغرات في CI، لأن الكود المولّد يقترح أحيانًا حزمة مهجورة أو إصدارًا معروفًا بثغرات.
- قائمة مراجعة قصيرة للكود المولّد — الاستعلامات الخام، المقارنات في مسارات المصادقة، أي شيء تشفير، أي شيء يقرأ بيانات الطلب مباشرة.
- مراجع ثانٍ لتغييرات حدود الأمان، بغض النظر عن كاتبها.
والتصحيح الهيكلي، الذي يعيد الفائدة على كل شيء آخر أيضًا: تحديث قاعدة الكود. إصدار حديث من PHP مع أنواع صارمة، إطار عمل مُحدث وتغطية تحليل ثابت عالية يضيق مساحة الكود المحتمل الخطأ بشكل كبير، لأن معظم التعبيرات القديمة لن تُترجم، أو لن تمر بالتحليل، أو ستفشل بوضوح.
هذا هو نفس الحجة التي نطرحها حول وضوح قاعدة الكود في سياسة مراجعة Laravel المدعومة بالذكاء الاصطناعي، وهو سبب آخر لأهمية سؤال الإصدار في هل لا يزال PHP الخيار الصحيح أكثر من سؤال اللغة.
موقف الحوكمة
لرئيس التكنولوجيا أو نائب رئيس الهندسة الذي يحتاج إلى موقف يمكن الدفاع عنه في هذا الشأن:
- لا تحظره. الفرق تستخدم هذه الأدوات بغض النظر، والحظر يستبدل ممارسة يمكن مراجعتها بأخرى غير معلنة.
- يُرجى طلب الإفصاح ليعرف المراجعون أي التغييرات تستحق قائمة التحقق.
- يُرجى تطبيق القواعد آلياً حيثما أمكن. كل قاعدة تنقلها من وثيقة السياسة إلى مهمة CI تقلل الاعتماد على الانتباه البشري.
- يُرجى إبقاء البشر على حدود الأمان. المصادقة، التفويض، المدفوعات، البيانات الشخصية.
- يُرجى تمويل التحديث. أكثر التدخلات فعالية ضد الكود المولد السيئ هو قاعدة كود لا يسمح ببقاء الكود السيئ ضمن سلسلة الأدوات.
هذا عمل نقوم به من خلال ممارسة تطوير PHP وتحديث PHP المخصص، ويرتبط مباشرة بالسؤال الأوسع حول المكان الذي تستحق فيه AI مكاناً حقيقياً في التسليم — تغطي ممارسة دمج AI وفريق هندسة AI هذا الجانب.
الأسئلة الشائعة
هل يحتوي PHP الناتج عن الذكاء الاصطناعي على ثغرات أمنية؟
قد يحتوي، والثغرات قابلة للتوقُّع بدلاً من أن تكون عشوائية: استعلامات مبنية كسلاسل نصية، المقارنات غير الصارمة في مسارات المصادقة، إرشادات تشفير قديمة، وبيانات طلب غير مُتحقّق منها. كلها تنبع من سبب واحد — عقد من المواد المنشورة التي تسبق ميزات الأمان في PHP الحديثة.
لماذا هذا أسوأ في PHP مقارنةً بلغات أخرى؟
لأن PHP تغيّرت أكثر من معظم اللغات بين 5.x و8.x مع بقاء حجم هائل من المواد المنشورة التي لم تُحدّث، ولأن جزءاً كبيراً من شيفرات حقبة PHP 5 لا يزال يعمل اليوم. توزيع ما كُتب يميل بقوة إلى المحتوى القديم أكثر من النُظُم البيئية الأحدث.
كيف نكشف ذلك أثناء المراجعة؟
لا تعتمد على المراجعة وحدها — الشيفرة تبدو عادية، وهذا بالضبط ما يغفل عنه المراجعون الذين يبحثون عن شذوذ. اطبِق الأنواع الصارمة ومستويات عالية من التحليل الساكن في CI، أضِف مجموعة قواعد أمنية تكتشف الاستعلامات المبنية كسلاسل نصية، واحتفظ بقائمة تحقق قصيرة للأربع أو الخمس أنماط المحددة.
هل يجب التوقف عن استخدام أدوات الشيفرة المعتمدة على الذكاء الاصطناعي مع PHP القديم؟
لا، لكن تعامل مع قواعد الشيفرة القديمة كحالة ذات مخاطرة أعلى. الشيفرة المولّدة التي تطابق أسلوب الشيفرة القديمة المحيط بها هي الأصعب في الاكتشاف، لذا فإن أعمال التحديث — إصدار حديث، الأنواع الصارمة، التحليل الساكن — هي ما يجعل مساعدة الذكاء الاصطناعي آمنة هناك بدلاً من أن تكون سريعة فحسب.
هل ينطبق هذا على أُطر العمل مثل Laravel وSymfony؟
بنسبة أقل، لأن قواعد الأطر تكون قوية وممثلة جيداً، لكن نفس الفشل يظهر على شكل عادات من إصدارات أقدم من الأطر — مساعدات مهملة، بناء جملة تحقق قديم، أنماط استُبدلت بميزات من الطرف الأول. الدفاع متماثل: طبّقه في سلسلة الأدوات.
اجعل سلسلة الأدوات تقوم بالمهمة
سنقوم بإعداد التحليل الثابت، قواعد الأمان، وبوابات CI التي تجعل هذا النوع من المشاكل يفشل تلقائياً بدلاً من الاعتماد على انتباه المراجع. تواصل مع فريقنا؛ نرد خلال يوم عمل.