le degré de sécurité sont préparées de PDO

Commencé à utiliser PDO préparées il y a pas longtemps, et, comme je le comprends, il fait tout le échappant/sécurité pour vous.

par exemple, en supposant que $_POST['titre'] est un champ de formulaire.

$title = $_POST['title'];
$query = "insert into blog(userID, title) values (?, ?)"
$st = $sql->prepare($query);
$st->bindParam(1, $_SESSION['user']['userID'], PDO::PARAM_INT);
$st->bindParam(2, $title);
$st->execute();

Est-ce vraiment sûr? Dois-je faire autre chose? quoi d'autre dois-je prendre en considération?

Grâce.

InformationsquelleAutor sqram | 2009-08-21
  1. 77

    Strictement parlant, il n'existe pas de s'échapper nécessaire, parce que la valeur du paramètre n'est jamais interpolées dans la chaîne de requête.

    La façon dont les paramètres de la requête travail est que la requête est envoyée au serveur de base de données lorsque vous avez appelé prepare(), et les valeurs des paramètres sont envoyés plus tard, quand vous avez appelé execute(). Si elles sont séparées de la forme textuelle de la requête. Il n'y a jamais une occasion pour l'injection SQL (à condition PDO::ATTR_EMULATE_PREPARES est faux).

    Donc oui, les paramètres de requête vous aider à éviter cette forme de vulnérabilité de la sécurité.

    Sont-ils 100% imperméable à toute faille de sécurité? Non, bien sûr que non. Comme vous le savez peut-être, un paramètre de requête ne prend la place d'une seule valeur littérale d'une expression SQL. Vous ne pouvez pas faire un seul paramètre de substitution pour une liste de valeurs, par exemple:

    SELECT * FROM blog WHERE userid IN ( ? );

    Vous ne pouvez pas utiliser un paramètre pour que les noms de table ou de colonne des noms dynamiques:

    SELECT * FROM blog ORDER BY ?;

    Vous ne pouvez pas utiliser un paramètre pour tout autre type de syntaxe SQL:

    SELECT EXTRACT( ? FROM datetime_column) AS variable_datetime_element FROM blog;

    Il y a donc assez peu de cas où vous avez à manipuler la requête comme une chaîne de caractères, avant la prepare() appel. Dans ces cas, vous avez encore le besoin d'écrire du code avec soin pour éviter les injection SQL.

    • c'était de très bons renseignements. merci!!!!
    • Aussi LIKE ? est valide, mais vous devez échapper les caractères utilisés pour la correspondance.
    • Quant à "Il n'y a jamais une occasion pour l'injection SQL (à condition PDO::ATTR_EMULATE_PREPARES est faux).", est-ce à dire AOP émulé prépare sont PAS aussi sûr que les indigènes se prépare du pilote de base de données? Si oui, pourquoi?
    • Un bon exemple de l'injection avec PDO prépare (en raison des limitations mentionnées dans cette réponse), c'est la récente drupal une vulnérabilité sektioneins.de/advisories/...
    • merci pour l'exemple réel! Mise à niveau de votre Drupal, tout le monde!
    InformationsquelleAutor Bill Karwin
  2. 10

    C'est la sécurité de l'injection SQL.

    Un couple de choses qu'il n'est PAS sûr à partir de:

    • Déni de service (provoquant des quantités excessives de lignes à créer)
    • Cross-site scripting attaques (si le titre est toujours en écho à un autre utilisateur)

    La sécurité est plus que juste la prévention de l'injection SQL.

    • merci de contribuer. que voulez-vous dire si le titre est en écho à un autre utilisateur?
    • Supposons que vous avez le titre de billets de blog étant stockées dans une base de données, et d'autres utilisateurs peuvent afficher ces messages. Il existe un risque potentiel de cross-site scripting attaque à un utilisateur malveillant peut fabriquer un titre qui inclut le code HTML à intégrer un script malveillant dans la page, comme c'est montré à d'autres utilisateurs de votre site.
    InformationsquelleAutor Yuliy
  3. 2

    Concernant les Injections SQL, je crois que c'est le plus sûr que vous pouvez obtenir, spécialement si vous utilisez des constantes comme PDO::PARAM_INT.

    • Cette 'spécialement' a besoin de quelques précisions de l'OMI. Vous ne voulez probablement pas à dire que c'est à 95% sûr, mais si vous utilisez les constantes c'est sûr à 100%. Si sans des constantes c'est pas sûr à 100% qu'il n'est pas sûr. Si il est à 100% alors il n'est pas "en particulier" sans danger avec des constantes. Quelle est la sécurité de la différence entre l'utilisation de constantes et de ne pas les utiliser?
    InformationsquelleAutor Alix Axel
  4. 1

    De voir que XSS a été mentionné, je pense qu'il est aussi bon de prendre un coup d'oeil à l'aide des choses telles que la saisie de nettoyage de la classe http://www.phpclasses.org/browse/package/2189.html pour empêcher les attaques XSS.

    InformationsquelleAutor Rob