本文介绍了防火墙 的相关知识点

本文介绍了 面试 常见面试题

CVE-2023-37582

产品介绍

RocketMQ是阿里巴巴在2012年开发的分布式消息中间件，后捐献给Apache软件基金会并成为Apache的顶级项目。RocketMQ专为万亿级超大规模的消息处理而设计，具有高吞吐量、低延迟、海量堆积、顺序收发等特点。

漏洞概述

当RocketMQ的NameServer组件暴露在外网，并且缺乏有效的身份认证机制时，攻击者可以利用nameServer更新配置功能，以RocketMQ运行的系统用户身份进行任意文件上传，甚至实现远程代码执行。

CVE-2023-33246

产品介绍

RocketMQ是阿里巴巴在2012年开发的分布式消息中间件，后捐献给Apache软件基金会并成为Apache的顶级项目。RocketMQ专为万亿级超大规模的消息处理而设计，具有高吞吐量、低延迟、海量堆积、顺序收发等特点。

漏洞概述

RocketMQ 5.1.0及以下版本，在一定条件下，存在远程命令执行风险。漏洞源于RocketMQ的NameServer、Broker、Controller等多个组件暴露在公网中且缺乏权限校验。攻击者可以利用该漏洞利用更新配置功能以RocketMQ运行的系统用户身份执行任意操作系统命令。

不知道你在挖洞过程中是否碰到过这样一个问题，资源下载到了，调试环境也搞定了却迟迟找不到合适的地方下断点进行调试，这时候你会选择怎么办？
是去寻找启动类一行一行代码查看直到找到URI的处理函数，还是快准狠地定位到关键点马上出洞？我想不会有人想要选择第一种方法，
但按照第一种方法不断地熟悉不同的框架的过程却是一个挖洞小白向大佬进化的过程，我们往往需要在这个过程中不断地积累足够的经验来熟悉常见的技术与框架，
这几乎是每一个大佬成长路上必须要走的路。毫无疑问，这种曲折的过程最能增长人们的能力，不过这个过程往往是痛苦且枯燥的，在挖洞过程中，时间紧任务重的情况下，
我们往往在这个过程中浪费了大量的时间与精力，所以我给大家简单总结了一下我们应该如何去找到一些常见框架进行资源处理与存放、配置存放与解析规则的方法。

Hutool JSONUtil拒绝服务漏洞（CVE-2022-45690 CVE-2022-45689）

产品介绍

Hutool是一个功能丰富且易用的Java工具库，通过诸多实用工具类的使用，旨在帮助开发者快速、便捷地完成各类开发任务。 这些封装的工具涵盖了字符串、数字、集合、编码、日期、文件、IO、加密、数据库JDBC、JSON、HTTP客户端等一系列操作， 可以满足各种不同的开发需求。

漏洞概述

CVE-2022-45690： 该项目受影响版本存在拒绝服务漏洞，由于org.json.JSONTokener.nextValue::JSONTokener.java组件中并未检验json的嵌套深度。攻击者可以通过构造特制的JSON或XML数据在程序解析时导致JVM溢出从而实现拒绝服务(DoS)攻击。

CVE-2022-45689：该项目受影响版本存在拒绝服务漏洞，由于JSONObject.java中JSONObject方法对于要解析的json并未检验是否合法，在后续解析JSON时就会因为内存不足而造成拒绝服务漏洞。

SnakeYaml反序列化过程与漏洞原理分析（CVE-2022-1471）

文字描述难免有所补足，请移步视频讲解：SnakeYaml反序列化过程与漏洞原理分析（CVE-2022-1471）

产品介绍

SnakeYaml是一个完整的YAML1.1规范Processor，支持UTF-8/UTF-16，支持Java对象的序列化/反序列化，支持所有YAML定义的类型。

漏洞概述

该漏洞源于程序在进行反序列化过程中未对用户输入内容做合法性验证，导致了恶意代码执行。

WebFlux Security 认证绕过（CVE-2023-34034）

产品介绍

Spring WebFlux 是 Spring Framework 5.0 中引入的新的响应式Web框架。与Spring MVC不同，它不需要Servlet API，是完全异步且非阻塞的，并且通过Reactor项目实现了Reactive Streams规范。Spring WebFlux 可用于创建基于事件循环执行模型的完全异步且非阻塞的应用程序。

