应用程序安全风险

攻击者可以通过应用程序中许多不同的路径方法去危害业务或者企业组织。每种路径方法都代表了一种风险。

A1 注入

描述

几乎任何数据源都能成为注入载体，包括环境变量、所有类型的用户、参数、外部和内部Web服务。当攻击者可以向解释器发送恶意数据时，注入漏洞产生。

检测

注入漏洞十分普遍，尤其是在遗留代码中。注入漏洞通常能在SQL、LDAP、XPath或是NoSQL查询语句、OS 命令、XML解析器、SMTP包头、表达式语句及ORM查询语句中找到。

注入漏洞很容易通过代码审查发现。扫描器和模糊测试工具可以帮助攻击者找到这些漏洞。

当您的应用存在如下点时，是脆弱的并易受到攻击：

用户提供的数据没有经过应用程序的验证、过滤或净化。
动态查询语句或非参数化的调用，在没有上下文感知转义的情况下，被用于解释器。
在ORM搜索参数中使用了恶意数据，这样搜索就获得包含敏感或未授权的数据。
恶意数据直接被使用或连接，诸如SQL语句或命令在动态查询语句、命令或存储过程中包含结构和恶意数据。

对业务的影响

注入能导致数据丢失、破坏或泄露给无授权方，缺乏可审计性或是拒绝服务。注入有时甚至能导致主机被完全接管。

防范

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

最佳选择是使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。

注意：当参数化时，存储过程仍然可以引入SQL注入，如果 PL/SQL或T-SQL将查询和数据连接在一起，或者执行带有立即执行或exec()的恶意数据。
使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API。
对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符。OWASP的Java Encoder和类似的库提供了这样的转义例程。

注意：SQL结构，比如：表名、列名等无法转义，因此用户提供的结构名是非常危险的。这是编写软件中的一个常见问题。
在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量地泄露记录。

A2 失效的身份认证

描述

攻击者可以获得数百万的有效用户名和密码组合，包括证书填充、默认的管理帐户列表、自动的暴力破解和字典攻击工具，以及高级的GPU破解工具。会话管理攻击很容易被理解，尤其是没有过期的会话密匙。

检测

大多数身份和访问管理系统的设计和实现，普遍存在身份认证失效问题。会话管理是身份验证和访问控制的基础，并且存在于所有有状态应用程序中。

确认用户的身份、身份验证和会话管理非常重要，这些措施可用于将恶意的未经身份验证的攻击者与授权用户进行分离。

如果您的应用程序存在如下问题，那么可能存在身份验证的脆弱性：

允许凭证填充，这使得攻击者获得有效用户名和密码的列表。
允许暴力破解或其他自动攻击。
允许默认的、弱的或众所周知的密码（例如Password1或 admin/admin）。
使用弱的或失效的验证凭证，忘记密码程序，例如“基于知识的答案”，这是不安全的。
使用明文、加密或弱散列密码。
缺少或失效的多因素身份验证。
暴露URL中的会话ID（例如URL重写）。
在成功登录后不会更新会话ID。
不正确地使会话ID失效。当用户不活跃的时候，用户会话或认证令牌（特别是单点登录（SSO）令牌）没有正确注销或失效。

对业务的影响

攻击者只需要访问几个帐户，或者只需要一个管理员帐户就可以破坏我们的系统。根据应用程序领域的不同，可能会导致放任洗钱、社会安全欺诈以及用户身份盗窃、泄露法律高度保护的敏感信息。

防范

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

A3 敏感数据泄露

描述

攻击者不是直接攻击密码，而是在传输过程中或从客户端（例如：浏览器）窃取密钥、发起中间人攻击，或从服务器端窃取明文数据。这通常需要手动攻击。通过使用图形处理单元（GPU），早前检索的密码数据库可能被暴力破解。

检测

在最近几年，这是最常见的、最具影响力的攻击。这个领域最常见的漏洞是不对敏感信息进行加密。在数据加密过程中，常见的问题是不安全的密钥生成和管理以及使用弱加密算法、弱协议和弱密码。特别是使用弱的哈希算法来保护密码。在服务器端，检测传输过程中的数据弱点很容易，但检测存储数据的弱点却非常困难。

首先你需要确认的是哪些数据是敏感数据（包含：传输过程中的数据、存储数据）而需要被加密。例如：密码、信用卡卡号、医疗记录、个人信息应该被加密，特别是隐私法律或条例中规定需要加密的数据。对于这些数据，要确定：

