Je poste ce nsujet parce que je viens de me rendre compte de grosses grosses failles sur un site dont je tairais le nom
 
L'injection SQL c'est quoi ?
Eh bien c'est un moyen de balancer du code malveillant en lieu et place de données envoyées par un formulaire le plus souvent
 
je vous conseille ces articles :
 
http://www.manuelphp.com/security. [...] ection.php
http://0ryck.free.fr/g%E9n%E9ral/h [...] ection.htm
http://www.ossir.org/resist/cr/200 [...] age-9.html
 
Je vous propose donc de mettre ici les dangers inhérents à l'injection SQL et de répertorier vos parades les plus courantes, les erreurs de modélisation à éviter etc..
 
J'aimerais aussi beaucoup avoir une vue d'ensemble des systèmes serveur / langage les plus vulnérables (les 3/4 de mes tentatives fructueuses étaient sur IIS / ASP)
 
Ce topic est pour toi public

Il parait qu'il y a un forumeur qui a réussi à hacker un certain forum qui tournait sur Apache/PHP

j'ai pas suivi l'affaire, mais était-ce bien un bug d'injection ?

Non, ce forum est sécurisé
 
Blague à part, il n'a pas encore dévoilé la faille (joce a pas encore backporté les modifs sur tous ses forums), mais il a du jouer sur les mots de passe à mon avis, vu que le formulaire de réponse masque maintenant le champ en question

Bon, ben les dangers, que quelqu'un s'amuse à détruire nos jolies tables   .
 
La parade : Tester les valeurs lors des requêtes. Des petites fonctions comme isint() peuvent toujours servir ou encore ne pas oublier à échapper les quotes.

Dans l'autre topic, j'ai expliqué comment blinder la chose en ASP en utilisant bêtement une fonction "quote" :
 
function quote(str)
   if isEmpty(str) then
      quote = "''"
   else
      quote = "'" & replace(str, "'", "''" ) & "'"
   end if
end function
 
Il suffit d'appeler cette requête pour tous les paramètre string des requêtes. Et pour les chiffres, il suffit de faire bêtement un cint(val) histoire de forcer le plantage si c'est pas un nombre. A partir de là, impossible de faire quoi que ce soit.
 
Sinon, il y a toujours la possibilité de passer avec des requêtes paramètrées avec ADO. A ce moment, là c'est clairement et à 100% impossible à contourner, quelquesoit les bidouilles qu'on tentera, y compris au niveau programmation. En plus, c'est beaucoup plus rapide... Par contre, c'est beaucoup plus chiant à écrire.
 
PS: ces informations sont généralement dès la deuxième page du chapitre "accès au données" de n'importe quel bouquin sur l'ASP, et c'est dans l'aide de M$. Après, y'a des guignols qui sont pas foutus de lire un tutorial avant de recopier du code généré par dreamweaver, faut pas s'étonner si ça merde...
PS: hé oui, DW ne fait pas ces contrôles, donc tout ce qui est généré par cette merde sera hackable.

ce qui me semble dingue, c'est de tomber sur des softs vendus dans les 12 000 ?, et qui sont vulnérables à tout ou presque
 
dans ce cas précis, l'administrateur est le premier utilisateur enregistré, et un simple injection OR 1=1 permet de se connecter en admin, de récupérer le mot de passe et de tout fusiller
 
tous les champs textes des formulaires sont attaquables (et même les subqueries fonctionnent en injection)