owasp总结

A01：失效的访问控制（越权）

将敏感信息泄露给未经授权的参与者、通过发送的数据泄露敏感信息、跨站请求伪造

风险说明：

访问强制实施策略，使用户无法在于其权限之外操作。失败的访问控制通常导致未授权的信息泄露，修改或销毁所有数据，或在用户权限之外执行业务能力。
常见的访问控制脆弱点：

  • 违法最小权限原则，即访问权限应只授权特定能力、角色或用户、但实际上任何人都可以访问。
  • 通过修改URL（参数修改或强制浏览），内部应用程序状态或者HTML页面，或者使用修改API请求的攻击工具绕过访问控制检查。
  • 通过提供唯一的识别符允许查看或编辑其他账户。
  • API没有对POST、PUT和DELETE强制执行访问控制
  • 特权提升，在未登录的情况下假扮用户或以用户身份登入时充当管理员。

预防措施：

开发人员和QA人员应进行访问控制功能的单元测试和集成测试

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

  • 除公有资源外，默认访问拒绝。
  • 使用一次性的访问控制机制，并在整个应用程序中不断重复它们，最小化跨站资源共享（CORS）的使用
  • 建立访问控制模型以强制执行所有权记录，而不是简单接收用户创建、读取、更新或删除的任何记录
  • 在日志中记录失败的控制访问，并在适当时间向管理员告警（重复故障）

A02：加密机制失效

敏感数据泄露

风险说明：

首先需要确定有哪些数据需要保护，例如：密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护
对于数据，需要确认：

  • 在传输数据过程中是否使用铭文传输？考虑传输协议：HTTP、SMTP、经过TLS升级的FTP。外部网络流量是有害的，需要验证所有内部通信。
  • 无论是在默认情况还是在旧的代码中，是否还是用任何旧的或者脆弱的加密算法或传输协议
  • 是否默认使用加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理密钥回转
  • 接收到的服务器证书和信任链是否经过正确的验证

预防措施：

  • 对应用程序处理、存储或者传输的数据分类，并根据相关要求确认哪些数据敏感
  • 对于没有必要存储的敏感数据，应当尽快清除
  • 确保加密存储所有的敏感数据
  • 确保使用了最新的，强大的标准算法、协议和密钥，并且密钥管理到位
  • 禁用缓存对包含敏感数据的响应
  • 不要使用传统协议HTTP、FTP等来传输敏感数据

A03：注入

源代码审查是检查应用程序是否易被注入攻击的最佳方法
可以对所有参数、标题、URL、cookie、JSON、SOAP和XML数据输入的自动测试

风险产生情况：

  • 应用程序不会验证、过滤或清洗用户提供的数据
  • 动态查询或无上下文感知转译的非参数调用之间在解释器中使用
  • 恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据

预防措施：

  • 推荐是用安全的API
  • 是用肯定或白名单服务器端数据验证
  • 对有任何残余的动态查询，使用该解释器的特定转译语法转译特殊字符
  • 在查询中使用LIMIT和其他SQL控件，以防止SQL注入的情况下大量纰漏记录

A04：不安全的设计

不安全设计和不安全实现直接存在差异，区别设计缺陷和实现缺陷是有原因的，安全设计可能存在实现缺陷，从而导致可能被利用的漏洞
一个不安全设计不能通过一个完美的实现来修复

预防措施：

  • 与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
  • 限制用户或服务的消耗
  • 通过设计咋所有层中严格隔离租户
  • 根据暴露和保护需求，对系统层和网络层进行分成

A05: 安全配置错误

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

配置错误：

  • 应用程序栈的任何部分缺少适当的安全加固，或者云服务的权限配置错误
  • 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、账户或权限）
  • 默认账户和密码：仍可用且没有更改
  • 错误处理机制指向用户纰漏堆栈信息或其他大量错误信息
  • 对于升级的系统，最新的安全特性被禁用或未安全配置
  • 应用程序服务器、应用程序框架，库文件，数据库等没有进行安全配置

预防措施：

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

A06：自带缺陷和过时的组件

不安全的组件是我们努力测试和评估风险的已知问题

风险说明：

如果满足下面某个条件，那么就容易遭到攻击：
- 不知道所使用的组件版本信息（包括服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
- 软件易受攻击，不再支持或过时
- 没有定期做漏洞扫描和订阅使用组件的安全公告
- 软件工程师没有对更新的、升级的、或打过补丁的组件进行兼容性测试
- 没有对组件进行安全配置
### 预防措施：
每个组织都应该指定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置
指定一个补丁管理流程：
- 移除不适用的依赖、不需要的功能、组件、文件和文档
- 仅从官方渠道安全的获取组件，并使用前面的机制来降低组件被篡改或加入恶意漏洞的风险
- 监控那些不再维护或者不发布安全补丁的和组件。如果不能打补丁，就考虑部署虚拟补丁来监控、检查或保护

