共用方式為


執行階段時的 Web 應用程式安全性

更新:2007 年 11 月

部署您的應用程式時需要處理一個安全性問題集。另一個問題集 -- 和一般而言在討論 Web 安全性時更重要的問題集 -- 說明在部署和執行應用程式時的安全性。

Web 應用程式根據定義允許使用者存取中央資源 (即 Web 伺服器) 並透過它存取資料庫伺服器等資源。了解並實作適當的安全性措施,您可以:

  • 防止您自己的資源受到未經授權的存取。

  • 依使用者或角色限制存取層級。

  • 建立資料完整性和機密性,向使用者提供一個可以放心使用應用程式的相對安全環境。

  • 對應用程式存取受限制資源的方式建立控制。

  • 確定應用程式程式碼是如您所希望的方式執行。

這個主題提供有關您如何完成這些目標的一般性討論,它包括其他主題的連結,在這些連結中您可以獲得相關技術的詳細資訊。

您可以利用這些安全性功能類型來協助防止應用程式受到未經授權的存取:

  • 網際網路資訊服務 (IIS) 所提供之屬於其一般 Web 伺服器功能的安全性功能。這些功能包括 Windows 檔案、電腦和使用者層級的安全性。

  • 您可以內建到 ASP.NET 應用程式中以提供特定應用程式存取的安全性。

ASP.NET 中的安全性處理

IIS 會為網站提供許多安全性選項。但是,IIS 的安全性機制是相當廣泛的,因為所有的應用程式都使用相同的機制。此外,IIS 安全性選項 (例如,使用 Windows 整合式安全性) 對應用程式來說可能不一定都很方便使用 (如果是內部網路應用程式,可能會為了簡單性而使用 Windows 整合式安全性)。

因此,若要提供對應用程式之特定部分的存取,您可以使用 ASP.NET 安全性。ASP.NET 安全性會和 IIS 安全性一起執行,但加以擴充以讓您能夠自訂功能,例如何取得使用者認證。

IIS 首先從用戶端接收要求,然後執行已使用 IIS 管理工具建立的應用程式安全性檢查。例如,如果應用程式已在 IIS 中設定為允許匿名存取,則 IIS 不會執行任何認證檢查。執行這個初始驗證檢查之後,IIS 會將要求傳送到 ASP.NET,它可以執行第二層的檢查。ASP.NET 允許您使用不同的準則,指定應用程式中的存取限制:您可以將存取限制為特定網頁或特定使用者等。

驗證

下表描述 ASP.NET 所支援的驗證方法。其中數種與 IIS 驗證重複。如需詳細資訊,請參閱 ASP.NET 驗證

驗證類型

說明

匿名存取

未知使用者會提出要求的應用程式 (通常是公用的 Web 應用程式)。與 IIS 重複。

基本和摘要式驗證

(IIS 安全性選項) 在此案例中,系統會提示不具有認證的使用者提供使用者名稱和密碼。

Windows 整合式安全性 (也稱為 NTLM 安全性)

(IIS 安全性選項) 如果使用者提出的要求已在 Windows 網路中驗證,則 IIS 可以在要求存取資源時傳遞使用者的認證。

憑證驗證

(IIS 安全性選項) 在此案例中,用戶端具有從協力廠商來源取得的憑證 (數位識別)。將對應至用戶端憑證的識別 (Identity) 傳遞至 ASP.NET。

Kerberos

(IIS 安全性選項) Kerberos 驗證通訊協定會定義用戶端與網路驗證服務 (也稱為金鑰發行中心 (KDC)) 間的互動。Windows 2000 和 2003 會在每個網域控制站上將 KDC 實作為驗證服務。

Windows 驗證

(ASP.NET 安全性選項) 與先前列出的 IIS 安全性選項整合。ASP.NET 會採用 IIS 所建立的安全性語彙基元 (Token),並讓其做為設為目前 HttpContextUser 屬性值的 WindowsPrincipal 物件可用。

表單驗證

(ASP.NET 安全性選項) 如果使用者需要經過驗證,則 ASP.NET 可將要求重新導向至您指定的網頁。這個網頁通常包含一個表單,在其中您可取得使用者的名稱資訊 (為了額外的安全性,表單可以使用 HTTPS 通訊協定來交換)。當您的應用程式取得表單資訊時,它可以對使用者的認證執行特定應用程式的檢查。重點是驗證的過程都在您的控制之下 (和 IIS 不一樣),您可以指定表單的外觀,選擇儲存使用者資訊的方式。

如果使用者驗證成功,ASP.NET 會發出加密的 Cookie,其中包含識別使用者可進行後續存取的 Token。