漏洞概述

当WebFlux使用了Spring Security进行用户认证与鉴权时，若错误地使用了无前导”/“的路径通配符”**“，程序将因为WebFlux与Spring Security对其不同的解析模式差异导致可能的认证绕过。

在拿到设备固件或者镜像文件后，若要进行更进一步的漏洞挖掘，我们便需要找到与当前设备功能相关联的软件的位置与启动方式等信息。
一般来讲如果只知道软件的位置便进行分析可能措施很多关键的信息，如：程序运行时设置的环境变量以及一些配置信息的设置。

什么是SSO，为什么需要SSO

如果单从字面意思来理解，SSO表达了一种什么样的含义？我们知道，SSO的中文翻译为单点登录，顾名思义，即为单点，则表示在一个地方登录，登录的结果便是可以在多个地方被使用。在生活中常见的B/S场景下，我们有时需要通过用户名密码来声明我们对某个网站的某些资源具有访问权限，如果存在多个这样的网站，出于安全考虑我们可能就需要每一个网站均通过不同的用户名密码来声明对这些资源的访问权限，这就导致我们需要记录大量的密码以及反复完成登录操作，这个过程是繁琐且容易出错的。SSO的出现便能在一定程度上对这个缺陷进行弥补。

当然，如果仅仅是出于便利性的需要，SSO技术可能仍不是那么紧要。SSO技术使得对于某一类网站，如：同一公司旗下的一组网站，用户只需在某一个统一的入口完成一次登录操作便可同时访问这一组网站所有的受限资源，并能够完成权限控制、统一的会话管理、统一的资源分配等其他操作，这使得受限资源的保密性、完整性以及可用性有不同程度的提高。

SSO技术不仅仅是对用户认证产生了正向的影响，其解决的另一个问题是为不受信第三方获取资源提供了一整套的解决方案，即第三方获取资源的授权问题。

我们例举一个具体的SSO技术方案来进行说明，这里引用OAuth2.0 规范中关于为什么需要OAuth的说明。

传统的受限资源访问方案往往是通过使用资源所有者的访问凭据来获取资源的访问权限，这种通过明文凭据的访问方案往往用于声明用户对某个资源的所有权，而不能很好地向第三方进行资源分配。传统地方案在应用于第三方应用对受限资源的方式时往往会面临以下四个方面的问题：

• 第三方应用需要存储资源所有者的访问凭据，典型的方案就是用户名密码，这种方案显然是危险的，资源所有者不完全可以确认第三方应用地可信性；
• 受限资源通过密码访问，但密码体系本身存在各种各样的安全问题，如：泄露、强度问题等；
• 第三方应用通过密码获取到的访问权限太过广泛，资源所有者并没有很好的办法对这个范围进行限制，这往往需要配合其他的权限控制方案进行实现，如：RBAC，ABAC等；
• 资源所有者不能很好地对第三方应用对受限资源得访问进行控制，如：撤销权限，变更权限等操作，要做到这些往往需要通过修改密码以及变更角色权限的方式来实现。

正因为传统的密码体系对受限资源的访问控制在应用到第三方应用的过程中存在的这些缺陷使然，亟需一种灵活、便捷、有效、安全的第三方应用访问受限资源的解决方案。如OAuth，CAS，OIDC，SAML等协议框架正是为了解决这些问题而诞生。

整体来讲，这些框架的基本原理是一致的，区别在于它们如何看待认证与授权过程中涉及到的各种对象以及如何描述他们之间的关系再辅以不同的数据传输与处理方案，比如：OIDC便基本上就是是基于OAuth 2.0基础上实现的一个框架，SAML与OAuth 2.0的隐式模式在表现上最大的差别也就在数据结构上面，CAS与OAuth 2.0的隐式模式也很相似，至少展露给用户的部分是极其相似的，区别在于CAS能够处理用户认证与授权，OAuth 2.0只负责处理授权且在CAS中第三方应用携带ticket去请求资源时会根据用户进行权限校验，而OAuth 2.0的权限授予在申请Access Token时便已经完成了。

下面我们将以OAuth 2.0授权框架为主体对常见的SSO解决方案进行一个认识。