OWASP TOP 10

先从复制一份top10开始

web 2017年版《OWASP Top 10》

A1:2017 – 注入

将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。

A2:2017 –失效的身份认证

通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

A3:2017 –敏感信息泄漏

许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗数据和PII数据。攻击者可以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据以及浏览器的交互数据。

A4:2017 – XML外部实体（XXE） [新]

许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。

A5:2017 – 失效的访问控制 [合并]

未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

A6:2017 – 安全配置错误

安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。

A7:2017 – 跨站脚本（XSS）

当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建 HTML或 JavaScript 的浏览器 API 更新现有的网页时，就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。

A8:2017 – 不安全的反序列化 [新，来自于社区]

不安全的反序列化会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行，攻击者也可以利用它们来执行攻击，包括：重播攻击、注入攻击和特权升级攻击。

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

组件（例如：库、框架和其他软件模块）拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。

A10:2017 – 不足的日志记录和监控 [新，来自于社区]

不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及篡改、提取或销毁数据。大多数缺陷研究显示，缺陷被检测出的时间超过200天，且通常通过外部检测方检测，而不是通过内部流程或监控检测。

移动端 2016年版《OWASP Top 10》

M1-平台使用不当这个类别包括平台功能的滥用，或未能使用平台的安全控制。

它可能包括 Android 的意图（ intent）、平台权限、 TouchID 的误用、密钥链（ KeyChain）、或是移动操作系统中的其他一些安全控制。有几种方式使移动应用程序能受到这类风险。

M2-不安全的数据存储

这个新的类别是《 2014 年版十大移动安全威胁》中 M2 和 M4 的组合。这个类别包括不安全的数据存储和非故意的数据泄漏。

M3-不安全的通信

这个类别包括不健全的握手通信过程、 SSL 版本的不正确使用、脆弱协议、敏感信息的明文传输，等等。

M4-不安全的身份验证

这个类别包括对终端用户身份验证或坏的会话管理的意见。这可以包括：当被要求时，没有对所有用户进行身份识别。当被要求时，没有保持对用户身份的确认。会话管理中的漏洞。

M5-加密不足

代码使用加密技术对敏感信息资产进行加密。然而，加密技术的应用在某种程度上是不足的。需要注意的是，任何与 TLS 或 SSL 有关的内容调整至 M3 中。此外，如果应用程序在它应当使用加密技术时而没有成功使用，该类问题可能属于 M2。本类别是在尝试使用加密技术时，却又没有成功使用的问题。

M6-不安全的授权

这个类别包括任何失败的授权行为（例如：在客户端的授权决策、强迫浏览等。）。它有别于身份验证问题（例如：设备注册、用户标识等）。如果应用程序在需要的时候没有验证用户的身份 (例如：当访问要求需经过身份验证和授予权限时，授予匿名用户访问某些资源或服务的权限)，那就是一起身份验证失败事件，而不是授权失败事件。

M7-客户端代码质量问题

这个类别曾经是“通过不可信的输入做出安全决定” ，是我们较少使用的类别之一。这将包括全部的移动客户端代码级别开发问题。这不同于服务器端的编码错误。本类别包括例如缓冲区溢出、字符串格式漏洞以及其他不同类型的代码级错误，而这些错误的解决方法是重写在移动设备中运行的某些代码。

M8-代码篡改

本类别包括二进制修补、本地资源修改、方法钩用、方法调整和动态内存修改。一旦应用程序交付至移动设备，代码和数据资源就都存放在那里。攻击者要么可以直接修改代码、动态修改内存中的内容、更改或替换应用程序使用的系统 API，要么可以修改应用程序中的数据和资源。这可以为攻击者提供颠覆本软件用户的使用预期或是获得金钱利益的直接方法。

M9-逆向工程

本类别包含对核心二进制代码的分析，以确定它的源代码、库文件、算法和其他资产。比如： IDA Pro、 Hopper、 otool 和其他二进制检验工具，使攻击者能洞察到应用程序内部的工作原理。这可用于在应用程序中发现其他漏洞，并可揭露有关后端服务器、加密常数、密码以及知识产权的信息。

M10-无关的功能

通常，开发人员不会打算将隐藏地后门程序功能或其他内部开发安全控件发布到生产环境中。例如：开发人员可能在一个混合应用程序中无意包含了一个作为注释的密码。另一个例子包括在测试阶段禁用了双因子身份验证。

对于移动端的补充——IOS安全开发须知

M1