表單驗證是在公用網際網路上對於 ASP.NET 應用程式最容易的選擇,因為它可讓您在相當大的程度上控制使用者驗證方式,並可讓您將驗證儲存在瀏覽器上的語彙基元中。

如需 IIS 安全性的詳細資訊,請參閱 Microsoft TechNet 網站上 Windows Server TechCenter for IIS 中的存取控制項主題。如需 ASP.NET 驗證的詳細資訊,請參閱 ASP.NET 驗證

如需使用具有 Windows Server 2003 網域環境中通訊協定轉換和限制委派的詳細資訊,請參閱 Kerberos Protocol Transition and Constrained Delegation

授權

當 Web 應用程式執行時,它會向 Web 伺服器以及其他如資料庫的處理序 (Process) 要求資源。ASP.NET 處理序在使用者內容中執行,使用者內容會決定您應用程式要求資源的方式。ASP.NET 處理序會做為 Windows 2000 和 Windows XP Professional Edition 上名為 ASPNET (依據預設) 的特殊本機使用者執行,或是做為 Windows 2003 上 ASP.NET 應用程式之應用程式集區的識別 (依據預設,本機 NETWORK SERVICE 帳戶) 執行。這些帳戶執行時具有有限的使用權限。您可為 ASP.NET 處理序指定不同的使用者內容,包括本機 SYSTEM 帳戶 (該帳戶在管理員內容中執行應用程式) 或明確提供其認證的使用者,儘管不建議這樣做。

在您的 ASP.NET 應用程式中,您可以指定不同的使用者具有不同資源的授權權限。如果您的應用程式使用 Windows 驗證,您可以使用 Windows 權限來決定在伺服器上存取特定檔案或資料夾的授權。

或者,您可以使用 URL 的授權,您可以在其中根據不同的準則來授與或拒絕授權:

  • 特定的使用者或識別 (Identity),是根據使用者提供的認證。

  • 角色,是定義為允許多個使用者根據一般角色或功能共用權限的實體 (Entity)。

  • 動詞命令 (Verb),是存取應用程式部分的 HTTP 處理序 (例如 GET 和 POST)。

例如,您可以指定所有的使用者都可以取得應用程式的頁面 (執行 GET 動詞命令),但只有特定的使用者可以將頁面張貼到應用程式。同樣地,您可以指定所有的使用者都可以取得 (GET) 頁面,但特定角色的張貼權限會被拒絕。

您可以對整個應用程式或者以目錄接著目錄的方式來授與 URL 的授權。一般的用途是允許所有的使用者檢視公用目錄中的頁面,但是將限制的頁面儲存在只授權給特定使用者或角色的不同目錄。

注意事項:

根據預設,透過 IIS 提供靜態 (Static) 檔案 (例如影像和樣式表) 時,這些檔案不受 ASP.NET 授權的限制。如果您不想讓所有使用者都能夠存取檔案,則可使用 IIS 安全性功能限制對靜態檔案的存取。如果使用 ASP.NET 程式開發伺服器測試 ASP.NET 應用程式,則會看到不同的行為,這是因為將靜態檔案受到 ASP.NET 授權的限制,一旦停用對那些檔案的匿名存取,即無法向匿名使用者提供那些檔案。您也可以將 IIS 中的靜態檔案副檔名對應至 ASP.NET ISAPI 副檔名,此時會套用 ASP.NET 授權規則 (Rule)。

如需詳細資訊,請參閱 ASP.NET 驗證Web 應用程式的基本安全性實行方式

ASP.NET 組態檔

您使用 Web.config 檔中的設定建立 ASP.NET 安全性選項。該檔案允許您包含不同安全性選項的預先定義項目,包括驗證和授權的區段。Web.config 檔的相關區段可能看起來與下列程式碼相同。

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" />
    </authentication>
    <authorization>
      <deny user="?" />
    </authorization>
  </system.web>
</configuration>

您的應用程式可以包含一個以上的組態檔。根據預設,在應用程式根目錄中有一個組態檔,指定應用程式的整體安全性 — 也就是說,安全性設定會由子資料夾繼承。但是,您也可以在個別的資料夾中建立組態檔,以建立該資料夾的安全性設定。

如需詳細資訊,請參閱 ASP.NET 架構

XML Web Service 安全性

使用 .asmx 檔的 XML Web Service 會使用 ASP.NET 做為 Web 應用程式執行,因此參與的安全性模式與所有 ASP.NET 應用程式相同。例如,XML Web Service 可能會設定為使用基本驗證或 Windows 整合式安全性。

