大中型企業(yè)有相當大部分都在使用Windows Server以及.Net架構來構建企業(yè)Web服務和應用，因此Web服務和Web應用程序通常被ASP.NET和IIS主管。保護Web服務和Web應 用程序是一個配置環(huán)境的問題而不是編程問題。例如，使用SSL/TLS通過加密來確保保密性是最好的實現方式。為你的應用程序激活它，簡單的方式是對 IIS進行恰當的配置，然后使用前綴為https的URL進行訪問。
ASP.NET安全性的配置主要涉及到編輯一個分級的XML文檔集合。在這棵樹的頂部是machine.config，其中運行在這臺機器上的用于所有 ASP.NET應用程序的全局設置被制定好。在全局配置文件的下面是web.config文件，它包含了每個單獨的ASP.NET應用程序的設置。本文將 討論如何在這些文件中配置CAS、身份認證、假冒以及授權等方面，來保證Web服務安全運行。
1、為ASP.NET配置CAS
盡管CAS主要作為保護系統(tǒng)客戶端免受惡意移動代碼侵擾的一種方式，但它與Web服務和Web應用程序在服務器端的部署仍有一些關聯。例如，一臺服務器可 能主管不止一個的個體，團體和組織授權的ASP.NET應用程序;在這種情況下，CAS有助于減少由一個實體擁有的應用程序被另外一個實體擁有的應用程序 干擾的風險，也有助于被服務器操作系統(tǒng)干擾的風險。
但是，你應該注意到：在默認情況下，CAS策略授予ASP.NET應用程序一套完整的程序集。因為他們從本地機器上運行。很顯然，當配置你的應用程序時， 你應該修正這一點。.NET框架定義了許多不同的信任級別：Full, High, Medium, Low和 Minimal，你可以用他們來確定ASP.NET應用程序的特權授予。除了這些策略中的第一種在配置文件 web_hightrust.config, web_mediumtrust.config等中被指定，其他所有策略位于.NET框架根目錄下的配置子目錄。為了給一個特殊的ASP.NET應用程序 授權一個medium信任等級，你必須給它的web.config文件如下的結構：
<configuration>
<system.web>
<trust level="Medium"/>
</system.web>
</configuration>
2、以最小特權運行
處理單個ASP.NET請求的“工作進程”運行在賬戶為ASPNET的Windows環(huán)境中。這個特殊的賬戶有一個受限的Windows 特權集，為了控制這種損害，應該讓給ASP.NET應用程序。但是，對于工作進程來說，在與IIS相同的賬戶——SYSTEM賬戶下執(zhí)行是可能的。如果你 想要這種情況發(fā)生，你編寫的machine.config文件應該像這樣：
<configuration>
<processModel userName="System" password="AutoGenerate"/>
</configuration>
為了讓這樣的更改生效，必須重啟IIS管理服務和WWW發(fā)布服務。
這樣做的一個原因可能是：為了獲得Windows用戶用于假冒目的的訪問令牌，允許你的ASP.NET代碼從Win32 API中調用LogonUser。但是，這違反了最低權限(least privilege)的基本安全原則，以及顯著增加了成功攻擊所引起的損害。因此在那樣做之前你應該仔細斟酌。
3、身份認證
ASP.NET提供了四中典型的身份認證：None,Windows,Forms以及Passport。每一種認證都是在應用程序的根文件 web.config中配置的。例如，為了完全禁用ASP.NET身份認證——適合于不需要用戶登錄的公共網站，那么你需要這樣的一個配置文件：
<configuration>
<system.web>
<authentication mode="None"/>
</system.web>
</configuration>
你應該牢記IIS身份認證和ASP.NET身份認證之間的相互作用。兩者都將需要被正確地配置，以達到預期的效果。通常情況下，你會在IIS和 ASP.NET兩者之中中使用Windows身份認證模式;或者在IIS中以及在ASP.NET中的None,Forms,Passport的某一種使用 匿名模式。
在IIS和ASP.NET兩者中使用Windows身份認證的優(yōu)點是：密碼不用通過網絡發(fā)送，而是客戶端應用程序向IIS提供了當前登錄用戶身份的相關信 息，那使得這些信息轉發(fā)到你的ASP.NET應用程序上。這種方法的缺點是：它依賴于客戶端和服務器端的Windows操作系統(tǒng)。Forms式的身份認證 對于基于互聯網的系統(tǒng)是一種更合適的方法，但是在這種情況下，使用SSL/TLS來確保用戶提供的憑證是加密的，這非常有必要。
4、假冒
不管Windows身份認證是否已經選擇，ASP.NET身份認證沒有指明ASP.NET應用程序運行下的用戶環(huán)境。如果你想要你的應用程序在任意賬號，而不僅僅是ASPNET賬號的環(huán)境中運行，你必須要假冒身份。
假設請求的用戶已經被IIS許可為有效的Windows用戶，這是由以下web.config中的內容完成的：
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>
這將導致ASP.NET應用程序假冒發(fā)出請求的用戶。然而，如果IIS設置為匿名身份認證，那么在IIS中，ASP.NET應用程序假冒任意一個用戶賬號，這些賬號已經被配置為匿名訪問。
如果你想要你的ASP.NET應用程序假冒特定的用戶，這是很簡單的：
<configuration>
<system.web>
<identity impersonate="true" userName="Foobar" password="baz"/>
</system.web>
</configuration>
在此很明顯的危險就是：在web.config中用戶憑證以明文形式存在。避免該危險是可能的，我們通過在注冊表中存儲加密的用戶憑證，并且從web.config的元素來引用他們。
<identity impersonate="true"
userName="registry:HKLMSoftwareMyAppAspNet,Name",
password="registry:HKLMSoftwareMyAppAspNet,Password"/>
這個實用的aspnet_setreg.exe必須被用于加密用戶憑證以及在注冊表中存儲加密的用戶憑證。
5、授權
當你在ASP.NET中應用Windows授權時，為了訪問一個給定的資源，被授權的用戶必須有必要的NTFS權限。這被稱為文件授權(file authorization)。ASP.NET支持其他的更具靈活性的授權類型，這被稱為URL授權(URL authorization)。不像文件授權，這是通過應用程序的web.config文件來配置的。它主要是基于通過對ASP.NET身份認證來對應用 程序進行分配;而不是基于一個經過許可的Windows賬戶的權限上。一個簡單URL授權配置的例子如下：
<configuration>
<authorization>
<allow verbs="GET" users="Fred,Joe"/>
<deny verbs="POST" users="Fred,Joe"/>
<allow roles="Developers"/>
<deny users="*"/>
</authorization>
</configuration>
這個例子允許用戶Fred和Joe將HTTP GET請求提交到應用程序，以求得由web.config文件管理的網站中的任意資源。但是若通過HTTP POST請求，就會拒絕他們訪問這些資源。擔任開發(fā)者角色的任意人(除了Fred或 Joe)是允許無限制的訪問該網站的，但是其他所有用戶被拒絕訪問任何資源。這些元素的順序非常重要，因為第一個匹配將是ASP.NET會使用到的。最后 明確通常需要鎖定網站，因為默認情況下，machine.config文件包括了這樣的配置：
<authorization>
<allow users="*"/>
</authorization>
|