OWASP TOP10 大主流漏洞原理和防范措施，易理解版

章节目录

回顾2017年和2021年OWASP主流漏洞都有哪些

一、访问控制崩溃

表现形式

防范

二、敏感数据暴露

防范

三、注入

sql注入分类

SQL盲注

SQL注入产生点

SQL注入的思路

盲注测试的思路

防范SQL

四、不安全的设计

产生的原因

业务漏洞的显现体现

五、安全配置不当

风险点

防范

XXE概念

防范

六、使用含有已知漏洞组件

场景

防范

七、识别和验证失败

风险点

防范

八、软件和数据完整性失败

防范

九、不足的日志记录和监控

场景

改进

十、服务端请求伪造

SSRF的成因

危害

防范

---

回顾2017年和2021年OWASP主流漏洞都有哪些

                                     总览

    2017年版                                                                             2021年版

1. 注入                                                                                         访问控制崩溃
2. 认证崩溃                                                                                     加密失败
3. 敏感数据异常                                                                                  注入
4. XML外部实体（XXE）                                                            不安全的设计
5. 访问控制崩溃                                                                           安全配置不当
6. 安全配置不当                                                                    易受攻击和过时的组件
7. 跨站脚本（XSS）                                                                   识别和认证失败
8. 不安全的反序列化                                                            软件和数据完整性失效
9. 使用已知漏洞组件                                                           安全日志记录和监控失败
10. 日子记录和监控不充分                                                             服务器请求伪造

一、访问控制崩溃

         通过身份验证的用户，可以访问其他用户的相关信息，没有实施恰当的访问权限，攻击者可以利用这个漏洞去查看未授权的功能和数据

表现形式

越权漏洞       {水平越权，垂直越权（向上垂直，向下兼容）}

例如：访问其他用户的账户信息、查看敏感文件、修改其他用户的数据、更改访问权限等

• 通过修改URL、内部应用程序状态或HTML页面绕过访问控制检查或简单地使用自定义地APL攻击工具。

• 允许将主键更改为其他用户地记录，例如查看或编辑他人地账户

• 特权提升，在不登陆地情况下假扮用户，或以用户身份登录时充当管理员

• 以未通过身份验证地用户身份强制浏览地通过身份验证时才能看到地页面或标准用户访问具有相关权限地页面或API没有对POST、PUT、DELETE强制执行访问控制

防范

• 除公有资源外，默认情况下拒绝访问

• 严格判断权限，用户只能操作属于自己的内容

• 记录失败的访问控制，并适当时向管理员告警

• 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害

• 当用户注销后，服务器上的JWT令牌失效

二、敏感数据暴露

        Web应用程序和API都无法正确保护敏感数据，攻击者可泄露容易受到破坏，因此需要对敏感信息数据加密

存在原因：数字系统越来越多，用户个人信息收集后储存分散，业务使用中管理不规范；员工下载违规软件等，导致公司信息泄露等

防范

• 加强员工意识，禁止上传代码
• 谨慎使用第三方云服务器，不要把工作内容存放到云端
• 禁止使用工作邮箱注册非工作相关网站

三、注入

        注入是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的执行语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息

sql注入：通过SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意SQL命令目的的入侵行为  

sql注入原因：SQL命令可以进行查询查询、插入、删除等操作，直接讲这些命令拼接起来，提交命令后就可以间接的操控数据库了

sql注入分类

1、基于数据类型的分类

• 字符串类型注入
• 整形注入

2、基于程度和顺序的注入

• 一阶
• 二阶
• 1='1' false

3、基于从服务器接收到的响应

4、基于错误的sql注入

5、联合查询的类型

6、堆查询注射

SQL盲注

• 基于布尔SQL盲注
• 基于时间的SQL盲注
• 基于报错的SQL盲注

SQL注入产生点

• 通过用户输入的表单域的注入
• 通过cookie注入
• 通过服务器变量注射

SQL注入的思路

1. 判断是否存在注入，注入是字符型还是数字型
2. 猜解SQL查询语句中的字段数
3. 确定显示的字段顺序
4. 获取当前数据库
5. 获取数据库中的表

盲注测试的思路

1. 判断是否存在注入，注入是字符型还是数字型
2. 猜解SQL查询语句中的字段数
3. 猜解当前数据库名
4. 猜解数据库中的表名
5. 猜解表中的字段名
6. 猜解数据

防范SQL

1. 关闭sql错误回显
2. 使用成熟的waf
3. 前端输入字符白名单验证（长度、类型等）
4. SQL服务运行于专门的账号，并使用最小权限
5. 对输入的特殊字符使用转义处理

四、不安全的设计

产生的原因

在开发软件时，在关键身份验证、访问控制、业务逻辑和关键流部位没有进行安全的设计

业务漏洞的显现体现

支付逻辑、密码找回、验证码、暴力破解、验证码重复使用、验证码客户端回显、验证码绕过、验证码自动识别

五、安全配置不当

        安全配置错误时常见的安全问题，通常是由不安全的默认配置、不完整的临时配置、开源云储存、错误的HTTP标头配置以及包含敏感信息的详细错误信息造成的，对操作系统、框架、库和应用程序进行安全配置，即使修补和升级

风险点

• 应用程序启用或者安装了不必要的安全功能
• 默认账户名和密码没有修改
• 应用软件过期或者出新版本
• 应用程序服务器或框架没有进行安全配置
• 错误处理机制披露大量敏感信息

