Discussion :

[infiniti]

Bonjour tout le monde,

Comment faire pour sécuriser le passage de variable via GET ou Post ?
Je suis tombé sur ce code (1ere portion pour Get, seconde pour POST) :

Pour info, je n'ai pas magic_quotes installé sur le serveur
Est-ce que ce code est efficace ? Dois je le conserver tel quel ou y a t il quelque chose d'inutile ?

Merci d'avance pour votre aide, toujours très préciseuse :-)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?
if(isset($_GET) && is_array($_GET))
    foreach($_GET as $key => $value){
        if(ini_get(register_globals))$value=stripslashes($value);
        $value=htmlentities($value,ENT_QUOTES);
        $_GET[$key]=$value;
        ${$key}=$value;
    }
if(isset($_POST) && is_array($_POST))
    foreach($_POST as $key => $value){
        if(ini_get(register_globals))$value=stripslashes($value);
        $value=htmlentities($value,ENT_QUOTES);
        $_POST[$key]=$value;
        ${$key}=$value;
    }
?>

[Eusebe]

Bonjour,

Pour sécuriser les paramètres reçus d'un utilisateur, il n'y a pas de recette magique, il faut vérifier que les données sont bien ce que l'on attend, et si on attend une chaîne de caractères, il faut l'échapper en fonction de son utilisation.

Appliquer la fonction htmlentities à tous les paramètres ne me parait donc pas judicieux. Si la chaîne doit être insérée dans une base de données, il faut l'échapper avec les fonctions fournies par le connecteur à la base (par exemple mysql_real_escape_string) ; si la chaîne est destinée à être utilisée dans une url, il faut utiliser urlencode ; si la chaîne est destinée à être affichée dans un document html, il faut utiliser htmlentities, etc...

Comme tu peux le voir, htmlentities répond à une utilisation de la chaîne, pas à toutes... Ca me semble donc aussi judicieux de l'appliquer à tous les paramètres, que d'appliquer un échappement des apostrophes, comme cela est souvent fait avec les magic_quotes (ce qui protège des injections sql, mais est souvent gênant si on souhaite afficher le paramètre directement).

Pour moi, la protection des chaînes de caractères passées en paramètre doit donc se faire au plus près de leur utilisation, et non pas à la source.

Pour les autres paramètres (nombres, dates, etc...), le mieux est de vérifier qu'ils contiennent le bon type de données et de les transformer en variables du bon type : par exemple $nb_resultats = (int) $_POST['nb_resultats'].

[infiniti]

salut, merci pour ta réponse !

Ok je comprends mieux. Vu en l'occurrence que je ne prends en Get que des ID numériques, j'ai du coup, et c'est vrai que c'est tellement plus simple, filtré cela de cette façon :

<?php
if(isset($_GET['id'])) {
$id=(int)$_GET['id'];
}
?>

J'ai un champ de formulaire de recherche, envoyé lui aussi en GET. Connaitrais tu un moyen de sécuriser les mots clés envoyés dans la recherche, histoire d'être sûr qu'il ne s'agit pas d'inclusion SQL ?

Merci beaucoup !

[Inazo]

Bonjour,

Je suis un peu du même avis que "Eusebe", surtout de la manière dont tu as traité tes "post" qui ne te protégera jamais d'une injection SQL.

Pour te couvrir des injections SQL, passe toutes les chaînes qui te servirons dans la fonction : mysql_real_escape_string().

Cordialement,

[kaymak]

Alors j'en rajoute une petite couche, mais la déclaration automatique des variables get / post, rappelez vous php4, si il y avait $_GET["something"] sa créé une variable $something.
Bref, cette méthodologie, quoique pratique de prime abord, est finalement complètement déconseillée.
De souvenir ce comportement à disparut, ou va disparaître prochainement.

Hors là, c'est typiquement ce que le script fais

L'explication en question pour ceux qui comme moi l'aurait un peu oubliée : http://fr.php.net/register_globals

Sinon oui, il faut traiter tes variables au cas par cas en fonction du type de valeur attendu.
Perso je préfère tester l'existence de mes variables, si elle n'existe pas, j'assigne une valeur par défaut, qui lors de la validation provoquera un warning utilisateur.
Lorsque la variable existe, je force TOUJOURS le type. Et enfin je teste le format.
Si tout est ok. Sa roule on envoit, vers la base de données.
A ce moment, ce sont les fonctions d'enregistrement qui se chargent de faire le nécessaire pour protéger les requêtes des injections sql.

voilà a plus

[infiniti]

ok mais j'ai besoin de faire ce genre de tests sur ma variable si la requête SQL n'est qu'un simple SELECT, et non un INSERT TO ???