OWASP TOP 10 ( 2021 ) 的详细介绍

目录

Top1-失效的访问控制

Top2-加密失败

Top3-Injection注入攻击

Top4-不安全的设计

Top5-安全配置错误

Top6-易受攻击和过时的组件

Top7-认证和授权失败

Top8-软件和数据完整性故障

Top9-安全日志记录和监控失败

Top10-服务器端请求伪造

Top1-失效的访问控制

1. 失效的访问控制的介绍

​         从第五位上升称为Web应用程序安全风险最严重的类别，常见的CWE包括：将敏感信息泄露给未经授权的参与者、通过发送的数据泄露敏感信息、跨站请求伪造（csrf）。

2. 失效的访问控制的攻击原理

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

3. 失效的访问控制的解决方法

        开发人员和QA人员应进行访问控制功能的单元测试和集成测试。访问控制只在受信服务器端代码或者无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据。

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

Top2-加密失败

1. 加密失败的介绍

​        上升一位到第二位，以前称为“敏感数据泄露”。敏感数据泄露更像是一种常见的表象问题而不是根本原因，敏感数据泄露的根本原因是对数据加密存在有机可乘的漏洞，这项风险重点是与加密机制相关的故障（或缺乏加密机制）

2. 加密失败的解决方法

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

Top3-Injection注入攻击

1. Injection注入攻击的介绍

        入降至第三，常见的CWE：跨站点脚本、SQL注入、文件名或路径的外部控制

2. Injection注入攻击的攻击原理

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

3. Injection注入攻击的解决方法

        防止注入需要将数据与命令和查询分开：

1. 推荐的选择是使用安全的API
2. 使用肯定或者白名单服务器端输入验证
3. 对于任何残余的动态查询，使用该解释器的特定转义语法转义特殊字符
4. 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量披露记录

Top4-不安全的设计

1. 不安全的设计的介绍

​         这是2021的一个新类别，侧重于设计和体系结构缺陷相关的风险，呼吁更多的使用威胁建模、安全设计模式和参考体系结构

2. 不安全的设计的攻击原理

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

3. 不安全的设计的解决方法

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

Top5-安全配置错误

1. 安全配置错误的介绍

        安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务、平台、Web服务器、应用服务器、数据库、框架、自定义代码和预安装的虚拟机、容器和存储。自动扫描器可用于检测错误的安全配置、默认帐户的使用或配置、不必要的服务、遗留选项等。

2. 安全配置错误的攻击原理

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

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

3. 安全配置错误的解决方法

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

Top6-易受攻击和过时的组件

1. 易受攻击和过时的组件的介绍

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

2. 易受攻击和过时的组件的攻击原理

1. 你不知道所使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
2. 软件易受攻击，不再支持或过时。
3. 没有定期做漏洞扫描和订阅使用组件的安全公告
4. 软件工程师没有对更新的、升级的或者打过补丁的组件进行兼容性测试
5. 没有对组件进行安全配置

3. 易受攻击和过时的组件的解决方法

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

1. 移除不使用的依赖、不需要的功能、组件、文件和文档
2. 仅从官方渠道安全的获取组件，并使用前面机制来降低组件被篡改或加入恶意漏洞的风险
3. 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，就考虑部署虚拟补丁来监控、检查或保护

Top7-认证和授权失败

1.认证和授权失败的介绍

        之前称为无效的身份认证，此类别从第二名下滑，现在包含了与身份识别失效相关的CWE。

2. 认证和授权失败的攻击原理

1. 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击
2. 允许暴力或其他自动化攻击
3. 允许预设、脆弱、常见的密码
4. 使用脆弱或无效的认证资讯回复或忘记密码的流程
5. 使用明码，被加密的或使用较脆弱杂凑法的密码

3. 认证和授权失败的解决方法

1. 实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单。
2. 在可能的情况下，实施多因素认证来防止自动化撞库攻击，暴力破解，以及遭窃认证咨询被重复利用的攻击。
3. 不要交付或部署任何预设的认证凭证，特别是管理者。
4. 限制或增加登入失败尝试的延迟。

Top8-软件和数据完整性故障

1. 软件和数据完整性故障的介绍

        在不验证完整性的情况下，做出与软件更新、关键数据和 CI/CD（持续集成/持续部署）管道相关的假设。软件和数据完整性故障与不能防止完整性违规的代码和基础设施有关。 一个例子是应用程序依赖来自不受信任的来源、存储库和内容交付网络 (CDN) 的插件、库或模块。 不安全的 CI/CD 管道可能会导致未经授权的访问、恶意代码或系统受损。 最后，许多应用程序现在包括自动更新功能，其中更新在没有充分完整性验证的情况下被下载并应用于以前受信任的应用程序。

2. 软件和数据完整性故障的攻击原理

        攻击者会上传自己的更新以分发并在所有安装上运行。或者通过对象或数据被编码或序列化为攻击者可以看到和修改的结构，容易受到不安全的反序列化。

3. 软件和数据完整性故障的解决方法

1. 使用数字签名或类似机制来验证软件或数据来自预期来源且未被更改。
2. 确保库和依赖项（例如 npm 或 Maven）正在使用受信任的存储库。如果您有较高的风险状况，请考虑托管经过审查的内部已知良好存储库。
3. 确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞
4. 确保对代码和配置更改有一个审查过程，以最大限度地减少恶意代码或配置可能被引入您的软件管道的机会。
5. 确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性。
6. 确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化数据的篡改或重放

Top9-安全日志记录和监控失败

安全日志记录和监控失败的介绍

        它指的是在没有日志记录和监控，将无法检测到漏洞，此类故障会直接影响可见性、事件报警和取证。

安全日志记录和监控失败的攻击原理

        日志记录和监控不足，再加上与事件响应的集成缺失或无效，使攻击者能够进一步攻击系统，保持持久性，转向更多系统，并篡改、提取或破坏数据。 大多数违规研究表明检测违规的时间超过 200 天，通常由外部方而不是内部流程或监控检测到。

安全日志记录和监控失败的解决方法

1. 在登录、访问控制失败和服务器端输入验证失败期间记录足够的用户上下文，并且日志数据保留足够长的时间。这将帮助您发现可疑活动和帐户
2. 使用日志理解决方案易于处理的日志格式
3. 对所有高价值交易实施具有完整性控制的审计跟踪，以避免删除或篡改企图
4. 使用监控和警报及时发现可疑活动并采取措施
5. 引入事件响应和恢复计划以有效应对攻击

Top10-服务器端请求伪造

1. 服务器端请求伪造的介绍

        2021年版的一个新类别，来源于社区调查（排名第1）。数据显示发生率相对较低，测试覆盖率高于平均水平，并且利用和影响潜力的评级高于平均水平。加入此类别风险是说明：即使目前通过数据没有体现，但是安全社区成员告诉我们，这也是一个很重要的风险。

2. 服务器端请求伪造的攻击原理

        服务器端请求伪造是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF是要目标网站的内部系统。(因为他是从内部系统访问的,所有可以通过它攻击外网无法访问的内部系统,也就是把目标网站当中间人)。

3. 服务器端请求伪造的解决方法

1. 过滤10.0.0.0/8、172.16.0.0/12、12.168.0.0/16、localhost私有地址、Pv6地址
2. 过滤file、dict:、 gopher:、ftp:/危险 schema
3. 对返回的内容进行识别
4. 内网服务开启鉴权(Memcached, Redis, Elasticsearch and MongoDB