OWASP Top 10 2017

2013版至2017版改变了哪些内容?

2013版至2017版改变了哪些内容?

2013年版《OWASP Top 10》	→	2017年版《OWASP Top 10》	OWASP Top 10应用安全风险– 2017
A1 – 注入	→	A1:2017 – 注入	将不受信任的数据作为命令或查询的一部分发送到解析器时,会产生诸如SQL注入、NoSQL注入、OS 注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预 期命令或访问数据。
A2 – 失效的身份认证和会话管理	→	A2:2017 –失效的身份认证	通常,通过错误使用应用程序的身份认证和会话管理功能,攻击者能够破译密码、密钥或会话令牌, 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。
A3 – 跨站脚本(XSS)	↘	A3:2017 –敏感信息泄漏	许多Web应用程序和API都无法正确保护敏感数据,例如:财务数据、医疗数据和PII数据。攻击者可 以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据 容易受到破坏,因此,我们需要对敏感数据加密,这些数据包括:传输过程中的数据、存储的数据 以及浏览器的交互数据。
A4 – 不安全的直接对象引用 [与A7合并]	U	A4:2017 – XML外部实体(XXE) [新]	许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃 取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻 击。
A5 – 安全配置错误	↘	A5:2017 – 失效的访问控制 [合并]	未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数 据,例如:访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。
A6 – 敏感信息泄漏	↗	A6:2017 – 安全配置错误	安全配置错误是最常见的安全问题,这通常是由于不安全的默认配置、不完整的临时配置、开源云 存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。因此,我们不仅需要对所 有的操作系统、框架、库和应用程序进行安全配置,而且必须及时修补和升级它们。
A7 – 功能级访问控制缺失 [与A4合并]	U	A7:2017 – 跨站脚本(XSS)	当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时,或者使用可以创建 HTML或 JavaScript 的浏览器 API 更新现有的网页时,就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器 中执行脚本,并劫持用户会话、破坏网站或将用户重定向到恶意站点。
A8 – 跨站请求伪造 (CSRF)	✖	A8:2017 – 不安全的反序列化 [新,来自于社区]	不安全的反序列化会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行,攻击者也可以 利用它们来执行攻击,包括:重播攻击、注入攻击和特权升级攻击。
A9 – 使用含有已知漏洞的组件	→	A9:2017 –使用含有已知漏洞的组件	组件(例如:库、框架和其他软件模块)拥有和应用程序相同的权限。如果应用程序中含有已知漏 洞的组件被攻击者利用,可能会造成严重的数据丢失或服务器接管。同时,使用含有已知漏洞的组 件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。
A10 – 未验证的重定向和转发	✖	A10:2017 – 不足的日志记录和监控 [新,来自于社区]	不足的日志记录和监控,以及事件响应缺失或无效的集成,使攻击者能够进一步攻击系统、保持持 续性或转向更多系统,以及篡改、提取或销毁数据。大多数缺陷研究显示,缺陷被检测出的时间超 过200天,且通常通过外部检测方检测,而不是通过内部流程或监控检测。

A1:2017-注入

如何防止?

防止注入漏洞需要将数据与命令语句、查询语句分隔开来。

• 最佳选择是使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。注意：当参数化时，存储过程仍然可以引入SQL注入，如果PL/SQL或T-SQL将查询和数据连接在一起,或者执行带有立即执行或exec()的恶意数据。
• 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击,但这不是一个完整的防御,因为许多应用程序在输入中需要特殊字符,例如文本区域或移动应用程序的API。
• 对于任何剩余的动态查询,可以使用该解释器的特定转义语法转义特殊字符。OWASP的Java Encoder和类似的库提供了这样的转义例程。注意:SQL结构,比如:表名、列名等无法转义,因此用户提供的结构名是非常危险的。这是编写软件中的一个常见问题。
• 在查询中使用LIMIT和其他SQL控件,以防止在SQL注入时大量地泄露记录。

A2:2017-失效的身份认证

如何防止?

• 在可能的情况下，实现多因素身份验证,以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。
• 不要使用发送或部署默认的凭证，特别是管理员用户。
• 执行弱密码检查,例如测试新或变更的密码,以纠正“排名前10000个弱密码” 列表。
• 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针的5.1.1章节-记住密码，或其他现代的基于证据的密码策略相一致。
• 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击。
• 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。
• 使用服务器端安全的内置会话管理器,在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中,可以安全地存储和当登出、闲置、绝对超时后使其失效。

A3:2017-敏感数据泄露

如何防止?

对一些需要加密的敏感数据,应该起码做到以下几点:

• 对系统处理、存储或传输的数据分类，并根据分类进行访问控制。
• 熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保护敏感数据。
• 对于没必要存放的、重要的敏感数据,应当尽快清除，或者通过PCI DSS标记或拦截。未存储的数据不能被窃取。
• 确保存储的所有敏感数据被加密。
• 确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且密钥管理到位。
• 禁止缓存对包含敏感数据的响应。
• 确保使用密码专用算法存储密码,如:Argon2 、 scrypt 、bcrypt 或者PBKDF2 。将工作因素(延迟因素)设置在可接受范围。
• 单独验证每个安全配置项的有效性。

A4:2017-XML 外部实体(XXE)

如何防止?

