J'ai une application qui prend des données via une demande postale. J'utilise ces données pour insérer une nouvelle ligne dans la base de données. Je sais que d'utiliser Cependant, je voulais m'assurer que Merci. mysql_real_escape_string () (plus enlever% et _) est le moyen d'aller pour les chaînes, mais qu'en est-il des valeurs entières? En ce moment, j'utilise la fonction PHP intval () sur eux.
intval () est parfaitement sûr. Je ne vois pas un moyen d'une attaquante préformant une attaque d'injection SQL lorsque les variables sont exécutées par intval () d'abord (puisqu'il retourne toujours un entier), mais je voulais m'assurer que c'est le cas de personnes qui ont plus d'expérience que moi.
4 Réponses :
oui, intval () est sûr. Il n'y a absolument aucun moyen d'effectuer une injection SQL lorsque le paramètre est converti en entier, car (évidemment) le format d'un entier n'autorise pas la mise en place de mots-clés SQL (ou citations ou autre) dedans.
Ok, c'est ce que je pensais. Merci.
Vous pouvez également utiliser (int) $ id car la coulée est beaucoup plus rapide que d'utiliser la fonction intval ($ id) . Vérifiez: HAKRE.WordPress.com/2010/05/13 / PHP-CASTING-VS-INTVAL
Es-tu sûr? Cause Intval est un lot permissive sur ce qu'il faut comme paramètre d'entrée. Ce code produit des résultats entier corrects, mais je ne voudrais jamais de telles valeurs dans mes requêtes: $ var = "123type_juggling"; var_dump (is_numérique ($ var)); var_dump ((int) $ var); var_dump (intval ($ var));
Intval retournez toujours INT, pourquoi ne voudriez-vous pas?
Le moyen le plus simple d'empêcher l'injection SQL est de toujours utiliser des stations préparées. Utilisez les bibliothèques MySQLI ou mieux encore une orje telle que la doctrine, etc.
Vos requêtes sont alors quelque chose comme:
+1 pour des déclarations préparées. Cependant, je validerais toujours les données d'entrée d'utilisateur avant d'exécuter un insert afin d'éviter une exception SQL. À moins que, bien sûr, l'orj ou le cadre faisait cela pour moi.
Malheureusement, des déclarations préparées ne sont pas disponibles pour ce projet particulier.
Je fais toujours pour vous assurer que $ var est traité comme un entier en toutes circonstances et ne regarde jamais $ _post ["var '] à nouveau. En regardant le manuel, intval () fait exactement la même chose. Quelle que soit la manière dont vous allez, en ultérieurement varier sera un entier réel, tout à fait sûr à gérer.
La déclaration préparée est la meilleure façon de traiter l'injection SQL. ou utiliser pdo Sinon, Intval est meilleur que IS_Numeric
Heads Up: Si vous traitez de chiffres de plus de 32 ou 64 bits (selon votre plate-forme)
intval () retournera zéro. Ceci est évidemment indésirable si vous essayez de stocker de très grands nombres dans votre base de données. Par exemple, les identifiants de Facebook ne correspondent pas à 32 bits pendant des années développeurs.facebook.com/blog/ Post / 45@Frank Farmer: HM .. c'est intéressant. Merci pour l'information. Je vais regarder dans ce que nous pouvons faire pour résoudre ce problème, si nécessaire.