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

Discussion dans 'Développement d'un site Web ou d'une appli mobile' créé par seïna, 16 Avril 2008.

  1. seïna
    seïna Nouveau WRInaute
    Inscrit:
    16 Avril 2008
    Messages:
    5
    J'aime reçus:
    0
    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]
     
  2. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 543
    J'aime reçus:
    0
    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 ) );
     
  3. seïna
    seïna Nouveau WRInaute
    Inscrit:
    16 Avril 2008
    Messages:
    5
    J'aime reçus:
    0
    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...
     
  4. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 543
    J'aime reçus:
    0
    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.
     
  5. seïna
    seïna Nouveau WRInaute
    Inscrit:
    16 Avril 2008
    Messages:
    5
    J'aime reçus:
    0
    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?
     
  6. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 543
    J'aime reçus:
    0
    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.
     
  7. seïna
    seïna Nouveau WRInaute
    Inscrit:
    16 Avril 2008
    Messages:
    5
    J'aime reçus:
    0
    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.
     
  8. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 543
    J'aime reçus:
    0
    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
     
  9. seïna
    seïna Nouveau WRInaute
    Inscrit:
    16 Avril 2008
    Messages:
    5
    J'aime reçus:
    0
    Mille mercisssss pour toutes ces précision et la rapidité.
    :D
     
Chargement...
Similar Threads - Connexion PDO sécuriser Forum Date
Prise en compte de GA seulement de la page de connexion Google Analytics 3 Mai 2022
Connexion au compte Google Search Console d'un client Google : l'entreprise, les sites web, les services 28 Avril 2022
Problème serveur connexion simultanée Administration d'un site Web 19 Janvier 2022
Signaler aux crawler de ne pas suivre un lien qui nécessite une connexion Crawl et indexation Google, sitemaps 9 Juin 2021
Connexion via comptes Google et Facebook Développement d'un site Web ou d'une appli mobile 15 Mai 2020
Safari ne peut pas établir de connexion sécurisée au serveur Demandes d'avis et de conseils sur vos sites 5 Mai 2020
Connexion à un serveur mysql distant Développement d'un site Web ou d'une appli mobile 21 Octobre 2018
Quelle origine connexion http en javascript ? Développement d'un site Web ou d'une appli mobile 11 Juillet 2018
RGPD : délai de conservation des données (de connexion) Droit du web (juridique, fiscalité...) 30 Avril 2018
Curl et une page de connexion Développement d'un site Web ou d'une appli mobile 9 Février 2018
Surveiller les connexions à la base de données MySQL Développement d'un site Web ou d'une appli mobile 1 Février 2018
Connexion à Paypal impossible. e-commerce 11 Mai 2017
Certificat ssl : message Votre connexion n'est pas privée Administration d'un site Web 19 Avril 2017
Connexions régulières d'un visiteur qui monte le taux de rebond Google Analytics 30 Octobre 2016
Site en HTTP : Chrome avertit que la connexion n'est pas privée Développement d'un site Web ou d'une appli mobile 6 Septembre 2016
Interconnexion reseau de sites internationaux Référencement international (langues, pays) 16 Août 2016
Connexion à une BDD externe Développement d'un site Web ou d'une appli mobile 13 Janvier 2016
Nginx + Pagespeed => pas de connexion https ? Administration d'un site Web 13 Décembre 2015
Problème de connexion à Filezilla Débuter en référencement 25 Août 2015
Stats GWT et Analytics incohérentes / connexion https Débuter en référencement 16 Juin 2015