當您在設計階段嘗試將參考加入至 XML Web Service 時 -- 也就是當您要求 XML Web Service 的探索 (Discovery) 文件時 -- XML Web Service 將根據其設定的方式執行標準的 Web 應用程式驗證。例如,如果 XML Web Service 設定為使用基本驗證,它將需要從要求的用戶端取得使用者名稱和密碼。舉例來說,如果 XML Web Service 使用基本驗證的話,[加入 Web 參考] 對話方塊將會提示您提供認證。

如果您建立的應用程式包含對 XML Web Service 的呼叫,則在您進行呼叫之前,您需要確定具有適當的認證,否則呼叫就會失敗。在執行階段時,您可以藉由在呼叫其方法之前,設定表示 XML Web Service 之用戶端物件的 Credentials 屬性,將認證傳遞至 XML Web Service。

因為其他的 ASP.NET 安全性選項可能不夠彈性,XML Web Service 可以實作自訂的驗證方案,在其中認證資訊會在 SOAP 前置資料中傳遞。在此方案中,認證會在用戶端和伺服器間交換之訊息的選擇性部分傳遞。然後,您可以撰寫自訂的 HTTP 模組 (實作 IHttpModule 介面),以接聽前置資料中的資訊,並呼叫您的驗證程式碼。

如同其他 ASP.NET 應用程式一般,XML Web Service 可以實作角色的特定授權,來將存取權限制為應用程式的特定部分。

如需詳細資訊,請參閱 XML Web Service 基礎架構保護使用 ASP.NET 建立的 XML Web Service

建立資料完整性和機密性

驗證和授權建立使用者的身分和他們可以存取的資源。這些安全性功能主要是設計用於保護您的 Web 應用程式免受未經授權的使用。

但是,安全性還有另外一個方面,就是保護使用者的資訊,並讓使用者有信心與您交換敏感資訊。例如,如果您的應用程式要求使用者提供信用卡或其他帳戶號碼、個人資訊或任何使用者可能不想讓其他人知道的資料,則您必須提供他們可以安全地將這項資訊送出給您的方式。

您可以使用 IIS 中的 Secure Sockets Layer (SSL),以藉由使用 HTTPS 通訊協定交換加密資訊。SSL 提供雙向的加密:您的資訊會使用加密 (Encryption) 傳送給使用者,而使用者張貼至您應用程式的資訊也同樣會進行加密。

建立 SSL 和加密

若要使用 SSL 和加密,您必須為您的公司或識別取得伺服器的憑證。憑證是識別網站的數位簽章,別人無法模擬。對於網際網路 (公用) 應用程式,您可從公認的協力廠商憑證單位取得伺服器憑證。對於私用 (內部網路) 應用程式,您可以自行發出伺服器憑證。您可以這樣做,保護內部應用程式,例如人事網站。

您的伺服器憑證還可讓您的瀏覽器使用者設定 SSL 加密的連接。SSL 使用的加密方法稱為 public key encryption。在這種形式的加密中,有兩個金鑰:用來加密資料的公開金鑰 (Public Key),以及您可以保密並用來解密使用公開金鑰加密資訊的私用金鑰。您取得的伺服器憑證包含公開金鑰。當使用者想要使用 SSL 時,您的應用程式會將憑證和公開金鑰傳送到瀏覽器。然後瀏覽器和伺服器就會使用公開金鑰來建立加密其資訊交換的方式。

注意事項:

使用 SSL 需要瀏覽器支援至少 40 位元長的加密金鑰。這個層級在大部分瀏覽器中都可用。然而,這個金鑰長度並不能算是安全的。您可以選擇性地設定 IIS 中的應用程式,讓其只允許具有 128 位元的 SSL 連接。

一旦取得伺服器憑證,您就可以讓使用者使用 https:// 做為取得和張貼 Web 網頁的前置詞,來通知使用者使用 SSL。還可以設定 IIS 中的網站只接受 HTTPS 連接。IIS 和瀏覽器會自動使用加密的通道來交換資訊。

如需如何使用 SSL 的詳細資訊,請參閱 Microsoft 知識庫 中的文件 Q307267<How to: Secure XML Web Services with Secure Sockets Layer in Windows 2000>。如需加密的詳細資訊,請參閱密碼編譯概觀。如需憑證和設定 SSL 的詳細資訊,請參閱 Microsoft TechNet 網站上的 Windows Server TechCenter for IIS

使用 .NET 程式碼安全性

安全性的最後一個方面就是,您應確保應用程式中的程式碼不會遭到不當使用,不論是不小心在不正確的內容中執行或是以惡意的方式使用。因為 ASP.NET 是 .NET Framework 的一部分,所以您還可以利用程式碼存取安全性為允許執行的程式碼建立使用權限。如需詳細資訊,請參閱程式碼存取安全性

請參閱

概念

Web 應用程式的基本安全性實行方式