在数据传输过程中是否使用明文传输？这和传输协议相关，如： HTTP、SMTP和FTP。外部网络流量非常危险。验证所有的内部通信，如：负载平衡器、Web服务器或后端系统之间的通信。
当数据被长期存储时，无论存储在哪里，它们是否都被加密，加密包含备份数据？
无论默认条件还是源代码中，是否还在使用任何旧的或脆弱的加密算法？
是否使用默认加密密钥，生成或重复使用脆弱的加密密钥，或者缺少恰当的密钥管理或密钥回转？
是否强制加密敏感数据，例如：用户代理（如：浏览器）指令和传输协议是否被加密？
用户代理（如：应用程序、邮件客户端）是否未验证服务器端证书的有效性？

对业务的影响

这个领域的错误频繁影响那些本应该加密的数据。通常情况下，这些数据通常包括很多个人敏感信息（PII），例如：医疗记录、认证凭证、个人隐私、信用卡信息等。

防范

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

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

A4 XML外部实体（XXE）

描述

如果攻击者可以上传XML文档或者在XML文档中添加恶意内容，通过易受攻击的代码、依赖项或集成，他们就能够攻击含有缺陷的XML处理器。

检测

默认情况下，许多旧的XML处理器能够对外部实体、 XML进程中被引用和评估的URI进行规范。

SAST工具可以通过检查依赖项和安全配置来发现XXE缺陷。DAST工具需要额外的手动步骤来检测和利用XXE缺陷。因为XXE漏洞测试在2017年并不常见，因此手动测试人员需要通过接受培训来了解如何进行 XXE漏洞测试。

应用程序和特别是基于XML的Web服务或向下集成，可能在以下方面容易受到攻击：

您的应用程序直接接受XML文件或者接受XML文件上传，特别来自不受信任源的文件，或者将不受信任的数据插入XML文件，并提交给XML处理器解析。
在应用程序或基于Web服务的SOAP中，所有XML处理器都启用了文档类型定义（DTDs）
如果为了实现安全性或单点登录（SSO），您的应用程序使用SAML进行身份认证。而SAML使用XML进行身份确认，那么您的应用程序就容易受到XXE攻击。
如果您的应用程序使用第1.2版之前的SOAP，并将XML实体传递到SOAP框架，那么它可能受到XXE攻击。
存在XXE缺陷的应用程序更容易受到拒绝服务攻击，包括： Billion Laughs攻击。

对业务的影响

XXE缺陷可用于提取数据、执行远程服务器请求、扫描内部系统、执行拒绝服务攻击和其他攻击。

防范

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

尽可能使用简单的数据格式（如：JSON），避免对敏感数据进行序列化。
及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高版本。
在应用程序的所有XML解析器中禁用XML外部实体和DTD进程。
在服务器端实施积极的（“白名单”）输入验证、过滤和清理，以防止在XML文档、标题或节点中出现恶意数据。
验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件。
尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST工具可以检测源代码中的XXE漏洞。
如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙（WAF）来检测、监控和防止XXE攻击。

A5 失效的访问控制

描述

对访问控制的利用是渗透测试人员的一项核心技能。SAST工具和DAST工具可以检测到访问控制的缺失，但不能验证其功能是否正常。访问控制可通过手动方式检测，或在某些特定框架下通过自动化检测访问控制缺失。

检测

由于缺乏自动化的检测和应用程序开发人员缺乏有效的功能测试，因而访问控制缺陷很常见。

访问控制检测通常不适用于自动化的静态或动态测试。手动测试是检测访问控制缺失或失效的最佳方法，包括：HTTP方法（如：GET和PUT）、控制器、直接对象引用等。

访问控制强制实施策略，使用户无法在其预期的权限之外执行行为。失败的访问控制通常导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。

常见的访问控制脆弱点包括：

通过修改URL、内部应用程序状态或HTML页面绕过访问控制检查，或简单地使用自定义的API攻击工具。
允许将主键更改为其他用户的记录，例如查看或编辑他人的帐户。
特权提升。在不登录的情况下假扮用户，或以用户身份登录时充当管理员。
元数据操作，如重放或篡改JWT访问控制令牌，或作以提升权限的cookie或隐藏字段。
CORS配置错误允许未授权的API访问。
以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问具有相关权限的页面、或API没有对POST、PUT和DELETE强制执行访问控制。

对业务的影响

技术影响是攻击者可以冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。

防范

访问控制只有在受信服务器端代码或没有服务器的API中有效，这样攻击者才无法修改访问控制检查或元数据。

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

A6 安全配置错误

描述

通常，攻击者能够通过未修复的漏洞、访问默认账户、不再使用的页面、未受保护的文件和目录等来取得对系统的未授权的访问或了解

检测

安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务、平台、Web服务器、应用服务器、数据库、框架、自定义代码和预安装的虚拟机、容器和存储。

自动扫描器可用于检测错误的安全配置、默认帐户的使用或配置、不必要的服务、遗留选项等。

您的应用程序可能受到攻击，如果应用程序是：

