Avec cette option , celà revient à mettre [b]register_globals[/b] à [b]on[/b] .. pas conseillé donc .

Imagine ton code , tu utilises une variable nommé [b]$toto[/b] pour un traitement spécifique dont tu afficheras le résultat plus tard ..
Tout va bien jusqu'au moment ou tu utilises extract($_POST,EXTR_OVERWRITE) , car dans ton formulaire tu as un champ nommé toto

ex : <input type='text' name='toto'>

Et bien ta variable $toto qui possède le resultat d'un traitement sera simplement écrasé par le contenu du champ , qui peut trés bien contenir du code malicieux ... si $toto est utilisé dans la suite du code , il peut donc y avoir une injection de code , ou simplement provoquer un beau plantage .

utiliser extrac pour $_POST et $_GET est d'autant plus dangereux que le nom des variables passé dans les entêtes / corps http , sont tres simplement modifiables !
Donc même si tu te dit , pas de problème .. il n'y a aucune correspondance entre les noms de champs de mon formulaire , et variables à l'intérieur de mon code , ce n'est pas figé !

Bon , apres , tu auras peu ( enfin , je pense ) d'attaques de ce genre , mais autant faire quelque chose de propre .. de plus ce là ne t'avancera pas beaucoup d'utiliser cette méthode , tu devras quand même traiter 1 par 1 tes variables récupérées .. alors autant rester avec $_POST['ma_var']

Sinon , je conseille plutôt EXTR_PREFIX_ALL comme option , qui te préfixera toujours le nom de tes variables ... ce qui évite les collisions .

Pour les requêtes préparé , tu as plusieurs avantages ( de secu et perf ) , je te laisse lire la doc à ce sujet :

http://fr2.php.net/manual/fr/pdo.prepare.php

Ch.

extract($_POST,EXTR_OVERWRITE);

[quote="stopher"]Collision avec des variables existantes , .. modification ou non , bref il faut savoir ce que l'on fait en utilisant correctement l'argument "extract_type" de la fonction .[/quote]

La tu parles de par exemple :
[php]extract($_POST,EXTR_OVERWRITE);[/php]

Le fait de mettre "$_post" limite l'extraction de variables à ce type. C'est de ça dont tu parlais ?

[quote="stopher"]Pour la vérification , en premier lieu , nettoyer le contenu par un simple htmlentities peut être automatisé , et si en plus tu prépares tes requetes , alors la le danger d'injection est déjà bien écarté ... [/quote]

Qu'entends tu par "préparer tes requêtes" ?

Merci de ta réponse

Slt ,

Pour extract , le risque et de ne pas complétement maitriser les variables ...

Collision avec des variables existantes , .. modification ou non , bref il faut savoir ce que l'on fait en utilisant correctement l'argument "extract_type" de la fonction .

Ceci dit , si tu utilises des régles de nommage de tes varialbes internes à ton code , normalement le risque de collision avec le nom des variables provenant de nom de champ de formulaire est réduit ... apres le nom d'un champ , se change très simplement .. donc bon ...


Concernant l'utilisation de ces variables dans une requete , qu'elle soit SELECT ou INSERT , le danger d'injection Sql est le même ... il faut toujours vérifier ce qui rentre .. et ce qui sort .. toujours .. c'est parfois chiant et répétitif , mais nécessaire !

Pour la vérification , en premier lieu , nettoyer le contenu par un simple htmlentities peut être automatisé , et si en plus tu prépares tes requetes , alors la le danger d'injection est déjà bien écarté ...
Ensuite , la vérification de type est "selon moi" important , afin de maitriser le maximum de réactions possible de ton appli , quelque soit les données envoyées par le client .

Car ce n'est pas par ce que tu demandes un entier dans ton formulaire que tu auras un entier ... et si cela provoque une erreur non maitrisé ... tu ne sais pas quelles réactions an chaine il peut y avoir derrière .. ( c'est peut être un cas extrême .. mais à avoir en tête tout de même )
D'ou l'importance de toujours out vérifier . ( mais rien ne t'y oblige )

Ch.

Bonjour,

j'ai découvert une fonction qui simplifie la réception des données d'un formulaire par exemple.
La fonction [b]extract()[/b]

En parcourant un peu le net, il y a des réserves de sécurité qui sont émises à son propos.
Mais quand on reçoit pas mal de données il faut avouer que ça va beaucoup plus vite d'écrire une ligne plutôt que 30 pour réceptionner les données d'un formulaire.

Est ce qu'on peut l'utiliser ou vaut-il mieux l'éviter ?
Si on peut l'utiliser, est ce qu'il y a des conditions pour minimiser ce risque de sécurité ?
Est ce que le fait de l'utiliser sur des requêtes "SELECT" et non "INSERT" de Mysql réduit le risque ou ça n'a rien a voir ?

Merci à vous