安全系统开发方法

安全系统开发方法

最小化攻击面

添加到应用程序中的每个功能都会给整个应用程序带来未知程度的风险。
安全开发的目的是通过减少攻击面，设计应用程序功能以最大程度地减少攻击面来降低总体风险。

范例：
网页系统功能提供线上全文检索功能，检索功能可能容易受到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