10.1.7 开发威胁缓解策略

在威胁建模过程的这个阶段,我们已经生成了购物车应用的一个威胁列表,并按照对应用/业务的风险排名。现在是为最高等级的威胁(也就是超过公认的威胁阈值的威胁)开发缓解策略的时候了。

提示  只要你有时间,可以为所有威胁建立缓解策略;实际上,对较低风险的威胁实施的缓解措施花费的精力很少。要有好的判断力。

威胁/风险缓解策略对应用可能是唯一的,但是它们可以分成通用的类别。同样,我们引用Microsoft的Web应用安全框架的“小抄本”将缓解策略划分为对应常见攻击技术的类别。一般来说,缓解措施显而易见:消除(或者限制影响)威胁所利用的漏洞,使用常见的预防和检测措施,以及灵敏的安全控制(例如验证、加密和入侵检测)。

提示  不是所有威胁在下一个版本中都必须得以缓解;有些威胁需要通过长期的不同迭代版本,随着应用技术和架构的更新,才能更好地加以处理。

例如,在我们虚构的购物车应用中,对验证系统的“暴力凭据猜测”威胁可以使用CAPTCHA技术缓解,在6次失败的尝试之后,要求用户手工输入登录界面中提供的CAPTCHA图像显示的信息(关于CAPTCHA的更多信息参见第4章)。(显然,对失败尝试的任何跟踪应该在服务器端进行,因为客户提供的会话数据不受信任;在这个例子中,在每次验证质询中显示CAPTCHA可能更有效)。另一个选项是增加失败登录尝试之间的延时,降低自动攻击发生的速度;这种技术还有附加的好处,可以缓解受到攻击的服务器的负载问题。这两种技术的使用反映了随时改进应用威胁模型以及对新的安全威胁保持跟踪的重要性。

显然,威胁缓解策略不应该仅仅帮助你的组织缓解威胁,还应该预防因疏忽造成的新威胁。常见的例子是设置账户锁定阈值为6,在6次尝试之后禁用该账户。这样的功能可以用于缓解密码猜测威胁。但是,如果攻击者能够猜测或者得到有效的用户名(考虑一下金融机构的账户,其特性就是简单的递增),他们可能自动化密码猜测攻击,很简单地给应用的所有用户造成拒绝服务(DoS)的情况。这样的攻击也可能使支持人员被请求账户重置的电话所淹没。

实现账户超时而非锁定是更好的解决方案。在失败尝试达到阈值后,账户被临时禁用(比如30分钟)而不是完全禁用。将这种账户超时方法与CAPTCHA质询结合将进一步缓解威胁。当然,这些机制对可用性都有影响,应该在现实场景中进行测试,才能更完整地理解安全控制带来的不可避免的妥协。

最后,考虑威胁缓解时不要忘记现成的组件。下面是一些当前可用于Web应用的显而易见的威胁缓解技术实例:

·许多Web和应用服务器自带预先打包的通用错误信息页面,提供给攻击者较少的信息。

·平台扩展如UrlScan和ModSecurity提供HTTP输入过滤“防火墙”。

·开发框架如ASP.NET和Apache Struts(Java EE)提供公告牌授权和输入校验例程。