設計原則
有若干重要原則適用於後面各章中提供的指導說明。您應當學會這些原則並在自己的應用程序設計中予以應用：
| • |
採用最少權限的原則.運行腳本或執行代碼的進程應當儘可能用權限最少的帳戶運行，從而在危及進程安全時限制可能造成的破壞。如果惡意用戶設法將代碼注入某個服務器進程，那麼授予該進程的權限會在很大程度上決定該用戶可執行的操作類型。應當將需要更多信任（和更高權限）的代碼分別隔離在不同的進程內。 ASP.NET 小組有意識地決定運行擁有最少權限的 ASP.NET 帳戶（使用 ASPNET 帳戶）這一修改在 .NET 框架的最初版本中得以實現。但在 .NET 框架的測試版中，ASP.NET 作爲SYSTEM運行，從本質上來說是一種較不安全的設置。 |
| • |
使用縱深防禦。在應用程序的每一層和每個子系統中設置檢查點。檢查點是網關守衛，它們確保只有經過身份驗證和授權的用戶能夠訪問下一個下游層。 |
| • |
不要信任用戶輸入。應用程序應當徹底地驗證所有用戶輸入，然後再根據用戶輸入執行操作。驗證可能包括篩選特殊字符。針對用戶意外地錯誤使用和某些人通過在系統中注入惡意命令蓄意進行攻擊的情況，這種預防性措施對應用程序起到了保護作用。常見的例子包括 SQL 注入攻擊、腳本注入和緩衝區溢出。 |
| • |
使用默認安全設置。開發人員往往僅僅爲了使應用程序運行而使用安全性較低的設置。如果應用程序所需的功能使您不得不減小默認安全設置或更改這些默認的安全設置，請在更改前測試更改所帶來的後果並瞭解可能帶來的隱患。 |
| • |
不要通過隱藏來保障安全。嘗試使用讓人迷惑的變量名來隱藏機密信息或將它們存儲在不常用的文件位置，這些方法都不能提供安全保障。在“捉迷藏”遊戲中，最好使用平臺功能或使用已被證實可行的技術來保護數據。 |
| • |
在關口進行檢查。您不必總是將用戶的安全上下文傳遞到後端進行授權檢查。通常，這種做法在分佈式系統中並不是最佳選擇。在關口檢查客戶端意思是在第一個身份驗證點（例如，Web 服務器上的 Web 應用程序內）授予用戶權限，並確定允許用戶訪問的資源和操作（可能由下游服務提供）。 如果在關口設計可靠的身份驗證和授權策略，就不必將原調用方的安全上下文一路委派到應用程序數據層。 |
| • |
假定外部系統是不安全的系統。如果外部系統不歸您所有，不要假定有人爲您保證安全。 |
| • |
減小表面區域。避免公開不需要公開的信息。如果公開這些信息，就可能進一步引起漏洞。同時，處理錯誤的方式一定要適當。向最終用戶返回錯誤消息時，不要公開任何不需要公開的信息。 |
| • |
以安全的方式顯示錯誤消息。如果應用程序失敗，一定要保護好機密數據。同時，不要在錯誤消息中提供過於詳細的數據，也就是不要提供任何有助於攻擊者發現應用程序漏洞的詳細信息。詳細的錯誤信息應寫入 Windows 事件日誌。 |
| • |
不要忘記您的安全程序受最薄弱環節制約。考慮安全性時，應該將應用程序所有層的安全性都考慮在內。 |
| • |
禁用不使用的內容。您可以通過禁用應用程序不需要的模塊和組件來去除一些潛在的攻擊點。例如，如果應用程序不使用輸出緩存，則應禁用 ASP.NET 輸出緩存模塊。這樣，即使以後在該模塊中發現安全漏洞，應用程序也不會受到威脅。 |