【技术分享】OWASPTopTen2017版：得与失

译者：ureallyloveme

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

引言

新的 OWASP Top Ten已出版。让我们来看看一个安全研究员是如何评论今年该版本的得与失。

OWASP Top 10将常见的 web 应用安全漏洞进行了大致分类，有助于团队专注于web 应用程序的各项关键安全活动。我在华盛顿大学教授 Web 应用程序安全课程时，就结合了 OWASP Top 10及其框架。在为Security Innovation（美国知名网络安全供应商）执行应用安全评估的时候，我也用它来对发现的安全漏洞进行归类与分组。然而，我在实践中对它使用得越多，其的好处和缺陷也就越是凸显。

其2017候选版（或称待发版），提供了改进，但是也引入了新的问题。为了使其我的建议列表更为有效，如下将以重要程度为顺序展开：

将A4的"失效的访问控制"措词变更为"失效的授权控制"，以阐明和拓展其含义。

简化A7为专注于日志记录/审计，这是一个可以完全独立开展的关键安全活动。

删除A10的"未受保护的APIs"，在其他类别中添加有关APIs的文字。或是将该类别改为备份。

合并的类别

2017候选版本将 2013年版中类别"A4-不安全的直接对象引用"和"A7-功能级访问控制缺失"合并到了一个单独的类别–"A4失效的访问控制"。我认为这是明智之举，它创造了一个更广泛和强健的、集中于授权控制的类别。然而，我更趋向于将"授权"也包含到该类别的标题中，使之更好地与其他安全框架进行交互。这也将与他们在A2缺失的验证和会话管理中使用到的"验证"相呼应。

为什么呢？

新的“A4失效的访问控制”类别被描述为"对通过了身份验证的用户的限制"没有得到适当的强制执行。攻击者可以利用这些漏洞访问未经授权的功能和/或数据，如访问各种其他用户的帐户、查看敏感的文件、修改其他用户的数据、 更改访问权限等。A4假定用户已经通过了身份验证，而且一旦通过了验证，他将只专注于访问。其实还应该有一句明确且被广泛采用的词语–授权。A4并非关于失效的访问控制，因为它在广义上不太与"访问"相关。它并不涉及身份验证，这在A2中已经有所涵括。A4只专注与授权有关的问题，因此，应该把名称中的"访问"一词替换的。其标题才能够反映出真正的意义和具体的问题。

虽然这可能让人会感觉只是一个语义的问题，但我相信这个措辞的变化对于其上下文的语境并达成理解上的共识是非常重要的。在业界，身份验证和授权有着明确和特定的含义，所以它们应该反映在OWASP的标准中。

对于今年引入的两个新的类别：“A7-攻击检测与防范不足”和“A10-未受保护的API”，这些都是为了试图跟上不断进化的 web 应用环境而引入的。不过，我相信OWASP其他类别的涉及面会使得这两个新类略显多余。

A7-攻击检测与防范不足

这个类别被定义为:"大多数的应用程序和API缺乏针对手动和自动攻击的检测、 以及防止和响应的基本能力。攻击保护远远超出了基本的输入验证，并且涉及到自动检测、记录、响应甚至阻止攻击对漏洞利用的尝试。应用程序所有者还需要有快速部署修补程序以防止攻击的能力。

输入验证能够检测、响应、并且阻止攻击对漏洞利用的尝试。

A7将控件描述为应该"不仅仅是基本的输入验证，还涉及到检测、记录、响应甚至阻止攻击对漏洞利用的尝试。"而这正是输入验证的作用 — — 它检测到恶意或不应出现的用户输入所引发的错误，通过去除，记录或阻止它来作为响应。如果应用程序请求一美元金额的银行转帐，而用户提供的确是一个负数，那么应用程序将能识别该恶意输入，并通过阻断交易来作出回应。所以说将输入验证区别于检测和对漏洞利用尝试的响应，显然在本质上的不准确和具误导性的。

A9 和 A5中涉及到的修补 

A7里提到："应用程序所有者还需要有快速部署修补程序以防止攻击的能力。"而准确地说，这与A9-使用已知漏洞的组件，以及A5-安全配置错误 （其中包括了"软件应该保持更新"）重复了。将修补问题单独成为一个类别，显然是多余的，而且降低了分类的价值。

A7类别并未给整张表带来任何新的内容

如前文所述，用适当的控制来验证用户的输入，以防止A1注入攻击、A2失效的身份验证、A3跨站脚本（XSS）、A4失效的授权、A6敏感信息的泄漏、A8跨站请求伪造（CSRF），所有这些都涵括了检测用户输入、记录（有时候）、响应甚至阻止恶意攻击。登录页面不能节流各种访问的尝试吗？这都是A2或A5涉及到的问题。如果有人使用SQLMap试图攻击的话，这就是A1涵括的问题。如果应用程序需要一个补丁的话，这就是A9涉及到的问题。

A7涵括的是应用程序，而设备则通常超出范围了

如果我们暂时接受攻击防护不足这种类别，那么对于一个组织来说，要解决这问题的最佳途径似乎就是部署 IDS / IPS / WAF设备了。然而，所有这些措施 （网络硬件和基础设施设备） 都是外部的，并非web应用的一部分。虽然我也知道应用程序并非在隔离状态下运行的，但OWASP Top 10应该更关注于web应用的安全，而不是更大的、基础设施方面的生态系统的安全。一念之差，则会在概念上滑入深渊。

