2008-12-08 6 views
1

J'ai reçu quelques anciennes bases de données qui utilisent SQL Server 2000 et SQL injecté avec des balises de script javascript à la fin de certains champs de base de données. J'ai besoin d'un déclencheur pour retirer l'injection sur la mise à jour jusqu'à ce que j'ai le temps de réparer l'extrémité avant qui permet cela. Je suis un novice SQL Server - s'il vous plaît, aidez-moi!Comment créer un déclencheur pour remplacer les balises <script> SQL injectées dans SQL Server 2000?

+0

Y a-t-il un élément dans votre base de données où «script» pourrait légitimement faire partie du texte? –

Répondre

3

Je pense qu'une contrainte serait meilleure. Tout ce qui a compromis le contenu serait mieux rejeté.

Mettre en place une contrainte sur quelque chose sur le terrain comme

 
CHARINDEX('<script>',[fieldname]) = 0 
+0

Il est préférable, mais a l'inconvénient où le code qui avait l'habitude de toujours réussir maintenant pourrait jeter une exception. –

+0

oui, j'ai juste pensé à cela et je suis revenu pour commenter. Cela n'a pas vraiment d'importance cependant, toute personne qui met ce genre de contenu dans votre site n'a pas besoin de bons commentaires. ;-) –

+0

C'est simple et fonctionne parfaitement - merci! – Slee

0

quelque chose comme:

UPDATE table
champ SET = REPLACE (champ, '</script >', REPLACE (champ, '< scénario >', ''))
OÙ table.pk EN (SELECT pk FROM FROM inséré WHERE champ LIKE '% script >')

?

+0

Je ne pense pas que vous pouvez mettre à jour les tables virtuelles directement. Au lieu de cela, je pense que vous devez vous joindre aux tables réelles et les mettre à jour. –

+0

Bon - ça fait longtemps - j'ai presque oublié les déclencheurs. :) – dkretz

0

Existe-t-il des fonctionnalités de type regex dans SQL Server 2000? Le contenu des balises de script change constamment.

+0

SQl Server 2000 n'a pas de fonctionnalité regex autre que le type de remplacement indiqué dans les réponses. Pouvez-vous restaurer la base de données juste avant l'attaque? – HLGEM

0

Une attaque à grande échelle est en cours depuis le mois d'avril. Si c'est le cas, vous devrez ajouter un déclencheur pour chaque table de la base de données. Ce script modifie le code d'attaque d'origine pour nettoyer tout en un seul coup, en supposant <script n'est pas le texte valide partout dans le db:

DECLARE @T varchar(255),@C varchar(255) 
DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) 
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C 
WHILE(@@FETCH_STATUS=0) BEGIN 
exec('update ['[email protected]+'] set ['[email protected]+']=LEFT(['[email protected]+'], CHARINDEX(''<script'', ['[email protected]+'])-1) 
WHERE CHARINDEX(''<script'', ['[email protected]+']) >0') 
FETCH NEXT FROM Table_Cursor INTO @T,@C 
END 
CLOSE Table_Cursor 
DEALLOCATE Table_Cursor 

De plus, je vous ai entendu peut-être la chance arrêter cette attaque en supprimant SELECT autorisations pour l'utilisateur de l'application sur syscolumns ou sysobjects, si c'est une option pour vous. Vous devez toujours corriger vos vulnérabilités en prévision de la prochaine attaque.

0

une fois vos données est fixe, vous devrez trouver et corriger la façon dont les injections deviennent dans votre datbase. Je présume que vous utilisez probablement SQl dynamique. Cet article vous aidera à le réparer afin que les injections ne soient pas un problème http://www.sommarskog.se/dynamic_sql.html

Questions connexes