Как создать триггер для замены sql-инъецированных тегов <script> в SQL Server 2000?

У меня есть несколько старых баз данных, которые мне передали с использованием SQL Server 2000, и они получают SQL Injected с тегами JavaScript-скриптов в конце определенных полей базы данных. Мне нужен триггер, чтобы вырезать инъецированное на обновление, пока у меня не будет времени исправить передний конец, который позволяет это.Как создать триггер для замены sql-инъецированных тегов <script> в SQL Server 2000?

Я новичок в SQL Server - пожалуйста, помогите!

источник

2008-12-08 Slee

Есть ли где-нибудь в вашей базе данных, где ' 2008-12-08 20:07:31

Я думаю, что ограничение было бы лучше. Все, что скомпрометировало контент, было бы лучше отклонено.

Настройка ограничения на поле что-то вроде

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

источник

2008-12-08 20:15:52

что-то вроде:

UPDATE поле таблицы
SET = ЗАМЕНИТЬ (поле '</скрипт >', REPLACE (поле '< сценарий >', ''))
ГДЕ table.pk В (SELECT pk FROM вставлено WHERE поле LIKE '% script >')

источник

2008-12-08 20:08:08 dkretz

Я не думаю, что вы можете напрямую обновлять виртуальные таблицы. Вместо этого, я думаю, вам нужно присоединиться к фактическим таблицам и обновить их. – 2008-12-08 20:08:56

Справа - это было какое-то время - я довольно сильно пропустил триггеры. :) – dkretz 2008-12-08 20:15:05

Есть ли какие-либо регулярные выражения, подобные функциям SQL Server 2000? Содержимое тегов скрипта постоянно изменяется.

источник

2008-12-08 20:10:54 Slee

SQl Server 2000 не имеет функций регулярных выражений, отличных от вида замены, показанного в ответах. Можете ли вы восстановить db непосредственно перед атакой? – HLGEM 2008-12-08 20:22:15

Существует масштабная атака, которая продолжается с апреля прошлого года, и если это то, что вам нужно, вам придется добавить триггер для каждой таблицы в базе данных. Этот сценарий изменяет исходный код атаки, чтобы очистить все одним махом, предполагая, что <script не является действительным текст в любом месте в БД:

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

Кроме того, я слышал, что вы, возможно, повезет остановить эту атаку путем удаления SELECT разрешения для пользователя приложения на syscolumns или sysobjects, если это вариант для вас. Вы все равно должны исправлять свои уязвимости в процессе подготовки к следующей атаке.

источник

2008-12-08 20:13:58

раз ваших данных фиксированы вам нужно будет найти и исправить путь инъекция получает в вашу datbase. Я полагаю, вы, вероятно, используете динамический SQl. Эта статья поможет вам исправить это, так что инъекции не будут проблемой http://www.sommarskog.se/dynamic_sql.html

источник

2008-12-08 22:39:08 HLGEM

Как создать триггер для замены sql-инъецированных тегов <script> в SQL Server 2000?

ответ

Смежные вопросы