les déclarations préparées / les requêtes paramétrisées sont généralement suffisantes pour prévenir 1er ordre injection sur cette déclaration ^* . Si vous utilisez un SQL dynamique non vérifié ailleurs dans votre application, vous êtes toujours vulnérable à l'injection de deuxième ordre .

injection de 2ème ordre signifie que les données ont été parcourues une fois dans la base de données avant d'être incluses dans une requête, et est beaucoup plus difficile à retirer. AFAIK, vous ne voyez presque jamais de vraies attaques d'ordre 2, car il est généralement plus facile pour les attaquants de faire de l'ingénierie sociale, mais vous avez parfois des bogues d'ordre 2 qui apparaissent en raison de caractères extra bénins ' ou similaires.

vous pouvez accomplir une attaque d'injection de 2ème ordre quand vous pouvez faire qu'une valeur soit stockée dans une base de données qui est plus tard utilisée comme un littéral dans une requête. Par exemple, supposons que vous saisissiez les informations suivantes comme nouveau nom d'utilisateur. lors de la création d'un compte sur un site web (en supposant MySQL DB pour cette question):

' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + '

S'il n'y a pas d'autres restrictions sur le nom d'utilisateur, une déclaration préparée ferait toujours en sorte que la requête intégrée ci-dessus ne s'exécute pas au moment de l'insertion, et stockerait la valeur correctement dans la base de données. Cependant, imaginez que plus tard l'application récupère votre nom d'utilisateur de la base de données, et utilise la concaténation chaîne de caractères pour inclure cette valeur une nouvelle requête. Vous pourriez obtenir voir quelqu'un d'autre mot de passe. Depuis les premiers noms dans la table des utilisateurs ont tendance à être admins, vous avez également peut-être juste donné la ferme. (Note aussi: c'est une raison de plus pour ne pas stocker les mots de passe en clair!)

nous voyons, alors, que les déclarations préparées sont suffisantes pour une seule requête, mais par eux - mêmes ils sont pas suffisant pour protéger contre les attaques d'injection sql tout au long d'une application, parce qu'ils manquent d'un mécanisme pour faire respecter ce tous les accès à une base de données dans l'application utilise le code sécurisé. Cependant, utilisé dans le cadre de la bonne conception de l'application - qui peut inclure des pratiques telles que l'examen du code ou l'analyse statique, ou l'utilisation d'un ORM, couche de données, ou couche de service qui limite la dynamique sql - "déclarations préparées sont l'outil principal pour résoudre le problème D'Injection Sql. si vous suivez de bons principes de conception de l'application, de sorte que votre accès aux données est séparé du reste de votre programme, il devient facile d'appliquer ou de vérifier que chaque requête utilise correctement paramétrage. Dans ce cas, l'injection sql (premier et second ordre) est complètement empêché.

---

_{^* il s'avère que MySql / PHP sont (ok, étaient) juste stupide sur la manipulation des paramètres quand de larges caractères sont impliqués, et il ya encore un rare cas souligné dans le autre réponse très votée ici qui peut permettre à l'injection de glisser à travers une requête paramétrée.}

Non, ils ne le sont pas toujours.

cela dépend de si vous permettez à l'utilisateur d'entrer dans la requête elle-même. Par exemple:

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

serait vulnérable aux injections SQL et l'utilisation de déclarations préparées dans cet exemple ne fonctionnera pas, parce que l'entrée de l'utilisateur est utilisée comme un identificateur, pas comme des données. La bonne réponse ici serait d'utiliser une sorte de filtrage/validation comme:

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];
$allowedTables = array('users','admins','moderators');
if (!in_array($tableToUse,$allowedTables))    
 $tableToUse = 'users';

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

Note: vous ne pouvez pas utiliser PDO pour lier les données qui sortent de DDL( Data Definition Language), c'est-à-dire que cela ne fonctionne pas:

$stmt = $dbh->prepare('SELECT * FROM foo ORDER BY :userSuppliedData');

la raison pour laquelle ce qui précède ne fonctionne pas est que DESC et ASC ne sont pas données . AOP ne peut s'échapper que pour data . Deuxièmement, vous ne pouvez même pas mettre ' citations autour de lui. La seule façon de permettre le tri choisi par l'utilisateur est de filtrer manuellement et de vérifier que c'est soit DESC ou ASC .

Oui, c'est suffisant. La façon dont les attaques de type injection fonctionnent, c'est en obtenant d'une manière ou d'une autre un interprète (la base de données) pour évaluer quelque chose, qui aurait dû être des données, comme si c'était du code. Cela n'est possible que si vous mélangez du code et des données sur le même support (par ex. lorsque vous construisez une requête comme une chaîne de caractères).

Paramétrer des requêtes en envoyant le code et les données séparément, de sorte qu'il serait jamais être possible de trouver un trou.

vous pouvez néanmoins être vulnérable à d'autres attaques de type injection. Par exemple, si vous utilisez les données dans une page HTML, vous pourriez être sujet à des attaques de type XSS.

Non cela ne suffit pas (dans certains cas spécifiques)! Par défaut, PDO utilise des déclarations préparées émulées en utilisant MySQL comme pilote de base de données. Vous devez toujours désactiver les déclarations émulées en utilisant MySQL et PDO:

$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

une autre chose qui doit toujours être fait il définir le codage correct de la base de données:

$dbh = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass');

Voir Aussi cette question liée: Comment puis-je empêcher L'injection SQL en PHP?

notez Également que c'est seulement sur la base de données côté des choses que vous auriez encore à vous regarder lors de l'affichage des données. Par exemple: en utilisant htmlspecialchars() à nouveau avec le style d'encodage et de citation correct.

personnellement, je voudrais toujours exécuter une certaine forme d'assainissement sur les données d'abord comme vous ne pouvez jamais faire confiance à l'entrée de l'utilisateur, cependant en utilisant placeholders / parameter binding les données saisies sont envoyées au serveur séparément à la déclaration sql et puis binded ensemble. La clé ici est que cette lie les données fournies à un type spécifique et une utilisation spécifique et élimine toute possibilité de changer la logique de l'instruction SQL.

Eaven si vous voulez empêcher l'injection sql front-end, en utilisant des vérifications html ou js, vous devez considérer que les vérifications front-end sont "contournables".

vous pouvez désactiver js ou éditer un motif avec un outil de développement frontal (intégré avec firefox ou chrome de nos jours).

donc, afin d'empêcher L'injection SQL, serait le droit d'assainir entrée Date backend à l'intérieur de votre contrôleur.

je voudrais vous suggérer pour utiliser la fonction PHP native filter_input() afin d'assainir les valeurs GET et INPUT.

si vous voulez aller de l'avant avec la sécurité, pour les requêtes de base de données sensées, je voudrais vous suggérer d'utiliser l'expression régulière pour valider le format de données. preg_match() vous aideront dans ce cas! Mais prenez soin de vous! Moteur d'expressions régulières n'est pas si léger. Utilisez - le SEULEMENT si nécessaire, sinon vos performances d'application diminueront.

la sécurité a un coût, mais ne gaspillez pas votre la performance!

Exemple facile:

si vous voulez vérifier deux fois si une valeur, reçue de GET est un nombre, moins de 99 si(!preg_match('/[0-9]{1,2}/')){...} est heavyer de

if (isset($value) && intval($value)) <99) {...}

Donc, la réponse finale est: "Non! AOP Préparées ne pas empêcher tout type d'injection sql"; Elle n'empêche pas des valeurs inattendues, juste inattendu concaténation