Top1 ：失效的访问控制
失效的访问控制，也叫越权，指的是在未对通过身份验证的用户，实施恰当的访问控制。攻击者可以利用这一漏洞，访问未经授权的功能或数据。比如，访问其他用户的账户、查看敏感文件、修改其他用户的数据，更改访问权限等等，都属于失效的访问控制造成的后果。
常见风险点：
1.通过修改 URL、内部应用程序状态或 HTML 页面，或仅使用自定义 API 攻击工具来绕过访问控制检查。
2.允许将主键更改为其他用户的记录，允许查看或编辑其他人的帐户。
3.特权提升。在未登录的情况下充当用户或以用户身份登录时充当管理员。
4.元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或用于提升权限或滥用 JWT 失效的 cookie 或隐藏字段。
5.强制以未经身份验证的用户身份浏览经过身份验证的页面或以标准用户身份浏览特权页面。访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。
防范措施：访问控制只有在受信服务器端代码或没有服务器的API中有效,这样攻击者才无法修改访问控制检查或元数据。
1.除公有资源外，默认情况下拒绝访问。
2.严格判断权限,用户只能操作属于自己的内容。
3.记录失败的访问控制，并在适当时向管理员告苞女（女如:重复故障）。
4.对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。
5.当用户注销后,服务器上的JWT令牌应失效。
Top2 ：加密失败
在之前的Top10中，“加密失败”以前叫做“敏感数据泄露”，敏感数据泄露的根本原因是对数据加密存在有机可乘的漏洞，因此2021版改称为“加密失败”更贴切一些。
对于需要加密或加密传输的数据，常见风险点：
1.数据采用明文形式传输，例如使用HTTP、SMTP和FTP等协议。
2.默认情况下或在老代码中使用弱加密算法或过时的加密算法。
3.未强制执行加密。
4.用户代理不验证服务器证书是否有效。
防范措施：
1.加强员工意识,禁止上传代码到github等网站。
2.谨慎使用第三方云服务，不要把工作相关的存放到云端。
3.禁止使用工作邮箱注册非工作相关网站。
Top3 ：注入
注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾添加额外的执行语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。
随着大量主流框架被使用，发生注入攻击的概率也随之下降，“注入”也从2017年的第一位下降到第三位。
SQL注入是典型的注入攻击，攻击者可以在web应用程序中事先定义好的查询语句的结尾添加额外的SQL语句，把SQL命令插入到web表单递交或输入域名或页面请求的查询字符串，从而实现非法操作。
常见风险点：
1.不验证、过滤和清理用户提供的数据
2.没有上下文感知转义的动态查询或非参数化调用直接在解释器中使用。
3.在对象关系映射 (ORM) 搜索参数中使用恶意数据来提取额外的敏感记录。
4.直接使用或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。
防范措施：
- 关闭SQL错误回显；
- 使用成熟的waf；
- 前端输入字符白名单验证（长度、类型等)；
- SQL服务运行于专门的账号,并且使用最小权限5.对输入的特殊字符使用转义处理；
Top4 ：不安全的设计
“不安全设计”是2021年新增的一个类型，它重点关注的是设计缺陷的风险，“不安全设计”代表的是一类漏洞。漏洞产生的原因是：在开发软件时，在关键身份验证、访问控制、业务逻辑和关键流部位没有进行安全的设计。
漏洞利用：
业务逻辑的显性体现：
- 支付逻辑
- 密码找回
- 验证码暴力破解
- 验证码重复使用
- 验证码客户端回显
- 验证码绕过
- 验证码自动识别
Top5： 安全配置错误
安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的HTTP标头配置以及包含敏感信息的详细错误信息所造成的。
常见风险点：
1.在应用程序堆栈的任何部分缺少适当的安全强化或对云服务的权限配置不正确。
2.应用程序启用或安装了不必要的功能（例如，不必要的端口、服务、页面、帐户或权限）。
3.默认帐户及其密码仍处于启用状态且未更改。
4.错误处理向用户显示堆栈跟踪或其他信息过多的错误消息。
5.对于升级的系统，最新的安全功能被禁用或未安全配置。
6.应用程序服务器、应用程序框架（例如，Struts、Spring、ASP.NET）、库、数据库等中安全设置未设置为安全值。
8.服务器不发送安全标头或指令，或者它们未设置为安全值。
9.软件已过时或易受攻击（请参阅 A06:2021-易受攻击和过时的组件）。
防范措施：
- 按照加固手册加固（密码策略）
- 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和实例。移除或不安装不适用的功能和框架。
- 临时文件要删除
安全配置不当与XXE漏洞可以进行组合：
XXE（XML External Entity,XML外部实体注入）漏洞是指：当应用程序解析XML输入时，当允许使用外部实体时，攻击者可传递包含恶意XML代码的文件，导致读取任意文件、探测内网端口、攻击内网网站、发起Dos拒绝服务攻击、执行系统命令等。
防范措施：
1.尽可能使用简单的数据格式（如:JSON)，避免对敏感数据进行序列化。
2.及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测,将SOAP更新到1.2版本或更高版本。
3.在服务器端实施积极的（“白名单”）输入验证、过滤和清理，以防止在XML文档、标题或节点中出现恶意数据。
4.验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件。
5.尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST工具可以检测源代码中的XXE漏洞。如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙（WAF）来检测、监控和防止XXE攻击。
Top6 ：易受攻击和过时的组件
组件(例如:库、框架和其他软件模块)拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。
常见风险点有：
1.不知道所使用的组件的版本
2.不定期扫描漏洞，不关注所使用组件的官方公告
3.没有以基于风险的方式及时修复或升级底层平台、框架和依赖项。这通常发生在修补是变更控制下的每月或每季度任务的环境中，使组织面临数天或数月不必要地暴露于固定漏洞的风险。
4.软件开发人员不测试、升级或修补库的兼容性
5.不保护组件的配置
防范措施：
1.移除不使用的依赖、不需要的功能、组件、文件和文档。
2.仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险。
3.持续监控如CVE和NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。
Top7 ：认证和授权失败
在开发web应用程序时，开发人员往往只关注Web应用程序所需的功能，所以常常会建立自定义的认证和会话方案。但是要正确的实现这些方案却是很难的。结果就在退出、密码管理、超时、密码找回、帐户更新等方面存在漏洞。也就密码等重要数据进行交互的时候,程序存在了问题,并且被利用了。
通俗地说，该漏洞会导致攻击者使用用户的用户名和密码进行填充，从而入侵系统。
常见风险点：
1.允许暴力破解破解密码或账号；
2.允许使用默认密码、弱密码或众所周知的密码，例如“Password1”或“admin/admin”。
3.使用弱或无效的凭据恢复和忘记密码流程，例如无法确保安全的“基于知识的答案”。
4.使用纯文本、加密或弱散列密码（）。
5.缺少或无效的多因素身份验证。
6.暴露 URL 中的会话 ID（例如，URL 重写）。
7.不会正确地使会话 ID 无效。用户会话或身份验证令牌（主要是单点登录 (SSO) 令牌）在注销或一段时间不活动期间未正确失效。
防范措施：
1.在可能的情况下，实现多因素身份验证，以防止自动、凭证填充暴力破解和被盗凭据再利用攻击。
2.检查弱口令，模拟爆破操作。
3.限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。
4.使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储，当登出闲置、绝对超时后使其失效。
Top8 ：软件和数据完整性故障
软件和数据完整性故障与不能防止完整性违规的代码和基础设施有关。
一个例子是应用程序依赖来自不受信任的来源、存储库和内容交付网络(CDN)的插件、库或模块。不安全的CI/CD管道可能会导致未经授权的访问、恶意代码或系统受损。最后，许多应用程序现在包括自动更新功能，其中更新在没有充分完整性验证的情况下被下载并应用于以前受信任的应用程序。攻击者可能会上传自己的更新以分发并在所有安装上运行。
另一个例子是对象或数据被编码或序列化为攻击者可以看到和修改的结构，容易受到不安全的反序列化。
防范措施：
1、使用数字签名或类似机制来验证软件或数据来自预期来源且未被更改;
2、确保使用安全工具验证组件不包含已知漏洞;
3、确保未签名或未加密的序列化数据不会在没有检查或数字签名的情况下发送到不受信任的客户端;
Top9 ：安全日志记录和监控故障
2017年以前，“安全日志记录和监控故障”叫做“日志记录和监控不足”。它指的是在没有日志记录和监控或不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及篡改、提取或销毁数据。大多数漏洞研究显示，漏洞被检测出的时间超过200天，且通常通过外部检测方检测，而不是通过内部流程或监控检测。
常见风险点：
1.不记录可审计的事件，例如登录、失败登录和高价值交易。
2.警告和错误不会生成、或生成不充分或不清楚的日志消息。
3.没有利用应用系统和 API 的日志信息来监控是否存在可疑活动。
4.日志仅存储在本地。
5.对于实时或准实时的攻击，应用程序无法检测、处理和告警。
防范措施：
1.确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。
2.确保日志以一种能被集中日志管理解决方案使用的形式生成。
3.确保高额交易有完整性控制的审计信息,以防止篡改或删除。
4.审计信息保存在只能进行记录增加的数据库表中，建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对。
Top10 ：服务器端请求伪造（SSRF）
SSRF(Server-Side Request Forgery，服务器端请求伪造)是指攻击者能够从易受攻击的Web应用程序发送精心设计的请求的对其他网站进行攻击。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。利用一个可以发起网络请求的服务，当做跳板来攻击其它服务。简单来说就是:A让B帮忙访问C。这一漏洞是在行业调查中添加的，数据显示发生概率较低。
SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。ssrf是利用存在缺陷的web应用作为代理去攻击远程和本地的服务器。也就是说，对于为服务器提供服务的其他应用没有对访问进行限制,如果攻击者构造好访问包，那攻击者就有可能利用目标服务对他的其他服务器应用进行调用。
SSRF常见危害：
- 可以对服务器所在内网、本地进行端口扫描，获取一些服务的信息；
- 目标网站本地敏感数据的读取；
- 内外网主机应用程序漏洞的利用；
- 内外网web站点漏洞的利用；
防范措施：
1.过滤返回信息，验证远程服务器对请求的相应。这是比较容易的方法，如果 Web 应用获取某种类型的文件，那么可以在把返回结果展示给用户之前先验证返回信息是否符合标准。
2.统一错误信息,避免用户根据错误信息来判断远程服务器端口状态。
3.限制请求的端口为HTTP常用端口，比如80、443、8080、8090·黑名单内网IP，避免应用被用来获取内网数据，攻击内网。
4.禁用不需要的协议。仅仅允许HTTP和HTTPS请求，可以防止类似于file://、ftp://等引起的问题；
标签：10,组件,访问控制,top,应用程序,漏洞,2021,使用,攻击者 From： https://www.cnblogs.com/waiwaiq/p/17114539.html