前言

        该内容是 OWASP TOP 10 的学习笔记，笔记内容来源 B 站龙哥的视频【12.Top漏洞10：服务器请求伪造_哔哩哔哩_bilibili】

一、访问控制崩溃

概念

        未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的账户、查看敏感文件、修改其他用户的数据、更改访问权限等。

从表现形式来看，访问控制崩溃也就是我们常说的越权漏洞

越权分为两种

        ①、水平越权：A，B 两个用户权限是相同的，但是 A 可以访问 B 的信息。

        ②、垂直越权（向上垂直）：A 是普通用户，B 管理员用户，A 可以执行 B 的权限。 

简单的方法描述

• 通过修改 URL、内部应用程序状态或 HTML 页面绕过访问控制检查，或简单地使用自定义的 API 攻击工具。
• 允许将主键更改为其他用户的记录，例如查看或编辑他人的账户。
• 特权提升。在不登录的情况下假扮用户，或以用户身份登录时充当管理员。
• 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到得页面、或作为标准用户访问具有相关权限的页面、或 API 没有对 POST、PUT 和 DELETE 强制执行访问控制。

【注： POST、PUT、DELETE 等操作是相当危险的，用户在使用的时候一定要进行身份验证】

防范

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

①、除公有资源外、默认情况下拒绝访问（最小权限原则）。

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

③、记录失败的访问控制，并在适当时向管理员告警（如：重复故障）。

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

⑤、当用户注销后，服务器上的 JWT （ JSON Web Token）令牌应该失效。

二、敏感数据泄露

概念

        很多 Web 应用程序和 API 都无法正确保护敏感数据，例如：财务数据、医疗数据和 PII 数据（个人身份信息）。攻击者可以很容易的获取到，并造成破坏，因此，我们需要对敏感数据加密，这些数据包括传输过程中的数据、存储的数据。通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。

存在的原因

①、数字系统越来越多，用户个人信息收集后存储分散，业务使用中管理不规范

②、随着企事业单位规模的扩大，员工数量逐步增加，信息安全意识参差不齐，可能存在违规使用、随意下载用户个人信息的行为

防范

①、加强员工意识，禁止上传代码到 github 等网站。

②、谨慎使用第三方云服务，不要把工作相关的存放到云端。

③、禁止使用工作邮箱注册非工作相关网站。

三、SQL 注入

概念

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

SQL注入

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

        也就是说，服务器要用户提交一个数据，可是攻击者要么直接提交一个命令，要么提交一个数据后，还在数据后面加上一个命令。

正常的流程是这样

如果这里对 id 参数的内容过滤不严格的话，可能会被攻击者利用，造成 SQL 注入

SQL 注入的原因

        SQL 命令可以进行查询、插入、删除等操作，直接将这些命令拼接起来。所以你提交这些命令后，就可以间接操作数据库了。

详细学习数据库：【SQL 注入总结（详细）_sql注入语句and1=1 '1=1-CSDN博客】

SQL 注入的分类

①、基于数据类型的分类

        a、字符串类型注入

        b、整形注入

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

        a、一阶注射

        b、二阶注射

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

④、基于错误的 SQL 注入

⑤、联合查询的类型

⑥、堆查询注入

⑦、SQL 盲注

        a、基于布尔 SQL 盲注

        b、基于时间的 SQL 盲注

        c、基于报错的 SQL 盲注

SQL 注入的产生点

• 通过用户输入的表单域的注入。例如：post 里面的参数
• 通过 cookie 注入
• 通过服务器变量注射（HTTP 头部）

【所有能与用户进行交互的地方都可能存在注入】

SQL 注入的常见检测字符

• '        (单引号)
• "       (双引号)
• --+    (注释)
• #       (注释)
• and   (与)
• or      (或)
• xor    (非)

SQL 注入的思路

        1、判断是否存在注入，注入是字符类型还是数字类型

        2、猜解 SQL 查询语句中的字段数

        3、确定显示的字段顺序

        4、获取当前数据库

        5、获取数据库中的表

盲注测试的思路

        1、判断是否存在注入，注入是字符型还是数字型

        2、猜解 SQL 查询语句中的字段数

        3、猜解当前数据库名

        4、猜解当前数据库中的表名

        5、猜解表中的字段名

        6、猜解数据

防范

        1、关闭 SQL 错误回显

        2、使用成熟的 waf

        3、前端输入字符白名单验证（长度、类型等）

        4、SQL 服务运行于专门的账号，并且使用最小权限

        5、对输入的特殊字符使用转义处理

四、不安全的设计

漏洞产生原因

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

漏洞利用

        业务逻辑的显性体现：

        1、支付逻辑

        2、密码找回

        3、验证码暴力破解

        4、验证码客户端回显

        5、验证码重复使用

        6、验证码绕过

        7、验证码自动识别

支付逻辑漏洞

        所有涉及购买、支付等方面的功能处就有可能存在支付漏洞

