OWASP top10 的介绍
2021年版TOP 10产生三个新类别，且进行了一些整合
A01：失效的访问控制
从第五位上升称为Web应用程序安全风险最严重的类别，常见的CWE包括：将敏感信息泄露给未经授权的参与者、通过发送的数据泄露敏感信息、跨站请求伪造（csrf）
风险说明：
访问强制实施策略，使用户无法在其预期权限之外操作。失败的访问控制通常导致未经授权的信息泄露，修改或者销毁所有数据，或在用户权限之外执行业务功能。
常见的访问控制脆弱点：
违法最小权限原则或默认拒绝原则，即访问权限应只授予特定能力、角色或用户，但实际上任何人都可以访问
通过修改URL（参数修改或强制浏览），内部应用程序状态或者HTML页面，或者使用修改API请求的攻击工具绕过访问控制检查
通过提供唯一的标识符允许查看或编辑他人账户
API没有对POST、PUT和DELETE强制执行访问控制
特权提升，在未登陆的情况下假扮用户或以用户身份登入时充当管理员
预防措施
开发人员和QA人员应进行访问控制功能的单元测试和集成测试
访问控制只在受信服务器端代码或者无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据
除公有资源外，默认访问拒绝
使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨资源共享（CORS）的使用
建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、读取、更新或删除的任何记录
在日志中记录失败的访问控制，并在适当时向管理员告警（例如：重复故障）
A02：加密机制失效
上升一位到第二位，以前称为“敏感数据泄露”。敏感数据泄露更像是一种常见的表象问题而不是根本原因，这项风险重点是与加密机制相关的故障（或缺乏加密机制）
风险说明
首先要确认：对传输中的数据和存储数据都有哪些保护需求。例如：密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护。
对于数据，要确认：
在传输数据过程中是否使用明文传输？这和传输协议有关：HTTP、SMTP、经过TLS升级的FTP。外部网络流量是有害的，需要验证所有的内部通信
无论是在默认情况还是在旧的代码中，是否还在使用任何旧或者脆弱的加密算法或传输协议
是否默认使用加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理或密钥回转
接收到的服务器证书和信任链是否经过正确验证
预防措施
对应用程序处理、存储或者传输的数据分类，并根据相关要求确认哪些数据敏感
对于没有必要存储的敏感数据，应当尽快清除
确保加密存储所有的敏感数据
确保使用了最新的，强大的标准算法、协议和密钥，并且密钥管理到位
禁用缓存对包含敏感数据的响应
不要使用传统协议HTTP、FTP等来传输敏感数据
A03：注入
注入降至第三，常见的CWE：跨站点脚本、SQL注入、文件名或路径的外部控制
风险说明
源代码审查是检查应用程序是否易受注入攻击的最佳方法。
强烈鼓励针对所有参数、标题、URL、cookie、JSON、SOAP和XML数据输入的自动测试
风险产生情况：
应用程不会验证、过滤或清洗用户提供的数据
动态查询或无上下文感知转义的非参数化调用之间在解释器中使用
恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据
预防措施
防止注入需要将数据与命令和查询分开：
推荐的选择是使用安全的API
使用肯定或者白名单服务器端输入验证
对于任何残余的动态查询，使用该解释器的特定转义语法转义特殊字符
在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量披露记录
A04：不安全设计
这是2021的一个新类别，侧重于设计和体系结构缺陷相关的风险，呼吁更多的使用威胁建模、安全设计模式和参考体系结构
风险说明
不安全设计和不安全实现直接存在差异，我们区别设计缺陷和实现缺陷是有原因的，安全设计仍然可能存在实现缺陷，从而导致可能被利用的漏洞。
一个不安全设计不能通过一个完美的实现来修复。
预防措施
与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
限制用户或服务的资源消耗
通过设计咋所有层中严格隔离租户
根据暴露和保护需要，对系统层和网络层进行分层
A05：安全配置错误
从上一版的第六名提升，90%都进行了某种形式的配置错误测试。
风险说明
缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中
你的应用程序可能受到攻击，如果应用程序是：
应用程序栈的任何部分缺少适当的安全加固，或者云服务的权限配置错误
应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、账户或权限）
默认账户和密码仍然可用且没有更改
错误处理机制向用户纰漏堆栈信息或其他大量错误信息
对于升级的系统，最新的安全特性被禁用或未安全配置
应用程序服务器、应用程序框架（如：Struts、Spring、ASP。net）、库文件、数据库等没有进行安全配置
预防措施
应实施安全的安装过程，包括
一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的消耗
搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和实例。移除或不安装不适用的功能和框架
检查和修复安全配置来适应最新的安全说明、更新和补丁，并将作为更新管理过程的一部分
一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构
A06：自带缺陷和过时的组件
不安全的组件是我们努力测试和评估风险的已知问题
风险说明
如满足下的某个条件，那么你的应用就易受到此类攻击：
你不知道所使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
软件易受攻击，不再支持或过时。
没有定期做漏洞扫描和订阅使用组件的安全公告
软件工程师没有对更新的、升级的或者打过补丁的组件进行兼容性测试
没有对组件进行安全配置
预防措施
每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置
制定一个补丁管理流程：
移除不使用的依赖、不需要的功能、组件、文件和文档
仅从官方渠道安全的获取组件，并使用前面机制来降低组件被篡改或加入恶意漏洞的风险
监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，就考虑部署虚拟补丁来监控、检查或保护
A07：身份识别和身份验证错误
之前称为无效的身份认证，此类别从第二名下滑，现在包含了与身份识别失效相关的CWE
风险说明
允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击
允许暴力或其他自动化攻击
允许预设、脆弱、常见的密码
使用脆弱或无效的认证资讯回复或忘记密码的流程
使用明码，被加密的或使用较脆弱杂凑法的密码
预防措施
实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单
在可能的情况下，实施多因素认证来防止自动化撞库攻击，暴力破解，以及遭窃认证咨询被重复利用的攻击
不要交付或部署任何预设的认证凭证，特别是管理者
限制或增加登入失败尝试的延迟
A08：软件和数据完整性故障
暂无请见谅
A09：安全日志和监控故障
风险说明
如果不进行日志记录和检测，就无法发现任何违规行为，任何时候都会发现日志记录、检测、监视和主动响应不足的情况：
日志只存储在本地
渗透测试和动态应用安全测试工具的扫描没有触发情报
警告和错误生成的日志或日志记录不充分或日志消息不清晰
A10：服务端请求伪造（ssrf）
风险说明
一旦web应用程序在获取远程资源时没有验证用户提供的URL，就会出现ssrf缺陷。它允许攻击者强制应用程序发送一个精心构造的请求到意外的目的地，即使是在有防火墙，VPN获其他类型的网络访问控制列表保护的情况下
预防措施
使用黑白名单进行过来url
