Connexion PDO : comment sécuriser les champs de formulaire?

  • Auteur de la discussion Auteur de la discussion seïna
  • Date de début Date de début
Nouveau WRInaute
Bonjour, je suis nouvelle sur le forum. Je poste rarement sur les forums mais j'ai cherché partout une solution à mon problème en vain... Je suis débutante en php
J'avais fait un petit programme pour un livre d'or amélioré pour mon site avec la connexion mysql_connect. J'ai ensuite changé le type de connexion pour utiliser PDO. Cependant pour sécuriser mon formulaire je récupérais les infos avec des variables POST précédées de mysql_real_escape_string et htmlentities. On m'a dit que tout ce qui est mysql.... ne fonctionnait plus avec les connection PDO et on m'a conseillé d'utiliser PDO::quote sauf que ça ne marche pas. Par exemple pour récupérer ce qui est rentré dans le champ mot de passe, ça semble le transformer puisque ça rend tous les mots de passe faux, même s'il est correct. Ce qui n'arrive pas si j'enlève la ligne en question.
Je voulais sécuriser tous les champs accessibles à l'utilisateur mais je ne sais plus quelle fonction utiliser. Comment faire??

Ensuite concernant PDO je voulais savoir si on fait une connexion persistante et qu'on met $connexion=null à la fin de la page, est ce que ça ferme complètement la connexion ou est ce que ça la met juste proprement en stand by?

Je vous mets l'extrait de code concernant le mot de passe (mais sur les autres pages il y a d'autres endroits où il y a d'autres champs) :

Code:
else
            {
            $motPasse=htmlentities($_POST['motPasse']);
            $motPasse=$connexion->quote($motPasse);
            // on vide la 1ère variable du champ texte
            unset($_POST['motPasse']);
            //on récupère le vrai mot de passe dans la base de données
                        
            $req=$connexion->query('select passe from moderation') or die(mysql_error());
            $result=$req->fetch(PDO::FETCH_ASSOC);                 
            //on le stocke dans variable $passeVrai
            $passeVrai=$result['passe'];
            if($motPasse==$passeVrai)
                {
                header("Location: moderation2PDO.php");
                exit;
                }
            else
                {
                $page_html.='Ce mot de passe n\'est pas valable';
                }
            }
[/code]
 
WRInaute passionné
Hello,

avec PDO le mécanisme "idéal" pour protéger les variables est d'utiliser la "préparation" de requêtes. Ca donne :
Code:
$stmt = $pdo->prepare( "select champ1, champ2 from tatable where login = ?" );
$stmt->execute( array( $login ) );

Les "?" dans la requête seront remplacés par les valeur du tableau utilisé lors de l'appel à execute(). Cette méthode a l'avantage de protéger automatiquement toutes les variables, en plus d'un gain de performances selon les cas.
On peut également utiliser ce système de manière plus poussée, mais je te laisse te reporter à la doc pour ces détails.


Pour ma part j'utilisais déjà cette méthode bien avant PDO, et j'en suis très satisfait. J'ai d'ailleurs surchargé la méthode "query" afin qu'elle accepte ces paramètres, ce qui donne :
Code:
$res = $pdo->query( "select champ1, champ2 from tatable where login = ?", array( $login ) );
 
Nouveau WRInaute
Merci pour l'info. Mais la préparation de requête est ce que ça vaut le coup si la requête n'est utilisée qu'une seule fois? Parce qu'il me semblait que c'était plus gourmand.
Sinon, il me semble que cela ne résout pas le problème concernant la sécurisation des champs de formulaire sans qu'il n'y ait de requête, ex : quand je récupère le mot de passe rentré par le visiteur. A moins qu'il y ait quelque chose qui m'échappe...
 
WRInaute passionné
Je ne suis vraiment pas certain que le surcoût du prepare() soit supplémentaire aux appels de mysql_real_escape_string().
A mon avis au final les gains d'un coté compensent les pertes de l'autres... avec au passage un risque d'oubli (et donc de failles) bien moins élevé.

Pour ce qui est de la "sécurisation" c'est uniquement pour une requete SQL justement.
mysql_real_escape_string() ne fait que protéger pour des requetes SQL également.
Que veux tu lui faire de plus à ce "mot de passe" ? Il ne pose soucis que s'il est utilisé...
Dans une requête MySQL, il faut évidement protéger le code SQL de cette entrée. Dans du code HTML, il faut aussi protéger la dite entrée, mais la méthode est radicalement différente.
 
Nouveau WRInaute
Ok je comprends concernant le code Sql. Mais donc concernant l'Html, utiliser htmlentities comme je le fais là :
Code:
$motPasse=htmlentities($_POST['motPasse']);
suffit donc à protéger le formulaire? Pas besoin d'autre chose?
 
WRInaute passionné
Il n'y a pas de "protection de formulaire" : htmlentities ça ne va te servir que si tu cherches à mettre ce mot de passe dans du HTML.
Et dans le cas du mot de passe, j'ose espérer que ce n'est pas le cas.

Au moment d'afficher la variable, tu fais un htmlentities() (ou htmlspecialchars). Au moment de faire une requête SQL, tu fais un mysql_real_escape_string() ou équivalent, selon le driver. Quand tu intègres la variable à un fichier CSV, tu ajoutes les échappements adéquats. Si la variable est utilisée en ligne de commande, tu utilises là aussi la fonction d'échappement adéquate (par exemple escapeshellarg[/b]).

Il n'existe aucune fonction magique commune à toutes les utilisations (d'où les problèmes avec magic_quotes_gpc, qui est une belle annerie).

Et si tu tiens vraiment à sécuriser ton code, ne stocke pas tes mots de passe en clair dans la base de données.
 
Nouveau WRInaute
Bon ben d'accord. Je vois.
Effectivement je comptais m'occuper ensuite de crypter le mot de passe mais là dessus ça va il y a de la doc.
En fait concernant la sécurité il y a pas mal de choses mais c'est vrai qu'il y a aussi beaucoup de contradictions et j'ai un peu de mal à m'y retrouver.
Il faudrait faire un stage en hacking :lol: pour comprendre vraiment les dangers potentiels.
Merci de ces infos précieuses. Je suis preneuse de tout ce qui concerne ce sujet surtout en lien avec les connexions PDO.
En fait je vais t'emboîter le pas et passer aux requêtes préparées je pense.
Sinon concernant ma question sur la "fermeture" $connexion=null; quelqu'un aurait-il des précisions.
En fait je ne comprends pas trop étant donné que la connexion est persistante (puisque je lui demande d'être ainsi) à quoi sert le
Code:
$connexion=null
et faut-il quand même le mettre?
Mais comme il faut remettre à chaque fois l'instruction d'ouverture de connexion sur les pages qui suivent, peut-être est ce quand même nécessaire.
 
WRInaute passionné
Prendre le pli de mettre systématiquement le "$connexion = NULL" apporte à priori deux choses :
- cela libère aussitôt la mémoire consommée par l'objet PHP. Même si la connexion "SQL" reste établie.
- cela évite de devoir modifier tout le code le jour où tu devras désactiver les connexions persistantes
 
Discussions similaires
Haut