Cela vaut-il la peine de corriger un système d'administration sur lequel REGISTER GLOBALS est activé?

Question

J'ai un site d'administration que j'ai copié sur un nouveau serveur pour tester les bogues et les mettre en ligne, ainsi que d'autres sites.

L'administrateur semble avoir activé REGISTER GLOBALS et l'utilise pour la plupart des 300 fichiers php.

Étant donné que vous devez vous connecter à ce système, est-ce que cela vaut la peine de travailler sur les semaines de travail pour re-coder toutes les variables? Ou être heureux que je voudrais corriger chaque page que j'ajoute une nouvelle fonctionnalité à l'avenir?

Est-ce que Register Globals laisse des problèmes dans le code qui a été nettoyé, si nous ne réparons pas tout à la fois? Je suppose que cela pourrait être que $ user_id peut être défini par n'importe quel global.

Answer 1

Register_Globals est non sécurisé et ne doit pas être utilisé. Si j'étais vous je réécrirais le code, ou l'application elle-même à partir de zéro. Cependant, si c'est un système d'administration, et personne ne connait son URL et que seul l'administrateur lui-même peut y accéder, alors vous ne devriez pas le changer (assurez-vous que son URL reste secrète)

Answer 2

à certains problèmes de sécurité très graves, cela dépend un peu de la façon dont il est codé.

Par exemple:

<?php 
// $loggedin comes from $_SESSION['loggedin'] 
if($loggedin) 
{ 
    echo 'Loggedin!'; 
} 
else 
{ 
    echo 'Please login'; 
} 
?> 

Le principal problème est ici, est que le script ne vérifie pas où loggedin de $ provient. Donc, si je devais faire script.php? Loggedin = 1, je serais connecté. Vu qu'il y a ~ 300 fichiers PHP, il serait difficile de tout vérifier.

Donc le garder est une (très) mauvaise idée. Même si vous utilisiez .htaccess pour bloquer l'accès, cela conduirait probablement à des problèmes dans le futur (réglage de l'hébergeur Web IE REGISTER_GLOBALS) et de la confusion.

Answer 3

Ne pas réécrire tout le système. Si le système fonctionne et que vous allez le mettre à niveau en cours de route, vous n'avez pas besoin de recommencer à zéro.

Je voudrais peser l'importance d'adresser les registres Globals basé sur la sensibilité de l'information.

Si c'est un système bien construit, vous devriez être en mesure de voir quelles variables sont utilisées dans tout le site et de les rendre simplement disponibles en haut des pages. Méfiez-vous de toutes les fonctions qui tirent leurs données à travers $ this, $ cela;

Mon vote, si les données sont importantes à protéger, est de faire le travail.

Answer 4

Cette application pourrait être jonchée de nombreuses autres pratiques de programmation de mauvaise qualité. (Quelle est la taille de l'application pour justifier 300 fichiers php?). Si c'est le cas, il pourrait être judicieux de laisser l'application telle quelle et de coder une nouvelle version à partir d'un cadre décent si la maintenance est déjà devenue trop compliquée.

Answer 5

Cela dépend de votre quotidien.Juste pour en nommer quelques-uns:

1. la politique de sécurité de l'entreprise
2. Coût de réécrire
3. L'importance de l'application
4. Impact sur d'autres parties de l'application.
5. etc

Answer 6

Je register_globals de la désactiver php.ini et mettre un bloc de code en haut de chaque script qui extrait les variables du _REQUEST $, $ _GET ou $ _POST, quelque chose comme:

$nVars = extract($_GET, EXTR_SKIP); 

Le code ci-dessus enregistre les variables sous le même nom que la clé du tableau transmis. C'est utile pour refactoriser rapidement le vieux code activé par REGISTER_GLOBALS, mais vous devez faire attention. Lisez l'extrait de la documentation PHP extract() suivante:

Ne pas utiliser extract() sur des données non fiables, comme entrées utilisateur ($ _GET, ...). Si vous faites, par exemple, si vous voulez terme ancien code qui repose sur register_globals temporairement, assurez- que vous utilisez l'un des extract_type non-écrasement valeurs telles que EXTR_SKIP et être conscient que vous devez extraire dans la même commande définie dans variables_order dans le fichier php.ini.