安全系統開發方法

最小化攻擊面

添加到應用程式中的每個功能都會給整個應用程式帶來未知程度的風險。
安全開發的目的是通過減少攻擊面，設計應用程式功能以最大程度地減少攻擊面來降低總體風險。

範例：
網頁系統功能提供線上全文檢索功能，檢索功能可能容易受到SQL注入攻擊。
降低攻擊可能性則可能有：

• 限制授權帳號使用
• 檢索功能具備資料驗證程序控制
• 以其他限制存取資料方式功能取代

建立安全預設值

有很多方法可以為帳號提供"開箱即用"的體驗，預設情況下，應該由帳號決定是否降低其安全性。

範例：
啟用Session逾時。
可能允許帳號關閉這些功能〈例如：通過"記住我"功能〉，簡化應用程式的使用並增加風險。

最小權限原則

最小權限原建議帳號具有執行其業務流程所需的最小權限。
包括帳號權限，資源權限〈例如：CPU限制、記憶體、網路〉和檔案系統權限。

範例：
如果中介伺服器需要存取網路、資料庫表的讀取存取權限及寫入日誌的能力，應該僅授予需要的權限。
在任何情況下都不應授予中介軟體管理權限。

深度防禦原則

縱深防禦的原則表明，在一種控制措施合理的情況下，以不同方式應對風險的控制措施越多越好。
如果深入使用控制項，可能會使嚴重漏洞變得越來越難以利用，因此不太可能發生。

使用安全編碼，這可以採取基於分層的驗證，集中審核控制的形式，並要求帳號登錄所有頁面。

範例：
如果系統管理界面正確地控制了對網路的存取，檢查了管理帳號的授權並記錄了所有存取，則不太可能受到匿名攻擊。

安全失敗(fail-safe)

相對於快速失敗(fail-fast)，可能有很多原因應用程式無法處理服務，如何處理失敗(fail)才能確定應用程式是否安全。

如果failCode()或isUserRole()失敗或引發異常，則預設情況下，該帳號會誤判為管理員。

//錯誤範例：
isAdmin = true;
try
{
	failCode();	//錯誤發生
	isAdmin = isUserRole("管理員");
}
catch(ex)
{
	log.write(ex.toString());
}

//正確範例：
isAdmin = false;
try
{
	failCode();//錯誤發生
	isAdmin = isUserRole("管理員");
}
catch(ex)
{
	log.write(ex.toString());
}

不信任並驗證外部來源的服務及資料

第三方協力廠商很可能具有與您不同的安全策略和狀態。
您不可能影響或控制任何外部第三方。
無論它們是否為主要供應商或協力廠商。

不能保證外部系統的隱式信任，所有外部系統都應以類似的方式處理，並且在處理之前進行驗證。

範例：
信用卡紅利積點計劃提供者依據網路銀行交易資料，提供了獎勵點數以及兌換項目。
此處應該進行資料驗證，並且檢查獎勵積分是正數，而且數值在正常範圍中。

基於職責和角色的存取權限分離

職責分離是關鍵控制方法。
某些角色的信任等級與普通帳號不同，可以在應用程式的整合組件之間創建一個"制衡"系統。
職責分離限制每個帳號的許可更加容易，這符合最少存取的原則。

範例：
管理員應該能夠打開或關閉系統及設置密碼策略，但不能以超級權限帳號身份登錄到購物平台，例如能夠代表其他帳號"購買"商品。

模糊知識避免風險

關鍵系統的安全性不應該依賴於試圖隱藏細節。
例如：Linux的原始碼可廣泛獲得，但是如果得到適當的保護，Linux是一種安全的操作系統。

範例：
應用程式的安全性不應依賴於對原始碼保密的知識。
安全性應取決於許多其他因素，包括合理的密碼策略，深度防禦，業務交易限制。
可靠的網路體系結構以及審核控制。

保持安全性簡單

攻擊表面積和簡單性並存。
某些軟體工程偏愛複雜的方法，而不是相對簡單直接的程式碼。
當更簡單的方法會越來越快時，開發人員應避免使用雙重否定和複雜的系統架構。

範例：
在單獨的中介伺服器上運行大量的 Singleton 實體物件(Bean、COM+)可能是企業規模之下的做法。
但是簡單地使用帶有適當互斥機制的全域變數來防止競爭情況或許更加安全。

正確解決安全問題

一旦發現安全問題，對它進行測試並理解問題的根本原因就很重要。
使用設計模式時，安全性問題可能會在所有程式碼庫中普遍存在，因此開發正確的修補程式而不引入回歸問題至關重要。

範例：
某使用者發現他們可以通過調整Cookie來查看另一帳號的餘額。
由於cookie處理程式碼在所有應用程式之間共享並影響所有其他應用程式。
必須在所有受影響的應用程式上測試此修復程式。

參考資料

https://www.owasp.org/index.php/Security_by_Design_Principles