sécurité et super-globales...

[oxyd-x]

Salut,

je suis hébergé chez OVH, et ceux-ci, ne permettent pas la modification et le passage de register_globals sur "OFF". (sur un mutualisé;arff)

Alors, je me retrouvre avec plein de questions ...niveau sécurité !

- les variables super-globals (

$_SERVER, $_ENV

, ...) sont-elles concernées par la modification à la volé dans les urls ? si oui, éxiste-t-il un moyen de corriger ceci ?

- le fait d'initialiser une variable

$montest=null;

est-il suffisant pour la protéger ?

j'espere vraiment que quelqu'un pourra m'aider, parceque là, apres des heures de recherche sur le net (francais, bin oui, j'suis pas bilingue) je n'ai trouvé que des docs sur "comment passer à register_globals off" (mais pas de : comment etre emmerd... avec register_globals on )...

enfin, merci pour votre aide ;

ps: si par exemple, je veut obtenir l'adresse ip d'un visiteur

$ip=null;$ip=$_SERVER['REMOTE_ADDR'];

celle-ci peut-elle est modifié par le visiteur (je parle uniquement des register globals, pas des proxy, ...,...)

[minirop]

le vrai problème avec les register global sur on c'est que si tu t'habitues a coder comme ca :

<?php
mysql_query('INSERT INTO table VALUES('.$message.')');
?>

et que tu as un formulaire qui envoie cette valeur en hidden sur cette page, il suffira d'appeler

page.php?message=hack (sans passer par le formulaire donc) pour mettre la valeur qu'on veux.

(l'exemple est pourri mais j'ai pas trouver mieux)

si tu utilises la syntaxe superglobale $_XXX[''], mais faut bien initialiser les autres variables car elles pourraient quand meme être modifiée via l'url (et utilise des nom assez zarb pour pas qu'on puisse les deviner facilement)

voila

[TheRec]

Bonjour,

l'essentiel est de toujours vérifier la nature (le type) et le contenu des variables. Une bonne pratique pour ce faire est d'initialiser les variables que tu utilises, de cette manière même si l'utilisateur fournit une valeur par l'URL elle sera remplacée par celle qui tu souhaites, je parle des variables qui ne proviennent pas des utilisateurs.

Par contre, pour les variables provenant des utilisateur, dans tous les cas possibles il faut limiter leur valeurs possibles au strict minimum. Si tu connais les valeurs qu'elle auront (par exemple un champ select), limite les possibilités à celles-ci. Si tu ne peux pas connaître leur valeur (par exemple un champ texte), vérifie le type, utilise (comme pour toutes autres variables) les fonctions d'échapement lors d'insertion dans la base, empêche l'utilisation des balises (X)HTML si elle ne sont pas nécessaires. Mais ces points sont plus relatifs à l'utilisation d'une base de données.

Si tu utilises les tableaux de super-gloales ($_POST, $_GET, ...) tu n'auras pas ces problèmes (cités dans le 2ème paragraphe de ce message), mais ce que je t'ai cité plus haut sont des bonnes pratiques (à mon goût en tout cas) en programmation.

Pour répondre à tes deux questions, certaines valeurs de $_SERVER peuvent être modifiés par l'utilisateur ($_SERVER['HTTP_USER_AGENT'] entre autres), mais cela demande plus qu'une simple modification d'URL. Ce n'est tout fois pas à négliger. Concernant $_ENV, les valeurs sont définies par le serveur et ce problème n'est donc pas important dans la mesure où si tu fais assez confiance au serveur pour héberger les sources de tes scripts tu devrais lui faire assez confiance pour gérer ses variables internes

Le fait d'initialiser à null certaines variables peu résoudre certains problèmes mais l'exemple que tu cite n'est pas réellement un de ces cas. Le risque se situe surtout lorsque tu utilises une variable qui n'a pas été initialisée ou contrôlée tu risques d'avoir un contenu "malicieux" qui aura été fourni par l'utilisateur au moyen de l'URL. Le fait de l'initialiser à null n'a pas réellement de sens dans ton exemple vu que tu remplaces, tout de suite après, son contenu avec celui de la variable $_SERVER['REMOTE_ADDR'].

P.S.:

Il faut te dire avant tout que le mode register_globals depuis PHP4 a été conservé pour des raisons de compatibilité, c'est pour cela que certains hébergeurs conservent ce paramètres activé. Cela "te fais une belle jambe" sûrement mais c'est pour t'expliquer pour quelles raisons les hébergeurs conservent ce paramètre. Bien que beaucoup d'entre eux n'ont fait cela que pour éviter les questions que tu poses, certains on pris sur eux et on décidé de désactiver ce paramètre par défaut pour assurer une meilleure sécurité à leurs serveurs mutualisés...

[ste]

Comme le dit TheRec, sécuriser ses variables, et donc les définir, et vérifier absolument la concordance retournée est impérative !

Une fonction "sécurisée" de test, telle que la suivante, est certainement très intéressante de ce point de vue, surtout en termes de valeurs qui peuvent être injectées dans des variables pour base de données ou accessibles à l'utilisateur :

<?php
# On n'exécute la boucle que si nécessaire
if(get_magic_quotes_gpc() == 1) {

# Définition de la fonction récursive.
    function remove_magic_quotes($array) {
        foreach($array as $key => $val) {

        # Si c'est un array, recurssion de la fonction, sinon suppression des slashes
            if(is_array($val)) {
                remove_magic_quotes($array[$key]);
            }
            elseif(is_string($val)) {
                $array[$key] = stripslashes($val);
            }
        }
        unSet($key, $val);
    }

# Appel de la fonction pour chaque variables.
# Notes, vous pouvez enlevez celle d'on vous ne vous servez pas.
# Personnellement, j'enlève $_REQUEST et $_FILES

    remove_magic_quotes($_POST);
    remove_magic_quotes($_GET);
    remove_magic_quotes($_REQUEST);
    remove_magic_quotes($_SERVER);
    remove_magic_quotes($_FILES);
    remove_magic_quotes($_COOKIE);
}
?>

Ainsi, si la constante 'magic_quotes_gpc' est défini - le test par la function PHP 'get***' s'en assure - et dès qu'elle trouve une chaine de caractères, elle l'a passe à la moulinette de la function PHP stripslashes !

Autrement, il n'y en a pas besoin...

[oxyd-x]

Salut,

merci à vous pour vos réponses, concernant le typage des données, je le fais déjà, le hic, c'est que j'ai TOUJOURS programmé avec un globals sur off. Je suis donc perdu maintenant que cette option est obligatoirement active.

Merci à vous pour votre aide, @+ sur le hub