应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。
应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
默认帐户的密码仍然可用且没有更改。
错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
对于更新的系统，禁用或不安全地配置最新的安全功能。
应用程序服务器、应用程序框架（如：Struts、Spring、 ASP.NET）、库文件、数据库等没有进行安全配置。
服务器不发送安全标头或指令，或者未对服务器进行安全配置。
您的应用软件已过期或易受攻击。

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

对业务的影响

这些漏洞使攻击者能经常访问一些未授权的系统数据或功能。有时，这些漏洞导致系统的完全攻破。

防范

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

A7 跨站脚本（XSS）

描述

存在三种XSS类型，通常针对用户的浏览器：

反射式XSS：应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。通常，用户将需要与指向攻击者控制页面的某些恶意链接进行交互，例如恶意漏洞网站，广告或类似内容。
存储式XSS：你的应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。存储型XSS一般被认为是高危或严重的风险。
基于DOM的XSS：会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScript API。

检测

不同类型的xss漏洞的检测方法详见 http://blogs.loongeyes.cn/2018/07/29/WEB%E5%AE%89%E5%85%A8/

对业务的影响

XSS对于反射和DOM的影响是中等的，而对于存储的XSS，XSS的影响更为严重，譬如在受攻击者的浏览器上执行远程代码，例如：窃取凭证和会话或传递恶意软件等。

典型的XSS攻击可导致盗取session、账户、绕过MFA、DIV替换、对用户浏览器的攻击（例如：恶意软件下载、键盘记录）以及其他用户侧的攻击。

防范

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

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

A8 不安全的反序列化

描述

对反序列化的利用是有点困难的。因为在不更改或调整底层可被利用代码的情况下，现成的反序列化漏洞很难被使用。

检测

在应用程序中，序列化可能被用于:

远程和进程间通信（RPC/IPC）
连线协议、Web服务、消息代理
缓存/持久性 • 数据库、缓存服务器、文件系统
HTTP cookie、HTML表单参数、API身份验证令牌

如果反序列化进攻者提供的敌意或者篡改过的对象将会使将应用程序和API变的脆弱。

这可能导致两种主要类型的攻击：

如果应用中存在可以在反序列化过程中或者之后被改变行为的类，则攻击者可以通过改变应用逻辑或者实现远程代码执行攻击。我们将其称为对象和数据结构攻击。
典型的数据篡改攻击，如访问控制相关的攻击，其中使用了现有的数据结构，但内容发生了变化。

对业务的影响

反序列化缺陷的影响不能被低估。它们可能导致远程代码执行攻击，这是可能发生的最严重的攻击之一。

防范

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

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

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

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

描述

对一些漏洞很容易找到其利用程序，但对其它的漏洞则需要定制开发。

检测

这种安全漏洞普遍存在。基于组件开发的模式使得多数开发团队根本不了解其应用或API中使用的组件，更谈不上及时更新这些组件了。

如果满足下面的某个条件，那么你的应用就易受此类攻击：

如果你不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或其依赖的组件。
如果软件易受攻击，不再支持或者过时。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、 API和所有的组件、运行环境和库。
如果你不会定期做漏洞扫描和订阅你使用组件的安全公告。
如果你不基于风险并及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。
如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。
如果你没有对组件进行安全配置。

对业务的影响

虽然对于一些已知的漏洞其影响很小，但目前很多严重的安全事件都是利用组件中的已知漏洞。根据你所要保护的资产，此类风险等级可能会很高。

防范

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

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

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

A10 不足的日志记录和监控

描述

对不足的日志记录及监控的利用几乎是每一个重大安全事件的温床。攻击者依靠监控的不足和响应的不及时来达成他们的目标而不被知晓。

检测

判断你是否有足够监控的一个策略是在渗透测试后检查日志。测试者的活动应被充分的记录下来，能够反映出他们造成了什么样的影响。

下列情况会导致不足的日志记录、检测、监控和响应：

未记录可审计性事件，如：登录、登录失败和高额交易。
告警和错误事件未能产生或产生不足的和不清晰的日志信息。
没有利用应用系统和API的日志信息来监控可疑活动。
日志信息仅在本地存储。
没有定义合理的告警阈值和制定响应处理流程。
渗透测试和使用DAST工具（如：OWASP ZAP）扫描没有触发告警
对于实时或准实时的攻击，应用程序无法检测、处理和告警。

如果你的应用使得日志信息或告警信息对用户或者攻击者可见，你就很容易遭受信息泄露攻击

对业务的影响

多数成功的攻击往往从漏洞探测开始。允许这种探测会将攻击成功的可能性提高到近100% 据统计，在2016年确定一起数据泄露事件平均需要花191天时间，这么长时间里损害早已发生。

防范

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

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

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