开发人员培训是识别和减少XXE缺陷的关键，此外，防止XXE 缺陷还需要：

• 尽可能使用简单的数据格式(如:JSON)，避免对敏感数据进行序列化。
• 及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高版本。
• 参考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》，在应用程序的所有XML解析器中禁用XML外部实体和DTD进程。
• 在服务器端实施积极的(“白名单”)输入验证、过滤和清理,以防止在XML文档、标题或节点中出现恶意数据。
• 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件。
• 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST 工具可以检测源代码中的XXE漏洞。

如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙( WAF )来检测、监控和防止XXE攻击。

A5:2017-失效的访问控制

如何防止?

• 访问控制只有在受信服务器端代码或没有服务器的 API 中有效，这样这样攻击者才无法修改访问控制检查或元数据。
• 除公有资源外,默认情况下拒绝访问。
• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化CORS使用。
• 建立访问控制模型以强制执行所有权记录,而不是接受用户创建、读取、更新或删除的任何记录。
• 域访问控制对每个应用程序都是唯一的，但业务限制要求应由域模型强制执行。
• 禁用 Web服务器目录列表，并确保文件元数据(如:git)不存在于 Web的根目录中。
• 记录失败的访问控制,并在适当时向管理员告警(如:重复故障)。
• 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。
• 当用户注销后，服务器上的JWT令牌应失效。

开发人员和 QA人员应包括功能访问控制单元和集成测试人员。

A6:2017-安全配置错误

如何防止?

应实施安全的安装过程,包括:

• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置,并且,在每个环境中使用不同的密码。这个过程应该是自动化的,以尽量减少安装一个新安全环境的耗费。
• 搭建最小化平台,该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，(参见A9:2017-使用含有已知漏洞的组件)。在检查过程中，应特别注意云存储权限(如:S3桶权限)。
• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括:分段、容器化和云安全组。
• 向客户端发送安全指令,如:安全标头。
• 在所有环境中能够进行正确安全配置和设置的自动化过程。

A7:2017-跨站脚本(XSS)

如何防止?

防止XSS需要将不可信数据与动态的浏览器内容区分开。这可以通过如下步骤实现:

• 使用设计上就会自动编码来解决XSS问题的框架，如:Ruby 3.0或 React JS。了解每个框架的XSS保护的局限性，并适当地处理未覆盖的用例。
• 为了避免反射式或存储式的XSS漏洞,最好的办法是根据HTML输出的上下文(包括：主体、属性、JavaScript、CSS或URL)对所有不可信的HTTP请求数据进行恰当的转义 。更多关于数据转义技术的信息见:《OWASP Cheat Sheet ‘XSS Prevention’》。
• 在客户端修改浏览器文档时，为了避免DOM XSS攻击，最好的选择是实施上下文敏感数据编码。如果这种情况不能避免，可以采用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》描述的类似上下文敏感的转义技术应用于浏览器API。
• 使用内容安全策略(CSP)是对抗XSS的深度防御策略。如果不存在可以通过本地文件放置恶意代码的其他漏洞(例如:路径遍历覆盖和允许在网络中传输的易受攻击的库),则该策略是有效的。

A8:2017-不安全的反序列化

如何防止?

唯一安全的架构模式是不接受来自不受信源的序列化对象，或使用只允许原始数据类型的序列化媒体。

如果上述不可能的话，考虑使用下述方法:

• 执行完整性检查,如:任何序列化对象的数字签名,以防止恶意对象创建或数据篡改。
• 在创建对象之前强制执行严格的类型约束,因为代码通常被期望成一组可定义的类。绕过这种技术的方法已经被证明,所以完全依赖于它是不可取的。
• 如果可能,隔离运行那些在低特权环境中反序列化的代码。
• 记录反序列化的例外情况和失败信息,如:传入的类型不是预期的类型,或者反序列处理引发的例外情况。
• 限制或监视来自于容器或服务器传入和传出的反序列化网络连接。
• 监控反序列化,当用户持续进行反序列化时,对用户进行警告。

A9:2017-使用含有已知漏洞的组件

如何防止?

应该制定一个补丁管理流程：

• 移除不使用的依赖、不需要的功能、组件、文件和文档。
• 利用如 versions、DependencyCheck 、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE 和 NVD等是否发布已使用组件的漏洞信息,可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。
• 仅从官方渠道安全的获取组件,并使用签名机制来降低组件被篡改或加入恶意漏洞的风险
• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁,可以考虑部署虚拟补丁来监控、检测或保护。

每个组织都应该制定相应的计划,对整个软件生命周期进行监控、评审、升级或更改配置。

A10:2017-不足的日志记录和监控

如何防止?

根据应用程序存储或处理的数据的风险：

• 确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。
• 确保日志以一种能被集中日志管理解决方案使用的形式生成。
• 确保高额交易有完整性控制的审计信息,以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中。
• 建立有效的监控和告警机制,使可疑活动在可接受的时间内被发现和应对。
• 建立或采取一个应急响应机制和恢复计划,例如:NIST 800-61 rev 2或更新版本。

目前已有商业的和开源的应用程序防护框架(例如:OWASP AppSensor)、Web应用防火墙(例如 :Modsecurity with the OWASP Core Rule Set)、带有自定义仪表盘和告警功能的日志关联软件。

2017 OWASP TOP 10 — OWASP-CHINA