J'utilise des instructions préparées et MySQLi avec mes requêtes pour protéger contre les attaques par injection. Les instructions préparées supprimeraient-elles complètement le besoin de mysql_real_escape_string? Y a-t-il autre chose que je devrais considérer en sécurisant mon site?Est-ce que les instructions préparées sécuriseraient complètement mon site Web de l'injection de MySQL?
Tant que vous utilisez correctement les instructions préparées, ils le feront. Vous devez vous assurer que vous liez toutes les variables externes et ne les placez pas directement dans la requête.
Par exemple
$stmt = $mysqli->prepare("SELECT District FROM City WHERE Name=" . $name);
Cette déclaration est en cours de préparation, mais il n'utilise l'une des méthodes lient donc il ne sert à rien. Il est toujours vulnérable à l'injection SQL.
Pour résoudre ce problème assurez-vous de lier tout ...
$stmt = $mysqli->prepare("SELECT District FROM City WHERE Name=?")) {
$stmt->bind_param("s", $city);
J'utilise des instructions préparées et MySQLi avec mes requêtes pour protéger contre les attaques par injection.
Ne le faites pas. N'utilisez pas d'instructions préparées pour vous protéger de quoi que ce soit. Ce n'est pas ce que les déclarations préparées sont pour. C'est juste pour rendre vos requêtes syntaxiquement correctes. Et, en tant qu'effet secondaire, une requête syntaxiquement correcte est également invulnérable à toute attaque.
Donc, il suffit de l'utiliser pour mettre des données dans la requête.
Les instructions préparées supprimeraient-elles entièrement mysql_real_escape_string?
C'est faux du côté de mysql_real_escape_string. cette fonction ne vous protège pas de quoi que ce soit. Si vous appliquez simplement cette fonction à vos données, cela ne la rendrait pas "sûre". cette fonction fonctionne uniquement pour les chaînes entre guillemets.
Bien que oui, l'utilisation d'instructions préparées rend cette fonction obsolète, ainsi que autres règles d'assemblage SQL. Il fait vraiment le travail que vous pensez que mysql_real_escape_string fait. Il rend effectivement toutes les données sécurisées (pour SQL).
Y a-t-il autre chose que je devrais considérer lors de la sécurisation de mon site?
Bien sûr.
Ne pas parler de la ville entière - c'est une autre question et bien trop large, mais encore une fois de requête SQL:
Les instructions préparées ne font que data safe.
Ainsi, vous devez prendre en charge non-données dynamiques parties de la requête, telles que les noms de champs, les opérateurs, etc. Les instructions préparées ne vous aideront pas.
Pourquoi est ce mot - "externe"? Les variables "internes" ne devraient-elles pas être également liées? pourquoi une telle ségrégation? –
Externe comme dans les variables hors de votre contrôle. Par exemple si vous avez défini un nom de table dans votre fichier de configuration (define ('TABLE', 'table')). La seule façon d'injecter sql avec cette variable est d'avoir votre serveur compromis et cette variable définie éditée. – Galen
En fait, vous ne pouvez pas utiliser les noms de table comme étant liés par exemple dans PDO.Vous devrez le coder en dur dans la requête ou le stocker dans une variable. – Galen