A07：身份识别和身份验证错误

无效的身份认证
### 风险说明：
- 允许像是攻击者已经拥有有效用户名和密码列表的撞库自动化攻击
- 允许暴力或其他自动化攻击
- 允许预设、脆弱、常见的密码
- 使用脆弱或无效的认证咨讯回复或忘记密码的流程
- 使用明码，被加密的或使用较脆弱杂凑法的密码
### 预防措施：
- 实施弱密码的检查
- 在可能得情况下，实施多因素认证防止自动化撞库攻击，暴力破解，以及遭窃认证咨询被重复利用的攻击
- 不要交付或部署任何预设的认证凭证，特别是管理者
- 限制或增加登入失败尝试延时

A08：软件和数据完整性故障

预防措施：

  • 使用数字签名或类似机制来验证软件或数据来自预期来源，且未被修改
  • 确保库和依赖项目，如：npm或maven，正在使用受信任的存储库。如果风险较高，需要托管一个经过审核的，内部一致合格的存储库
  • 确保使用软件供应链安全工具（如OWASP Dependency Check）来验证组件不包含已知漏洞
  • 确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性
  • 确保CI/CD管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性
  • 确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播，所有未签名或未加密的序列化数据不会发送到不信任的客户端。

A09：安全日志和监控故障

风险说明：

如果不进行日志记录和检测，就无法发现任何违规行为，任何时候都会发现日志记录、检测、监视和主动响应不足的情况：

- 日志只存储在本地
- 渗透测试和动态应用安全测试工具的扫描没有触发情报
- 警告和错误生成的日志或日志记录不充分或日志消息不清晰

预防措施：

开发人员根据应用的风险，实施以下部分或全部控制
- 确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在在足够的用户上下文中，以识别可疑或恶意的账户，并保留足够的
时间以允许延迟的取证分析。
- 确保日志是日志管理解决方案以方便使用的格式生成的
- 确保日志数据被正确编码加密，以防止对日志或监控系统的注入或攻击
- 确保高价值交易又完整性控制的审计跟踪，以防止篡改或删除，例如：只附加数据库表或类似的内容
- DevSecOps团队应该建立有效的监控和警报，以便发现可疑的活动并迅速做出反应
- 建立或采用事故应对和恢复计划，例如：美国国家标准技术研究所（NIST）800-61r2或更高版本。
- 有一些商业和开源的应用程序保护框架：OWASP ModSecurity核心规则集，以及开源的日志相关软件，如：Elasticsearch、Logstash
Kibana(ELK)、具有自定义告警功能

A10：服务端请求伪造（SSRF）

风险说明：
web应用程序在获取远程资源时没有验证用户提供的URL，就会出现SSRF缺陷，他允许攻击者强制应用程序发送一个精心构造的请求到意外的目的地
即使是在有防火墙，VPN或其他类型的网络访问控制列表保护的情况下

预防措施：

开发者可以通过实现以下部分或全部防御手段，纵深防御来阻止SSRF；

网络层防御建议:

  • 在隔离的网络中设置多个远程资源访问功能的网段，以减少SSRF的影响
  • 执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除必须的内部网通信外的所有通信。
  • 建立基于应用的防火墙规则的所有权和生命周期
  • 在防火墙上记录所有接收和阻止的网络流（参见“A09：2021-安全日志和监控故障”）

应用层防御建议：

  • 检查和验证所有客户端提供的数据。
  • 使用白名单允许列表执行URL统一资源标志符、端口和目标
  • 不要给客户端发送原始的回复
  • 禁用HTTP重定向
  • 注意URL的一致性，以避免DNS重新绑定和“检查时间，使用时间”（TOCTOU）竞争条件等攻击
  • 不要通过使用黑名单拒绝列表或正则表达式来缓解SSRF。攻击者拥有有效载荷列表，工具和绕过列表的技能

需要额外考虑的措施

  • 不要再前端系统上部署其他与安全相关的服务（如：OpenID）。控制这些系统上的本地流量（如：localhost）
  • 对于专用和可管理的前端用户，可以在独立的系统上使用网络加密（如：VPN）来满足非常高的安全需求保护