Problème d’injection sql 2005

Problème d’injection
Bonjour,
Voila j’ai un gros souci avec sql serveur 2005 et un site web
J’avais mon site internet relié a une base de donnée sql 2000 qui avait été attaquer via une injection sql , de type je me retrouvais avec dans toutes les tables ce type de donnée :
« <scritp src=http://www.cg33.ru/script.js><script> »
Voila donc j’ai revu totalement mon code « colmater mes erreur de développement » et installer url scan j’ai ensuite sous les conseils d’une personne http://forums.iis.net/t/1148917.aspx
Lancer un script sur mon sql serveur 2000 voila le code :

use [Your_Database_name]
GO
DENY SELECT ON [sys].[columns] TO [Your_User]
DENY SELECT ON [sys].[tables] TO [Your_User]
DENY SELECT ON [sys].[syscolumns] TO [Your_User]
DENY SELECT ON [sys].[sysobjects] TO [Your_User]
DENY SELECT ON [sys].[objects] TO [Your_User]
DENY SELECT ON [sys].[syscomments] TO [Your_User]
GO

Avec tout sa plus d’attaque .
Je passe sous sql 2005 je repasse le script pour le deny select on le site ne bouge pas
Et voila que les attaques reviennent !!!!
je suis obliger de rester sur sql 2000
Merci de m’aider je ne sais plus quoi faire.

Les attaques par injection de SQL ne sont pas liés à une versions et sont connues de tous les SGBDR. Il s'agit de protéger votre serveur de SQL dynamique.

A +

oui j'ai revu le codages de mes requetes
mais franchement je trouve bizare que des que je transferre mes base sur sql 2005 elle soit corronpue dnas la journée !!!
alors que si je les laisse sur mon serveur 2000 rien nada elle reste nikel.

meme un truc bizare c'est toutes les tables de ma base qui se font corrompre
meme des tables que je n'utilise que dans le back office et totalement invisible du front office.

j'insiste mais sur sql 2008 les tables qu'il faut interdire au select c'est bien
DENY SELECT ON [sys].[columns] TO [Your_User]
DENY SELECT ON [sys].[tables] TO [Your_User]
DENY SELECT ON [sys].[syscolumns] TO [Your_User]
DENY SELECT ON [sys].[sysobjects] TO [Your_User]
DENY SELECT ON [sys].[objects] TO [Your_User]
DENY SELECT ON [sys].[syscomments] TO [Your_User]

ou il y en a d'autre avec cette requete sur mon serveur 2000 sa suffisait

merci
(j'ai lancer un sql profiler pour voir ce qui ce passe sa peux servir non ?)

Vous ne pouvez en aucune manière interdire la lecture des "données" système. En effet si vous interdisiez cela aucune requête ne serait plus possible car à chaque requête sur une table de production (par exemple client) il faut aller lire dans les tables système les id équivalent pour établir les plan de requête.
Vous faites totalement fausse route quand à la manière de protéger votre serveur des attaques par injection de SQL.

Vous verrez par exemple que les vues d'INFORMATION_SCHEMA sont par nature publiques (norme SQL en lieu et place de sys.bidule).

La protection contre l'injection de SQL est assez simple si la base a été conçue dans le respect des règles de l'art, car en principe, vous ne devriez quasiment jamais avoir à faire à du SQL dynamique.

En particulier, testez tous les objets composants votre assemblage de chaîne SQL avant exécution et donnez leur un type adéquat.

De plus, la plupart du temps je constate que l'on recoure au SQL dynamique alors que l'on n'en à pas besoin !

Enfin, le fait que vous ayez plus ceci sur 2005 que sur 2000 est simple : les objets systèmes ont changés entre 2000 et 2005. Si fait que les scripts 2005 attaquant des vues systèmes (sys.columns par exemple) ne peuvent être appelés sur 2000 car ces vues n'existent pas dans cette version.


A +

Je suis d'accord avec SqlPro. Le travail doit se faire au niveau du développement pas dans la base.
En .net par exemple, il suffit d'utiliser une requete paramétrée ou une procédure stockée pour se prémunir du problème. Pour les autres langages, il doit y avoir des controles faciles à mettre en place je pense.

j ai trouvé !!!!!!!!!
enffet mon code etias bon par contre c etais bien mes droit sur l'utilisateur web qui etais foireux j 'ai pas regarder les connection que me met mon logiciel de sauvegarde j'a

j ai trouvé !!!!!!!!!
enffet mon code etias bon par contre c etais bien mes droit sur l'utilisateur web qui etais foireux j 'ai pas regarder les connection que me met mon logiciel de sauvegarde j'ai juste refait ma connection / user et remis les droit et hop sa fonctionne depuis 2 semaine sans attaque (avant tout les soir la base etais foireuse)
merci pour vos tuyaux !!!!