Discussion:Injection SQL
- Admissibilité
- Neutralité
- Droit d'auteur
- Article de qualité
- Bon article
- Lumière sur
- À faire
- Archives
- Commons
Cet article est indexé par le projet Sécurité informatique.
Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.
| Avancement | Importance | pour le projet | |
|---|---|---|---|
| Ébauche | Moyenne |  | Sécurité informatique (discussion • critères • liste • stats • hist. • comité • stats vues) |
Cet article ne comporte pas de liste de tâches suggérées. Vous pouvez saisir une liste de tâches à accomplir (par exemple sous forme d'une liste à puces), puis sauvegarder. Vous pouvez aussi consulter la page d'aide.
phrase à reformuler
Bonjour
la phrase « Certaines failles de sécurité, comme le fait de ne pas s’appliquer sur les champs hidden des formulaires... » est incompréhensible. Qu'est ce qui ne s'applique pas aux champs hidden, SVP ? --90.50.71.112 (d) 15 décembre 2009 à 22:48 (CET)Doume
suppression de lien
Je supprime le lien
qui n'a aucun contenu (page vide).
Protection par procédure stockée
J'annule la suppression de la solution des procédures stockées, elle est bien valide car elle évite que le code SQL soit nécessairement dynamique. Askywhale (discuter) 29 août 2013 à 12:12 (CEST)
171.16.208.3 (discuter) 29 août 2013 à 16:23 (CEST) :
La phrase est "Utiliser des procédures stockées, à la place du SQL dynamique. Les données entrées par l'utilisateur sont alors transmises comme paramètres, sans risque d'injection"
Cette phrase est fausse : le fait de passer par une SP ne prévaut pas d’empêcher une injection SQL. Il est tout à fait possible d'avoir du code dynamique dans une SP (et c'est souvent le cas) et donc de s'exposer au injection SQL de ce type de code.
- La phrase est finie par "à la place du SQL dynamique". Si vous ne gardez pas de SQL dynamique (c'est à dire dont la construction, avant compilation, diffère à l'utilisation), ces injections disparaissent. Les exemples mentionnés soient continuent à faire des requêtes dynamiques, soir concernent PL et non SQL. Toutefois l'absence de différence me fait modérer la phrase maintenant. Askywhale (discuter) 29 août 2013 à 17:21 (CEST)
Les 2 liens Web mis en commentaire sont assez explicites. Je les remets ici pour la discussion : http://www.nes.fr/securitylab/?p=98 et http://conseilit.wordpress.com/2010/07/30/sql-injection-%E2%80%A6/
De plus, la notion de "SQL dynamique" n'est pas définie et elle apparait seulement dans cette phrase sans aucune explication. Le lecteur ne sait pas ce qu'il faut remplacer.
- Il manque une explication à SQL dynamique
Autre point, la notion de "risque" est très complexe dans le domaine de la sécurité informatique. L'utilisation de ce terme n'est pas forcément approprié.
Dernière remarque qui n'est pas liée au SP : le point 5 de "Comment éviter les attaques" fait référence au SGBDR MySQL. L'injection SQL n'est pas réservée à cette base de données. Cet exemple devrait être traité à part.
- Cette article est assez mal ordonné et devrait être repris. Askywhale (discuter) 29 août 2013 à 17:21 (CEST)
Problème sur les exemples.
Les derniers exemples ne concernent pas des injections SQL, doivent-ils réellement figurés sur cette page ?