不是要治标，而是要治本

A7似乎激发了"将技术掷向问题"的行为。整个行业越来越愿意为“商家过度炒作，却无法兑现”而买单。这些功效有待验证的、面向企业的动态漏洞检测与缓解方案成为了各种公司的巨大财务支出。这些设备本身并无良莠差别，但是在使用的时候应当仔细考虑它们的自身优势和特点。我曾供职过一家大型企业，他们宁可选择部署Web 应用防火墙(WAFs)，而不去真正地修复其web应用程序中的问题。我去与他们的应用程序所有者交流，他们告知我之所以不愿意修复web应用程序的各种漏洞发现，是因为他们已经有了入侵检测系统（IDS），能够捕获各种SQL注入的尝试。这是一种道德风险，这些设备的存在会抑制潜在问题的减轻可能性。

除了我对OWASP Top Ten包含范围的疑问，此问题在根本上还是源于：让传统的网络安全部门承接应用安全方面的责任，这一趋势。这产生了一个试图从网络/基础设施的角度，而不是从解决问题的根源和保护应用程序本身的角度，去解决问题的坏习惯。正是因为如此，我很不情愿地推荐将部署安全设备直接作为OWASP Top 10的一个类别。因为这会怂恿公司去部署一个打包式的解决方案，而不是去认真修复那些属于OWASP其他类别的、潜在的问题，其他分为的根本问题。在某一种类别中，例如A1-注入或A3-跨站脚本XSS，设备可以作为一种非常有用的选择，以及被列为缓解的一种方式，但它们不应该被列成一种单独的类别。

因此，我的建议是删除该类别，或是更改成关注记录，从而让各种控制围绕着阻断、事件响应和审核，以形成一个简单的、总体的重要安全控制。通过这样做，它将填补2013版OWASP类别中的空白在，使各个组织更容易聚焦执行，从而产生更大的应用和整体安全。

A10-未受保护的APIs

A10 指出，"现代应用程序和API通常涉及丰富的客户端应用程序，例如浏览器中的JavaScrip和移动应用程序，连接到某种 API（SOAP / XML，REST / JSON，RPC，GWT 等）。这些API通常是不受到保护的，并且包含许多漏洞。

安全性不足的API通常与安全性不足且GUI欠佳的web应用程序有关。越来越多的web应用程序其实只是在浏览器中运行，并且用于访问API的客户端而已。试图厘清APIs和web应用程序之间的区别只会将问题弄得更为混淆，而降低OWASP Top 10的通用性。例如，我们该如何从API的角度来划分SQL注入漏洞的类别呢？它属于A1的漏洞还是A10的漏洞呢？

对于当前的2017候选版框架来说，它属于两者。将其划归A1是很合理的，但其归入A10也同样说得过去。其影响、缓解和优先级与A1类别联系紧密。而A10类别其本质说就是一种 API，它对整个系统产生了看似不必要地杂乱和冗余。其他的例子还有：

如果API不受保护的，那么它要么是A2-身份验证的问题，要么是A4授权的问题 （注意授权一词在此上下文中比较贴切）。

如果API包含了已知的、易受攻击软件的漏洞，那么它应该被涵括在A9中。

如果API暴露了敏感的数据，那么它应该被涵括在A6中。

如果API容易受到注入的攻击，那么它应该被涵括在A1中。

因此它没有必要单独成为一个自己的类别，相反应该往其他要求中添加API相关论述，从而让应用程序所有者们能够了解到这些问题，并且应用到API以及那些丰富的web应用程序中。 

如果一定要有一个能够替代当前A10的类别，那么应该是 “备份和恢复的不安全或不足”，虽然它可能有点超出左边的标题范畴了。很多时候，应用程序并不能执行充分的备份或恢复机制。CIA三元素（confidentiality, integrity和availability）的最后一部分就是可用性，但是它常在安全中被忽视。强健的信息备份对于应用程序容错能力来说是很重要的。备份问题的有趣之处就在于：它使得可能出现威胁场景中，甚至不需要有传统的攻击者就能造成损失。一个倒霉的管理员可以会擦除掉整个数据库或是源代码，以及价值数以百万美元的IP地址或数据可能会瞬间丢失。这些类型的问题通常不会成为新闻，因为它们往往被归咎为一些令人尴尬的错误，而不是由穿着连帽衫的黑客或是敌对民族国家所犯下的事端。不过随着web应用程序处理和存储着我们越来越多的个人数据，这些信息是否能通过可靠的备份和恢复策略予以安全地保存，比以往任何时候都更加重要了。

OWASP Top Ten影响到开发团队中的每个角色，从需要选择安全设计组件，以缓解OWASP Top Ten中各种漏洞的架构师，到需要做代码防御的开发者，再到为安全和合规目的需要确保没有OWASP Top Ten任何漏洞残留的测试人员。为了您和您的团队，请参阅检我们如下的免费OWASP资源吧：

白皮书：通过对OWASP Top Ten的实践，改进您的应用安全程序(https://web.securityinnovation.com/owasp-top-ten-developers-perspective )

指南：通过对OWASP Top Ten来简化应用程序的安全与合规(https://web.securityinnovation.com/owasp-top-ten )

免费在线课程： DES 225: OWASP Top的威胁及缓解方法(https://www.securityinnovation.com/course-catalog/application-security/secure-design/owasp-top-threats-and-mitigations-free )