毫无疑问，移动设备用户面临的最大风险是设备丢失或被盗。任何捡到或偷盗设备的人都能得到存储在设备上的信息。这很大程度上依赖设备上的应用为存储的数据提供何种保护。苹果的iOS提供了一些机制来保护数据。这些内置的保护措施适合大多数消费级信息。如果要满足更严格的安全需求（如财务数据等），可以在应用程序中内置更好的保护措施。

补充

一般来说，一个应用程序应该只存储执行其功能所必须的数据。包括旁路数据在内，如系统日志（见M8章节），无论任何形式的敏感数据，都不应该明文存储在应用的沙箱中（如：~/Documents/*）。消费级的敏感数据应该使用苹果提供的API存储在安全的容器中。

少量的消费级敏感数据，如用户身份认证凭证、会话令牌等，可以安全的存储在设备的钥匙扣（Keychain）内（see Keychain Services Reference in Apple’s iOS Developer Library）
对于更大或更一般类型的消费级数据，可以安全的使用苹果的文件保护机制存储。(see NSData Class Reference for protection options).
如果数据必须要存储在本地，数据的安全敏感度会比普通的消费级敏感度更高，这时可以考虑使用不受苹果的内置加密机制限制（如：keying与用户设备的四位数字PIN编码绑定）的第三方加密API。SQLcipher（http://sqlcipher.net）就是这样一种免费解决方案。在此过程中，适当的密钥管理是极为重要的——当然，这超出了本文的讨论范围。
将数据存储在keychain的最安全的API参数是kSecAttrAccessibleWhenUnlocked（在iOS5/6中是默认值）。
避免使用NSUserDefaults存储敏感信息。
请注意，使用NSManagedObects存储的所有数据/实体都是存放在一个未加密的数据库文件中的。

M2

尽管大多数服务器端控制是在服务器端处理的。我们参考Web Service Security Cheat Sheet，其实有些是可以在移动端做的，同时移动端可以帮助服务器做一些必要的工作。

补充

设计并实现让移动端和服务端支持的一套共同的安全需求。例如：敏感信息在服务器的处理应该等效于客户端。对所有的客户端输入数据执行积极的输入检查和标准化。使用正则表达式和其他机制来确保只有允许的数据能进入客户端应用程序。如果有可能，对所有的不可信数据进行编码。

M3

网络应用程序的敏感数据被窃听攻击比较常见，iOS手机应用也不例外。

补充

所有应用程序都可能在开放的Wi-Fi网络环境中使用，要设计和实现这个场景下的防护措施。列一个清单，确保所有清单内的应用数据在传输过程中得到保护（保护要确保机密性和完整性）。清单中应包括身份认证令牌、会话令牌和应用程序数据。确保传输和接收所有清单数据时使用SSL/TLS加密（See CFNetwork Programming Guide）。确保你的应用程序只接受经过验证的SSL证书（CA链验证在测试环境是禁用的；确保你的应用程序在发布前已经删除这类测试代码）。通过动态测试来验证所有的清单数据在应用程序的操作中都得到了充分保护。通过动态测试，确保伪造、自签名等方式生成的证书在任何情况下都不被应用程序接受。

M4

当移动应用是web应用的时候，数据注入攻击有可能存在，不过攻击场景往往有所不同（例如：利用URL来发送扣费短信或拨打扣费电话）。

补充

一般来说，web应用程序的输入验证和输出过滤应该遵循同样的规则。要标准化转换和积极验证所有的输入数据。即使对于本地SQLite/SQLcipher的查询调用，也使用参数化查询。当使用URL scheme时，要格外注意验证和接收输入，因为设备上的任何一个应用程序都可以调用URL scheme。当开发一个web/移动端混合的应用时，保证本地/local的权限是满足其运行要求的最低权限。还有就是控制所有UIWebView的内容和页面，防止用户访问任意的、不可信的网络内容。

M5

尽管授权和身份认证很大程度上是由服务端来控制的，但是一些移动端特性（如唯一设备标示符）和常见的使用方式也会加剧围绕安全验证、授权用户和其他实体之间的安全问题。

补充

一般来说，web应用程序的身份验证和授权应该遵循相同的规则。永远不要使用设备唯一标示符（如UDID、IP、MAC地址、IMEI）来验证用户身份。避免可能的“带外”（out-of-band）身份认证令牌发送到用户用来登陆的相同的设备（如：将短信发送到同一个iPhone）。实现强壮的服务端身份验证、授权和会话管理。验证所有的API请求和支付资源。

M6

同样，会话处理一般主要是服务器端的工作，但是移动端设备往往有通过不可预见的方式放大传统问题的倾向。例如，在移动端设备上，会话通常要比传统web应用程序的持续时间要长。

补充

在大多数情况下，你要遵循与web应用程序相同的会话管理安全实践，两者只有些许不同。永远不用使用设备唯一标示符（如UDID、IP、MAC地址、IEME）来标示一个会话。保证令牌在设备丢失/被盗取、会话被截获时可以被迅速重置。务必保护好认证令牌的机密性和完整性（例如：只使用SSL/TLS来传输数据）。使用可信任的服务来生成会话

M7

虽然iOS没有给应用很多彼此通讯的渠道，但存在的那些仍有可能通过数据注入攻击、恶意应用等被攻击者利用。

补充

输入验证、输出转义和授权控制相结合可以对付这类缺陷。规范和积极的验证所有输入数据，特别是应用程序之间的边界调用。当使用URL scheme时，要格外小心的验证和接收输入数据，因为设备上的任何应用程序都能调用URL scheme。根据上下文过滤所有不可信的输出，从而保证没有改变应用意图的输出。验证是否允许调用者访问其所请求的资源。如果可能的话，当应用程序访问请求的资源时，提示用户，让用户选择允许/不允许访问。

M8

旁道数据通常是指那些用来管理或具有非直接功能性目的的I/O数据。如web缓存（用来优化浏览器速度）、击键记录（用户拼写检查）以及其他类似的数据。苹果的iOS提供的一些机制，让一些旁道数据从一个应用程序泄露成为可能。这些数据能够被捡到或偷窃被害人设备的人获取。大多数这类数据都能被应用程序编码控制。

补充

在设计和实现所有应用时，都要考虑用户的设备丢失或被盗的情况。首先确认所有的旁道设备数据。这些数据资源至少包括：web缓存、击键记录、屏幕截图、系统日志、剪切缓冲区和第三方类库使用的数据。不要将敏感数据（身份凭证、令牌、个人身份信息PII）放在系统日志中。控制iOS的屏幕截图，防止敏感的应用数据在应用最小化时被截图。在输入敏感数据时，禁用键盘记录，防止这类数据被明文存储到设备上。操作敏感数据时，禁用剪切板缓冲区，防止数据在应用外泄露（被其他应用读取）。动态的测试应用程序的数据存储方式和通讯方式，确保没有敏感信息被不当的传输或存储

M9

尽管绝大多数的加密软件的弱点源于密钥管理安全性不足，但是加密系统的各个方面都应该精心设计和实现。移动应用也是这样。

补充

永远不要将密钥硬编码或存储在攻击者可以很简单就能找到的地方：包括明文数据文件、属性文件和编译后的二进制文件。使用安全的容器来存储加密密钥；此外，当密钥是由一个安全服务器控制时，构建一个安全的密钥交换系统，永远不要存储在移动设备上。使用强壮的加密算法及算法实现，包括密钥生成器、哈希等。尽可能使用平台加密API时，如果不能使用，则使用可信任的第三方加密代码。消费级敏感数据应该使用苹果提供的API，将数据存储在安全容器中。

少量数据，如用户身份认证凭证、会话令牌等，可以安全的存储在设备的Keychain内。(更多请看：Keychain Services Reference in Apple’s iOS Developer Library).

较大或一般类型的数据，苹果的文件保护机制可以保证安全。(更多请看： NSData Class Reference for protection options).

为了更好的保护静态数据，可以使用第三方的加密API，这样就可以不受苹果加密的固有缺陷的限制（如：keying与用户设备的四位数字PIN编码绑定）。SQLcipher是一个免费可用的方案（更多请看：http://sqlcipher.net）

M10

各种敏感数据都能被iOS应用程序泄露。更可怕地是，每个应用程序编译后的二进制代码都可以被有能力的对手（攻击者）实施逆向工程。

补充

所有必须保证私密的东西都不应放在移动设备上；最好将他们（如算法、专有/机密信息）存储在服务器端。如果私密信息必须存储在移动设备上，尽量将它们保存在进程内存中，如果一定要放在设备存储上，就要做好保护。不要硬编码或简单的存储密码、会话令牌等机密数据。在发布前，清理被编译进二进制数据中的敏感信息，因为编译后的可执行文件仍然可以被逆向破解

最后更新于4年前