Spring WebFlux 是 Spring Framework 5.0 中引入的新的响应式Web框架。与Spring MVC不同，它不需要Servlet API，是完全异步且非阻塞的，并且通过Reactor项目实现了Reactive Streams规范。Spring WebFlux 可用于创建基于事件循环执行模型的完全异步且非阻塞的应用程序。
当WebFlux使用了Spring Security进行用户认证与鉴权时，若错误地使用了无前导”/“的路径通配符”**“，程序将因为WebFlux与Spring Security对其不同的解析模式差异导致可能的认证绕过。
在拿到设备固件或者镜像文件后，若要进行更进一步的漏洞挖掘，我们便需要找到与当前设备功能相关联的软件的位置与启动方式等信息。
一般来讲如果只知道软件的位置便进行分析可能措施很多关键的信息，如：程序运行时设置的环境变量以及一些配置信息的设置。
如果单从字面意思来理解，SSO表达了一种什么样的含义？我们知道，SSO的中文翻译为单点登录，顾名思义，即为单点，则表示在一个地方登录，登录的结果便是可以在多个地方被使用。在生活中常见的B/S场景下，我们有时需要通过用户名密码来声明我们对某个网站的某些资源具有访问权限，如果存在多个这样的网站，出于安全考虑我们可能就需要每一个网站均通过不同的用户名密码来声明对这些资源的访问权限，这就导致我们需要记录大量的密码以及反复完成登录操作，这个过程是繁琐且容易出错的。SSO的出现便能在一定程度上对这个缺陷进行弥补。
当然，如果仅仅是出于便利性的需要，SSO技术可能仍不是那么紧要。SSO技术使得对于某一类网站，如：同一公司旗下的一组网站，用户只需在某一个统一的入口完成一次登录操作便可同时访问这一组网站所有的受限资源，并能够完成权限控制、统一的会话管理、统一的资源分配等其他操作，这使得受限资源的保密性、完整性以及可用性有不同程度的提高。
SSO技术不仅仅是对用户认证产生了正向的影响，其解决的另一个问题是为不受信第三方获取资源提供了一整套的解决方案，即第三方获取资源的授权问题。
我们例举一个具体的SSO技术方案来进行说明，这里引用OAuth2.0 规范中关于为什么需要OAuth的说明。
传统的受限资源访问方案往往是通过使用资源所有者的访问凭据来获取资源的访问权限，这种通过明文凭据的访问方案往往用于声明用户对某个资源的所有权，而不能很好地向第三方进行资源分配。传统地方案在应用于第三方应用对受限资源的方式时往往会面临以下四个方面的问题：
正因为传统的密码体系对受限资源的访问控制在应用到第三方应用的过程中存在的这些缺陷使然，亟需一种灵活、便捷、有效、安全的第三方应用访问受限资源的解决方案。如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解决方案进行一个认识。