Remplacement des fonctions MySQL_ * avec des déclarations PDO et préparées

Pour répondre à la question de la longueur, spécifiez-le est facultatif, sauf si le paramètre de paramètre de paramètre est un paramètre OUT à partir d'une procédure stockée, donc dans la plupart des cas, vous pouvez l'omettre en toute sécurité.

En ce qui concerne la sécurité, l'échappement est terminé. dans les coulisses lorsque vous liez les paramètres. Cela est possible car vous avez dû créer une connexion de base de données lorsque vous avez créé l'objet. Vous êtes également protégé des attaques d'injection SQL depuis la préparation de la déclaration, vous indiquez à votre base de données au format de l'instruction avant que l'entrée de l'utilisateur ne puisse obtenir n'importe où. Un exemple: xxx

Ainsi, en termes de sécurité, vos exemples ci-dessus semblent bien.

Enfin, je conviens que les paramètres de liaison individuellement sont fastidieux et sont Tout comme efficacement fait avec un tableau transmis à PDOStatement-> Exécuter () (voir http: //www.php.net/manual/fr/pdostatement.execute.php ).

Merci pour la question intéressante. Vous y allez:

Il échappe aux caractères dangereux,

Votre concept est tout à fait faux.

En fait, "personnages dangereux" est un mythe, il n'y en a pas. Et mysql_real_escape_string s'échappant mais simplement un délimiteurs de chaîne . À partir de cette définition, vous pouvez conclure ses limitations - cela ne fonctionne que pour Strings .

Cependant, il est toujours vulnérable à d'autres attaques pouvant contenir des caractères sûrs, mais peut être nocif pour afficher des données ou dans certains cas, modifier ou supprimer des données malicieusement.

Vous mélangez ici tout.
Parlant de base de données,

• pour les cordes, il est pas vulnérable. aussi longtemps que vos cordes citées et échappées, elles ne peuvent "modifier ou supprimer des données malicieusement". * < / code>
• pour les autres données Typedata - Oui, c'est inutile . Mais pas parce que c'est un peu "dangereux" mais juste à cause d'une utilisation inappropriée.

  Quant aux données d'affichage, je suppose qu'il est offtopic dans la question liée à la PDO, comme PDO n'a rien à voir avec l'affichage des données non plus. < / p>

  Échapper l'entrée utilisateur

  ^^^ Une autre illusion à noter!

  • Une entrée d'utilisateur n'a absolument rien à voir avec une échappée . Comme vous pouvez apprendre de la définition antérieure, vous devez échapper aux chaînes, pas n'importe quelle "entrée utilisateur". Donc, encore une fois:

    • Vous avez des cordes d'évasion, quelle que soit leur source
    • Il est inutile d'échapper à d'autres types de données, quelle que soit la source.

      a eu le point?
      Maintenant, j'espère que vous comprenez les limites de l'échappement ainsi que de la fausse idée des "personnages dangereux".

      C'est à ma compréhension que l'utilisation de déclarations de PDO / préparées est une beaucoup plus sûre

      pas vraiment.
      En fait, il existe quatre différentes parties de requête que nous pouvons y ajouter de manière dynamique:

      • une chaîne
      • un nombre
      • un identifiant
      • Un mot clé de syntaxe.

        Ainsi, vous pouvez voir que l'échappement ne couvre qu'un seul problème. (Mais bien sûr, si vous traitez des chiffres en tant que chaînes (les mettre dans des guillemets), le cas échéant, vous pouvez les faire en sécurité)

        tandis que des déclarations préparées - UGH - Entier 2 Isues! Une grosse affaire; -)

        pour les 2 autres numéros Voir ma réponse précédente, Dans PHP Lors de la soumission des chaînes à la base de données Devrais-je m'occuper de caractères illégaux à l'aide de HTMLSpecialchars () ou d'utiliser une expression régulière?

        MAINTENANT, les noms de fonction sont différents, donc ne plus mon mysql_query, mysql_fetch_array, mysql_num_rows, etc.

        c'est une autre, grave illusion de php utilisateurs , une catastrophe naturelle, une catastrophe:

        même lorsqu'il utilise Old MySQL Driver, On ne devrait jamais utiliser les fonctions d'API nues dans leur code! Il faut les mettre dans une fonction de bibliothèque pour l'utilisation quotidienne! (Pas comme un rite magique, mais simplement pour rendre le code plus court, moins répétitif, une épreuve d'erreur, plus cohérente et lisible).

        la même chose va aussi pour le PDO!

        maintenant sur votre question à nouveau.

        mais en les utilisant, cela élimine la nécessité d'utiliser quelque chose comme mysql_real_escapape_string?

        oui.

        Mais je pense que c'est à peu près l'idée de ce qui devrait être fait pour récupérer un utilisateur d'une base de données

        ne pas récupérer, mais pour ajouter une donnée à la requête !

        Vous devez donner une longueur après PDO: Param_str si je ne me trompe pas

        Vous pouvez, mais vous n'êtes pas obligé.

        Maintenant, est-ce tout sûr?

        En termes de sécurité de la base de données, il n'y a pas de points faibles dans ce code. Rien à sécuriser ici.

        pour l'affichage de la sécurité - il suffit de rechercher ce site pour le mot clé xss .

        J'espère que je vis une lumière sur la matière.

        BTW, pour les inserts longs, vous pouvez utiliser la fonction que j'ai écrit un jour, Insérer / mettre à jour la fonction d'assistance à l'aide de PDO

        Cependant, je n'utilise pas de déclarations préparées pour le moment, car je préfère mes espaces réservés à domicile sur eux, en utilisant une bibliothèque j'ai mentionné ci-dessus. Donc, pour contrer le code posté par le RIHA ci-dessous, il serait aussi court que ces 2 lignes: xxx

        mais bien sûr, vous pouvez avoir le même code à l'aide de déclarations préparées bien.

        ---

        * (Oui, je suis au courant des contes de peur de Schiflett)