| 導購 | 订阅 | 在线投稿
分享
 
 
 

SQL注入防禦:用三種策略應對SQL注入攻擊

來源:互聯網網民  2008-06-13 06:49:16  評論

這篇論壇文章(賽迪網技術社區)著重介紹了有關SQL注入防禦的防禦策略及實施步驟,詳細內容請參考下文:

從去年下半年開始,很多網站被損害,他們在用于生成動態網頁的SQL數據庫中存儲的文本中被注入了惡意的script標簽。這樣的攻擊在2008年第一季度開始加速傳播,並且持續影響有漏洞的Web程序。

這些Web應用程序有這樣一些共同點:

* 使用經典ASP代碼的程序

* 使用SQL Server數據庫的程序

應用程序代碼根據URI請求字符動態地生成SQL查詢(http://consoto.com/widgets.asp?widget=sprocket)這體現了一種新的SQL注入(SQL injection)的途徑(http://msdn.microsoft.com/en-us/library/ms161953.aspx)。在過去,SQL注入攻擊的目標是具有如下特點的特殊Web應用程序:攻擊者知道或者可以探測出後台數據庫的漏洞或者結構。這樣的攻擊(指本文討論的攻擊- 譯者注)不同,因爲它是抽象的,對于攻擊來說,任何存在于使用URI請求字符串動態創建SQL查詢的ASP頁面都可能存在。你可以在 http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到更多的技術詳情和簡單代碼。

這樣的攻擊並非利用了Window、IIS、SQL Server或者其他底層代碼的漏洞,而是利用了在這些平台上運行的由程序員自行編寫的代碼中的漏洞。Microsoft已經對這些攻擊進行了徹底的調查,並且發現,他們和以往的Microsoft産品的補丁和0-day漏洞無關。你可以在http://blogs.technet.com/msrc/archive/2008/04/25/questions-about-web-server-attacks.aspx獲取跟多的信息。

正如上面所指出的,這些攻擊在近年來呈現一種增長的趨勢。這至少與兩個因素有關:

第一,有暴力性的惡意攻擊工具自動化進行此類操作。SANS在http://isc.sans.org/diary.html?storyid=4294討論了這類工具。該工具使用搜索引擎來尋找具有SQL注入漏洞的站點。

第二,一個或多個惡意僵屍正在進行SQL注入攻擊,用以廣泛傳播僵屍。SecureWorks在http://www.secureworks.com/research/threats/danmecasprox/討論了一個案例。

一旦某台服務器被該漏洞所攻擊,它將被插入指向某.js文件的惡意script標簽。雖然這些文件的內容不同,但是他們都嘗試利用已經被修複的Micfosoft産品的漏洞或者第三方ActiveX控件的漏洞。由于這些腳本被單獨存儲,這些腳本就很容易的被更新以利用更新的客戶端漏洞,也更容易按照不同浏覽器來定制。

給信息技術/數據庫管理員的建議

有很多事情是信息技術管理員或者數據庫管理員可以采取的,以減少他們的風險和響應他們的代碼和平台中可能出現的事件:

* 檢查IIS日志和數據表來尋找未知風險的標志。

由于該漏洞利用方式通過URI請求字符串作用,管理員們可以檢查IIS日志來查找嘗試利用該漏洞的非正常請求。你可以在http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到如何手動進行改操作的詳細信息。在 http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436有進行自動化操作的工具。

如果IIS日志表明服務器可能已經被侵害,那麽下一步要采取的行動就是審計相應的Web應用程序所使用的數據庫中的表,並且查找附加在文本內容中的script標簽。

提示:IIS服務器不應當在生産環境中關閉日志。存儲和適當的管理對于IIS日志都是重要的,缺少IIS日志對于響應安全事件是非常困難的。

* 如果運行了使用後端數據庫的第三方代碼,則考慮不受SQL注入影響的獨立軟件開發商(ISV,Independent Software Vendors)。

在使用第三方ASP Web程序的情況下,管理員應當聯系應用程序廠商來確定他們的産品不受SQL注入攻擊的影響。

* 確認Web應用程序所使用的數據庫帳戶具有最少的權限。

管理員應當確保Web應用程序所使用的SQL用戶具有最小的必要權限。Web應用程序不應當以諸如」sysadmin」的服務器管理員權限或者」db_owner」的數據庫權限鏈接。白皮書」在SQL Server 2005中的最優化安全設置和維護」: http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc 提供了關于SQL Server安全的多方面建議。

給Web開發者的建議

有很多優秀的文檔論述在編碼時如何防禦SQL注入攻擊。由于這些攻擊者leverage有漏洞的Web應用程序代碼,所以完全防禦他們的唯一方法是解析在代碼中存在的漏洞。程序中任何一個使用外部資源(一般指從URI請求字符串)數據來動態生成SQL請求的地方都應當被認爲是可疑的。當代碼漏洞被識別出來,他們應當被小心的修複。

* 說明-SQL注入、ASP.NET和ADO.NET :

http://msdn.microsoft.com/en-us/library/bb671351.aspx

同時,上面的文章包含到相關文章」如何在ASP.NET中避免SQL注入」 http://msdn.microsoft.com/en-us/library/ms998271.aspx,該文章同時適用于ASP。

這裏有一個非常有用的視頻(該視頻是針對一篇防禦文章的,然而鏈接可能已經無效了):http://channel9.msdn.com/wiki/default.aspx/SecurityWiki.SQLInjectionLab。

* 關于SQL注入如何實現的簡單信息:

http://msdn.microsoft.com/en-us/library/ms161953.aspx

* ASP代碼中的SQL注入(與ASP.NET中的並不相同):

http://msdn.microsoft.com/en-us/library/cc676512.aspx

如何在ASP中執行SQL Server存儲過程: http://support.microsoft.com/kb/q164485

* Microsoft安全部門(The Microsoft Security Development Lifecycle,SDL)對SQL注入的防禦進行了一些指導。簡單來說有三種策略來應對SQL注入攻擊:

1. 使用SQL參數查詢

2. 使用存儲過程

3. 使用SQL僅執行(execute-only)許可

Michael Howard在http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx談論了這些內容。

同時,編寫安全的代碼(第二版)也指導了如何防禦此類攻擊。

* 減輕SQL注入:使用參數查詢(第一部分和第二部分)。使用參數化查詢的好處是它將執行的代碼(例如SELECT語句)和數據(由程序使用者提供的動態信息)分開。該途徑防禦了通過用戶傳遞來執行的惡意語句。

第一部分:

http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx

第二部分:

http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx

在經典ASP代碼中過濾SQL注入(或者黑名單中的字符),我們將如下的工作認爲是實際中臨時性的解決方案,因爲它治標不治本。(例如,代碼仍然是有漏洞的,他仍然可能被繞過過濾機制而被訪問到)

IIS團隊中的Nazim解釋了如何過濾的詳細信息:http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx。

如果你仍然不了解從哪裏開始,所有使用特定ASP代碼訪問數據庫,尤其是使用由用戶提供的數據的代碼應當首先被檢測。

 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
這篇論壇文章(賽迪網技術社區)著重介紹了有關SQL注入防禦的防禦策略及實施步驟,詳細內容請參考下文: 從去年下半年開始,很多網站被損害,他們在用于生成動態網頁的SQL數據庫中存儲的文本中被注入了惡意的script標簽。這樣的攻擊在2008年第一季度開始加速傳播,並且持續影響有漏洞的Web程序。 這些Web應用程序有這樣一些共同點: * 使用經典ASP代碼的程序 * 使用SQL Server數據庫的程序 應用程序代碼根據URI請求字符動態地生成SQL查詢(http://consoto.com/widgets.asp?widget=sprocket)這體現了一種新的SQL注入(SQL injection)的途徑(http://msdn.microsoft.com/en-us/library/ms161953.aspx)。在過去,SQL注入攻擊的目標是具有如下特點的特殊Web應用程序:攻擊者知道或者可以探測出後台數據庫的漏洞或者結構。這樣的攻擊(指本文討論的攻擊- 譯者注)不同,因爲它是抽象的,對于攻擊來說,任何存在于使用URI請求字符串動態創建SQL查詢的ASP頁面都可能存在。你可以在 http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到更多的技術詳情和簡單代碼。 這樣的攻擊並非利用了Window、IIS、SQL Server或者其他底層代碼的漏洞,而是利用了在這些平台上運行的由程序員自行編寫的代碼中的漏洞。Microsoft已經對這些攻擊進行了徹底的調查,並且發現,他們和以往的Microsoft産品的補丁和0-day漏洞無關。你可以在http://blogs.technet.com/msrc/archive/2008/04/25/questions-about-web-server-attacks.aspx獲取跟多的信息。 正如上面所指出的,這些攻擊在近年來呈現一種增長的趨勢。這至少與兩個因素有關: 第一,有暴力性的惡意攻擊工具自動化進行此類操作。SANS在http://isc.sans.org/diary.html?storyid=4294討論了這類工具。該工具使用搜索引擎來尋找具有SQL注入漏洞的站點。 第二,一個或多個惡意僵屍正在進行SQL注入攻擊,用以廣泛傳播僵屍。SecureWorks在http://www.secureworks.com/research/threats/danmecasprox/討論了一個案例。 一旦某台服務器被該漏洞所攻擊,它將被插入指向某.js文件的惡意script標簽。雖然這些文件的內容不同,但是他們都嘗試利用已經被修複的Micfosoft産品的漏洞或者第三方ActiveX控件的漏洞。由于這些腳本被單獨存儲,這些腳本就很容易的被更新以利用更新的客戶端漏洞,也更容易按照不同浏覽器來定制。 給信息技術/數據庫管理員的建議 有很多事情是信息技術管理員或者數據庫管理員可以采取的,以減少他們的風險和響應他們的代碼和平台中可能出現的事件: * 檢查IIS日志和數據表來尋找未知風險的標志。 由于該漏洞利用方式通過URI請求字符串作用,管理員們可以檢查IIS日志來查找嘗試利用該漏洞的非正常請求。你可以在http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到如何手動進行改操作的詳細信息。在 http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436有進行自動化操作的工具。 如果IIS日志表明服務器可能已經被侵害,那麽下一步要采取的行動就是審計相應的Web應用程序所使用的數據庫中的表,並且查找附加在文本內容中的script標簽。 提示:IIS服務器不應當在生産環境中關閉日志。存儲和適當的管理對于IIS日志都是重要的,缺少IIS日志對于響應安全事件是非常困難的。 * 如果運行了使用後端數據庫的第三方代碼,則考慮不受SQL注入影響的獨立軟件開發商(ISV,Independent Software Vendors)。 在使用第三方ASP Web程序的情況下,管理員應當聯系應用程序廠商來確定他們的産品不受SQL注入攻擊的影響。 * 確認Web應用程序所使用的數據庫帳戶具有最少的權限。 管理員應當確保Web應用程序所使用的SQL用戶具有最小的必要權限。Web應用程序不應當以諸如」sysadmin」的服務器管理員權限或者」db_owner」的數據庫權限鏈接。白皮書」在SQL Server 2005中的最優化安全設置和維護」: http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc 提供了關于SQL Server安全的多方面建議。 給Web開發者的建議 有很多優秀的文檔論述在編碼時如何防禦SQL注入攻擊。由于這些攻擊者leverage有漏洞的Web應用程序代碼,所以完全防禦他們的唯一方法是解析在代碼中存在的漏洞。程序中任何一個使用外部資源(一般指從URI請求字符串)數據來動態生成SQL請求的地方都應當被認爲是可疑的。當代碼漏洞被識別出來,他們應當被小心的修複。 * 說明-SQL注入、ASP.NET和ADO.NET : http://msdn.microsoft.com/en-us/library/bb671351.aspx 同時,上面的文章包含到相關文章」如何在ASP.NET中避免SQL注入」 http://msdn.microsoft.com/en-us/library/ms998271.aspx,該文章同時適用于ASP。 這裏有一個非常有用的視頻(該視頻是針對一篇防禦文章的,然而鏈接可能已經無效了):http://channel9.msdn.com/wiki/default.aspx/SecurityWiki.SQLInjectionLab。 * 關于SQL注入如何實現的簡單信息: http://msdn.microsoft.com/en-us/library/ms161953.aspx * ASP代碼中的SQL注入(與ASP.NET中的並不相同): http://msdn.microsoft.com/en-us/library/cc676512.aspx 如何在ASP中執行SQL Server存儲過程: http://support.microsoft.com/kb/q164485 * Microsoft安全部門(The Microsoft Security Development Lifecycle,SDL)對SQL注入的防禦進行了一些指導。簡單來說有三種策略來應對SQL注入攻擊: 1. 使用SQL參數查詢 2. 使用存儲過程 3. 使用SQL僅執行(execute-only)許可 Michael Howard在http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx談論了這些內容。 同時,編寫安全的代碼(第二版)也指導了如何防禦此類攻擊。 * 減輕SQL注入:使用參數查詢(第一部分和第二部分)。使用參數化查詢的好處是它將執行的代碼(例如SELECT語句)和數據(由程序使用者提供的動態信息)分開。該途徑防禦了通過用戶傳遞來執行的惡意語句。 第一部分: http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx 第二部分: http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx 在經典ASP代碼中過濾SQL注入(或者黑名單中的字符),我們將如下的工作認爲是實際中臨時性的解決方案,因爲它治標不治本。(例如,代碼仍然是有漏洞的,他仍然可能被繞過過濾機制而被訪問到) IIS團隊中的Nazim解釋了如何過濾的詳細信息:http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx。 如果你仍然不了解從哪裏開始,所有使用特定ASP代碼訪問數據庫,尤其是使用由用戶提供的數據的代碼應當首先被檢測。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 
 熱帖排行
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有