防范

搭建最小化平台；按照加固手册加固；临时文件要及时删除

XXE概念

    当应用程序解析XML文件时包含了对外部实体的引用，攻击这传递恶意包含XML代码文件，读取指定的服务器资源

防范

• 使用简单的数据格式（json），避免对敏感数据进行序列化
• 修复和更新应用程序或底层操作系统使用的所有XML处理器和库。同时通过依赖项检查，将soap更新到1.2版本或更高版本
• 在服务器端实施积极的（“白名单”）输入验证、过滤和清理，以防止在XML文档、标题或节点中出现恶意数据
• 验证XML或XSL文件上传功能是否使用XSD验证或其他验证方法来验证上传的XML文件
• 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST工具可以检测源代码中的XXE漏洞，如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙（WAF）来检查、监控和防止XXE攻击

六、使用含有已知漏洞组件

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

场景

        软件易受攻击，不再支持或过时，包括：OS、Web服务器、应用程序服务器、数据库管理系统、应用程序、API和所有的组件、运行环境和库；没有对更新的、升级的或打过补丁的组件进行兼容性测试

防范

• 移除不使用的依赖、不需要的功能、组件、文件、文档
• 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险
• 持续监控如CVE和NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能

七、识别和验证失败

        通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌、利用其他开发缺陷来暂时性或永久性冒充其他用户身份，通常在退出、密码管理、超时、密码找回、账户更新等方面存在漏洞

风险点

• 允许暴力破解破解密码或账号
• 允许默认的、弱的或众所周知的密码
• 使用明文、加密、或弱散密码
• 缺少或失效的多因素身份验证、暴露URL中的会话ID
• 旧密码泄露
• 会话ID使用时间过长

防范

• 实现多因素身份验证、防止自动、凭证填充暴力破解和被盗凭据再利用攻击
• 检查弱口令，模拟爆破操作
• 限制或逐渐延迟失败的登录尝试，记录所有失败信息并在凭据填充、暴力破解或其他被检测时提醒管理员
• 使用服务器端安全的内置会话管理器，在登陆后生成高度复杂的新随机会话ID。会话ID不能再URL中，可以安全地储存和登出闲置、绝对超时后使其失效

八、软件和数据完整性失败

        软件和数据完整性故障于不能防止完整性违规的代码和基础设施有关，一个例子是应用程序依赖来自不受信任的来源、储存库和内容交付网络的插件、库或模块，不安全的CI/CD管道可能会导致未经授权的访问、恶意代码或系统受损，最后，许多应用程序现在包括自动更新功能，其中更新在没有充分完整性验证的情况下被下载并应用于以前受信任的应用程序，攻击者可能会上传自己的更新以分发并在所有安装上运行，另外一个例子是对象或数据被编码或序列化为攻击者可以看到和修改的结构，容易受到不安全的反序列化

防范

1. 使用数字签名或类似机制来验证软件或数据来自预期来源且未被更改
2. 确保使用安全工具验证组件不包含已知漏洞
3. 确保未签名或未加密的序列化数据不会在没有检查或数字签名的情况下发送到不受信任的客户端

九、不足的日志记录和监控

        不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统，保持持续性或转向更多系统，以及篡改、提取或销毁数据

        大多数缺陷显示，被检测出的时间超过200天，且通常通过外部检测方检测，而不是内部流程或监控检测

场景

• 未记录可审计性事件，如：登录、登录失败和高额交易
• 告警和错误事件未能产生或产生不足的和不清晰的日志信息
• 日志信息仅在本地存储
• 没有利用应用系统和API的日志信息来监控可疑活动
• 对于实时或准实时的攻击，应用程序无法检测、处理和告警

改进

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

十、服务端请求伪造

        SSRF（服务器请求伪造）是指攻击者能够从易受攻击的Web应用程序发送精心设计的请求的对其他网站进行攻击，一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。利用一个可以发起网络请求的服务，当跳板来攻击其他服务，简单来说就是A让B帮忙访问C

SSRF的成因

        SSRF形成的原因大都是由服务器提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤于限制，ssrf是利用存在缺陷的web应用作为代理去攻击远程和本地服务器，也就是说，对于为服务器提供服务的其他应用没有对访问进行限制，如果我构造好我的访问包，那我就有可能利用目标服务对他的其他服务器应用进行调用

危害

1. 可以对服务器所在的内网、本地进行端口扫描，获取一些服务器信息等
2. 目标网站本地敏感数据的读取
3. 内外网主机应用程序漏洞的利用
4. 内外网web站点漏洞的利用

防范

• 过滤返回信息，验证远程服务器对请求的相应，是比较容易的方法，如果web应用获取某种类型的文件，那么可以把返回结果展示给用户之前先验证返回信息是否符合标准‘
• 统一错误信息，避免用户根据错误信息来判断远程服务器端口状态
• 限制请求的端口为HTTP常用端口，比如80、443、8080、8090
• 黑名单内网IP，避免应用被用来获取内网数据，攻击内网
• 禁用不需要的协议，仅仅允许HTTP和HTTPS请求，可以防止类似于file://、ftp;//等引起的问题

喜欢的同学请动动小手点个赞，收藏一下，有问题请在评论区指出或者私聊，转载请注明出处，并附有原文链接，谢谢，你们的支持是我坚持的动力！！！