挖掘

        寻找网站的支付系统、或兑换系统，抓包判断有没有敏感信息可以修改

利用

        1、修改支付价格                                6、多重替换支付

        2、修改支付状态                                7、重复支付

        3、修改购买数量                                8、最小额支付

        4、修改优惠券、积分                         9、最大额支付问题

        5、修改支付接口                                10、无限制试用

案例

        这里通过修改 state 的值，可以修改密码，在本来需要原密码的基础上，修改 state 值为 1，系统默认认为随意输入的密码为真，导致存在任意密码重置的逻辑漏洞。

五、安全配置不当

        安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。

可能出现的风险点

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

案例一

        Tomcat 服务器是一个免费的开放源代码的 web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试 JSP 程序的首选。

案例二

        Apache ActiveMQ 是 Apache 软件基金会所研发的开放源代码消息中间件；由于 ActiveMQ 是一个纯 Java 程序，因此只需要操作系统支持 Java 虚拟机，ActiveMQ 便可执行。ActiveMQ 是一个完全支持 JMS 1.1 和 J2EE 1.4 规范的 JMSProvider 实现，尽管 JMS 规范出台已经是很久的事情了，但是 JMS 在当今的 J2EE 应用中间仍然扮演者特殊的地位。

该中间件存在的漏洞

1、ActiveMQ 物理路径泄露漏洞

2、ActiveMQ PUT 任意文件上传漏洞

3、ActiveMQ 反序列化漏洞（CVE-2015-5254）

4、ActiveMQ 信息泄露漏洞（CVE-2017-15709）

防范

• 按照加固手册加固。（密码策略等）
• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
• 临时文件要及时删除

安全配置不当漏洞可以和其他漏洞进行组合

        这里安全配置不当，已经将 2017 年的安全配置不当与 XML 外部实体（XXE）漏洞两种漏洞类型进行了组合。下面就来看一下我们的 XXE 漏洞的原理及如何防范。

XXE 概念

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

        在上面的代码中，XML 外部实体 ‘XXE’ 被赋予的值为：file://etc/passwd。在解析 XML 文档的过程中，关键字 SYSTEM 会告诉 XML 解析器，xxe 实体的值将从其后的 URL 中读取，并把读取的内容替换 entityex 出现的地方，所以 xxe 的值会被替换为 URL（file://etc/passwd）内容值（也就是 passwd 文件的内容）。

        假如 SYSTEM 后面的内容可以被用户控制，那么用户就可以随意替换为其他内容，从而读取服务器本地文件（file://etc/psswd）或者远程文件（http://www.baidu.com/abc.txt），想读什么文件就读什么文件。

防范

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

六、安全配置不当

概念

        通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其他开发缺陷来暂时性或永久性冒充其他用户的身份。

        在开发 web 应用程序时，开发人员往往只关注 web 应用程序所需的功能，所以常常会建立自定义的认证和会话方案。但是要正确实现这些方案却是很难的。结果就在退出、密码管理、超时、密码找回、账户更新等方面存在漏洞。

可能出现的风险点

• 允许暴力破解密码或账号
• 允许默认的、弱的或众所周知的密码，例如 “admin/123456” 或 “admin/admin”。
• 使用明文、加密或弱散列密码。
• 缺少或失效的多因素身份验证。
• 暴露 URL 中的会话 ID （例如 URL 重写）。
• 旧密码泄露
• 会话 ID 使用时间过长

防范

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

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

概念

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

场景

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

防范

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

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

概念

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

防范

        1、使用数字签名或类似机制来验证软件或数据来自预期来源且未被更改（软件在网上会有哈希值，我们可以把下载下来的软件去计算它的哈希值，如何计算出来的值和官方给的一样，那就证明下载下来的软件没问题）

        2、确保使用安全工具验证组件不包含已知漏洞

        3、确保未签名或未加密的序列化数据不会在没有检查或数字签名的情况下发送到不受信任的客户端

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

概念

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

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

场景

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

案例

如何改进

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

十、服务器请求伪造

        SSRF（服务器端请求伪造）是指攻击者能够从易受攻击的 Web 应用程序发送精心设计的请求对其他网站进行攻击。一般情况下，SSRF 攻击的目标是从外网无法访问的内部系统。

        利用一个可以发起网络请求的服务，当做跳板来攻击其它服务，简单来说就是：A 让 B 帮忙访问 C。

SSRF 的成因

        SSRF 形成的原因大都是由于服务器端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。SSRF 是利用存在缺陷的 web 应用作为代理去攻击远程和本地的服务器。

        也就是说，对于为服务器提供服务的其他应用没有对访问进行限制，如果我构造好我的访问包，那我就有可能利用目标服务对他的其他服务器应用进行调用。

SSRF 常见危害

        1、可以对服务器所在内网、本地进行端口扫描，获取一些服务的信息等

        2、目标网站本地敏感数据的读取

        3、内外网主机应用程序漏洞的利用

        4、内外网 web 站点漏洞的利用

防范

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