ASP.NET木馬安全解決方案

申請免費試用、咨詢電話：400-8352-114

　　大家都知道網上出現(xiàn)過諸如《asp.net虛擬主機的重大隱患》等類似介紹Asp.Net的漏洞以及相應的黑客攻擊辦法的文章，以及諸如Webadmin.aspx類Asp.Net的Webshell,如果您拿去到您的asp.net虛擬主機上測試時您就知道，這東東對C盤有讀取權限，以及對整個硬盤都有 修改、刪除權限;那這樣的話，我們的網站、我的服務器還有什么安全可言?在黑客頻頻攻擊的今天，我們不能不為我們的服務器而擔憂...

　　漏洞原因:大家知道ASP中常用的標準組件:FileSystemObject，這個組件為ASP提供了強大的文件系統(tǒng)訪問能力，可以對服務器硬盤上的任何有權限的目錄 和文件進行讀寫、刪除、改名等操作。FSO對象來自微軟提供的腳本運行庫scrrun.dll中。而在Asp.Net中這個問題仍然存在，并且更加難以解決;因為.Net中對系統(tǒng)IO操作功能更加強大,如：組件不再需要用Regsvr32來注冊，而是直接在bin目錄下就可以直接用了，所以這些功能對開發(fā)Asp.Net程序有很大方便是，但卻使安全變得更為復雜了....

　　解決方案：

　　大家都知道，Asp類木馬可以通過對IIS中的虛擬主機采用獨立匿名用戶來控制FSO組件的安全，讓其只能在站類活動，而不能跨站或者危害到其它硬盤的數據(注：如果您不明白可以參考一下本人以前的兩篇文章《FSO安全隱患解決辦法》; 《ASP木馬Webshell之安全防范解決辦法》) Asp的安全問題與設置這里不再作討論，下面我們開始著手Asp.Net木馬/WebShell防范方法的講解：

　　在IIS6.0中，WEB應用程序的工作進程為以進程標識“Network Service”運行。而在IIS5.0中，進程外WEB應用程序則是以“IWAM_服務器名”用戶運行行，這個User是普通的本地Guests用戶。網上有部份人提出針對此問題用Microsoft .NET Framework Configration設置System.io的對目錄讀取的權限，但很遺憾經過我們測試沒有成功，可能是.net framework1.1機制改了?

　　Network Service 是Windows Server 2003中的內置帳戶。了解IIS5.0上的本地用戶帳戶(IUSR和IWAM)與這個內置帳戶之間的區(qū)別是非常重要的。Windows操作系統(tǒng)中的所有帳戶都分配了一個SID(安全標識:Security ID)。服務器是根據 SID，而不是與SID相關的名稱來識別服務器上所有帳戶的，而我們在與用戶界面進行交互時，則是使用名稱進行交互的。服務器上創(chuàng)建的絕大部分帳戶都是本地帳戶，都具有一個唯一的 SID，用于標識此帳戶隸屬于該服務器用戶數據庫的成員。由于SID只是相對于服務器是唯一的，因此它在任何其他系統(tǒng)上無效。所以，如果您為本地帳戶分配了針對某文件或文件夾的 NTFS 權限，然后將該文件及其權限復制到另一臺計算機上時，目標計算機上并沒有針對這個遷移SID的用戶帳戶，即使其上有一個同名帳戶也是如此。這使得包含NTFS權限的內容復制可能出現(xiàn)問題。內置帳戶是由操作系統(tǒng)創(chuàng)建的、一類較為特別的帳戶 或組，例如System帳戶、Network Service和Everyone 組。這些對象的重要特征之一就是，它們在所有系統(tǒng)上都擁有一個相同的、眾所周知的SID。當將分配了NTFS權限的文件復制到內置帳戶時，權限在服務器之間是有效的，因為內置帳戶的SID在所有服務器上都是相同的。Windows Server 2003 服務中的 Network Service 帳戶是特別設計的，專用于為應用程序提供訪問網絡的足夠權限，而且在IIS 6.0中，無需提升權限即可運行Web 應用程序。這對于IIS安全性來說，是一個特大的消息，因為不存在緩沖溢出，懷有惡意的應用程序無法破譯進程標識，或是對應用程序的攻擊不能進入System用戶環(huán)境。更為重要的一點是，再也不能形成針對System帳戶的“后門”，例如，再也無法通InProcessIsapiApps元數據庫項利用加載到Inetinfo的應用程序。我們已經簡單的介紹了一下ASP.NET中關于文件IO系統(tǒng)的漏洞的防治方法，這一方法有些繁瑣，但是卻可以從根本上杜絕一些漏洞，我們討論的只是很少的一部分，更多的解決放法需要大家共同來探索、學習。