浅谈OWASP TOP10

不安全的软件正在破坏着我们的金融、医疗、国防、能源和其他重要的基础设施。随着我们的软件变得愈加重要、复杂且相互关联，实现应用程序安全的难度也呈指数级增长。而现代软件开发过程的飞速发展，使得快速、准确地识别软件安全风险变得愈发的重要。

1. 注入

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

如何防止：

• 防止注入漏洞需要将数据与命令语句、查询语句分隔开来。
• 最佳选择是使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。
• 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API。
• 对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符。OWASP的JavaEncoder和类似的库提供了这样的转义例程。
• 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量地泄露记录。

2. 失效的身份认证

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

如何防止：

• 在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。
• 不要使用发送或部署默认的凭证，特别是管理员用户。
• 执行弱密码检查，例如测试新或变更的密码，以纠正“排名前10000个弱密码”列表。
• 修改密码复杂度策略，密码由大/小写字母+特殊字符+数字组成，长度大于8位，定期90天修改密码。
• 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击。
• 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。
• 使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、闲置、绝对超时后使其失效。

3. 敏感数据泄露

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

如何防止：

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

4. XML外部实体(XXE)

当开发人员暴露一个对内部实现对象的引用时，例如，一个文件、目录或者数据库密匙，就会产生一个不安全的直接对象引用。在没有访问控制检测或其他保护时，攻击者会操控这些引用去访问未授权数据。许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。

如何防止：

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

5. 失效的访问控制

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

如何防止：

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

6. 安全配置错误

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

如何防止：

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

7. 跨站脚本(XSS)

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

如何防止：

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

8. 不安全的反序列化

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

如何防止：

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

9. 使用含已知漏洞的组件

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

如何防止：

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

10. 不足的日志记录和监控

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

如何防止：

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