Merci pour la question intéressante. Voilà :
Il échappe aux caractères dangereux,
Votre concept est totalement faux.
En fait "caractères dangereux" est un mythe, il n'y en a pas.Et mysql_real_escape_string s'échappe mais simplement un délimiteur de chaîne . À partir de cette définition, vous pouvez conclure que ses limites - cela ne fonctionne que pour les chaînes .
cependant, il est toujours vulnérable à d'autres attaques qui peuvent contenir des caractères sûrs mais peuvent nuire à l'affichage des données ou, dans certains cas, modifier ou supprimer des données de manière malveillante.
Vous mélangez tout ici.
En parlant de base de données,
- pour les chaînes, il n'est PAS vulnérable. Tant que vos chaînes sont entre guillemets et échappées, elles ne peuvent pas "modifier ou supprimer des données de manière malveillante".
* - pour les autres types de donnéesdata - oui, c'est inutile . Mais pas parce qu'il est quelque peu "dangereux", mais simplement à cause d'une mauvaise utilisation.
En ce qui concerne l'affichage des données, je suppose qu'il est hors sujet dans la question relative à PDO, car PDO n'a rien à voir non plus avec l'affichage des données.
échapper à la saisie de l'utilisateur
^^^^ Encore un délire à signaler !
-
une entrée utilisateur n'a absolument rien à voir avec l'échappement . Comme vous pouvez l'apprendre de l'ancienne définition, vous devez échapper les chaînes, pas n'importe quelle "entrée utilisateur". Donc, encore :
- vous avez des chaînes d'échappement, quelle que soit leur source
- il est inutile d'échapper à d'autres types de données, quelle qu'en soit la source.
Compris ?
Maintenant, j'espère que vous comprenez les limites de l'évasion ainsi que l'idée fausse des "personnages dangereux".
D'après ce que je comprends, l'utilisation d'instructions PDO/préparées est beaucoup plus sûre
Pas vraiment.
En fait, il y en a quatre différentes parties de requête que nous pouvons y ajouter dynamiquement :
- 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 les nombres comme des chaînes (en les mettant entre guillemets), le cas échéant , vous pouvez également les sécuriser)
tandis que les déclarations préparées couvrent - ugh - 2 problèmes entiers ! Un gros problème;-)
Pour les 2 autres problèmes, voir ma réponse précédente, En PHP, lors de la soumission de chaînes à la base de données, dois-je prendre soin des caractères illégaux en utilisant htmlspecialchars() ou utiliser une expression régulière ?
Maintenant, les noms de fonction sont différents, donc mes mysql_query, mysql_fetch_array, mysql_num_rows, etc. ne fonctionneront plus.
C'est une autre grave illusion des utilisateurs de PHP , une catastrophe naturelle, une catastrophe :
Même en utilisant l'ancien pilote mysql, il ne faut jamais utiliser les fonctions API nues dans leur code ! Il faut les mettre dans une fonction de bibliothèque pour un usage quotidien ! (Pas comme un rite magique mais juste pour rendre le code plus court, moins répétitif, sans erreur, plus cohérent et lisible).
Il en va de même pour l'AOP !
Maintenant, reprenez votre question.
mais en les utilisant, cela élimine-t-il le besoin d'utiliser quelque chose comme mysql_real_escape_string ?
OUI.
Mais je pense que c'est à peu près l'idée de ce qu'il faut faire pour récupérer un utilisateur à partir d'une base de données
Pas pour récupérer, mais pour ajouter n'importe quelle 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 que tout est sûr ?
En termes de sécurité de la base de données, il n'y a tout simplement pas de points faibles dans ce code. Rien à sécuriser ici.
pour la sécurité d'affichage - il suffit de rechercher sur ce site le XSS mot-clé.
J'espère avoir éclairci le sujet.
BTW, pour les longues insertions, vous pouvez utiliser la fonction que j'ai écrite 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 maison à eux, en utilisant une bibliothèque J'ai mentionné ci-dessus. Alors, pour contrer le code posté par la riha ci-dessous, il serait aussi court que ces 2 lignes :
$sql = 'SELECT * FROM `users` WHERE `name`=?s AND `type`=?s AND `active`=?i';
$data = $db->getRow($sql,$_GET['name'],'admin',1);
Mais bien sûr, vous pouvez également avoir le même code en utilisant des instructions préparées.
* (yes I am aware of the Schiflett's scaring tales)
