皮皮网

1.springboot异常处理机制？
2.SpringSecurity Oauth2Authentication对象使用
3.Spring Boot 之 Filter
4.JBoss反序列化漏洞（CVE-2017-12149）

springboot异常处理机制？

       springboot的源码四种拦截机制

       当我们在某些情况下需要对客户端发送来的请求进行拦截分析的时候，就需要用到拦截机制，源码比如，源码我们需要对一个请求进行计时，源码又或者需要知道当前请求需要进入哪个控制器，源码哪一个方法，源码万挂作坊源码该请求的源码参数是什么等等场景下都需要用到拦截机制来处理。下面，源码我们来讲解一下SpringBoot的源码几种拦截方式以及如何使用它们来处理一定的场景需求。

       过滤器（filter）

       拦截器（interceptor）

       全局异常处理器（ControllerAdvice）

       切片（aspect）

       如上图所示，源码当一个请求发送来的源码时候，filter在最外层，源码也最先拦截到请求，源码接下来就是源码interceptor，依次是源码ControllerAdvice（处理controller层异常）、aspect，最后才进入controller层去处理请求。相应的，当controller内部发生错误，加油软件源码抛出异常的时候，aspect最先接收到该异常，如果不对抛出的异常继续处理继续往外抛的话依次会抛到ControllerAdvice、interceptor、filter。

       请求的顺序：从先到后经过FilterInterceptorControllerAdviceAspect–Controller。

       过滤器（filter）可以拦截发送请求的状态码以及信息，拦截器（interceptor）除了可以拦截filter可以拦截的，还可以得到当前请求进入了哪一个controller，智慧车站 源码以及映射到哪一个方法，切片（aspect），它具有上面的所有功能外，还可以得到当前请求的参数的值。全局异常处理器（ControllerAdvice）只是用于处理controller层抛出的异常

       Springboot的Filter,HandlerInterceptor,Aspect与异常处理

       不知你在Springboot应用开发中有没有遇到过这样的情况,mon的项目，要暴露出去给依赖的项目使用,在文件src\main\resources\META-INF\spring.factories中添加最后一行

       可以被全局异常捕捉并处理成json

       访问接口，如果无数据，则输出异常信息

       { "data":"packageid为：BZ-的indexpackage无记录","flag":false,"code":null,"msg":"未查到数据"}

       全局异常类可以用@RestControllerAdvice，替代@ControllerAdvice，gitlab加密源码因为这里返回的主要是json格式，这样可以少写一个@ResponseBody。

springboot怎么取消同意的异常处理

       使用ErrorController类来实现。

       系统默认的错误处理类为BasicErrorController，将会显示如上的错误页面。

       这里编写一个自己的错误处理类，上面默认的处理类将不会起作用。

       getErrorPath()返回的路径服务器将会重定向到该路径对应的处理类，本例中为error方法。班级打卡源码

SpringSecurity Oauth2Authentication对象使用

        在调用资源服务器的过程中，我们会将申请的token 作为header值进行传递，携带调用者的身份信息。但是资源服务器是如何通过token对调用者的身份进行判断的呢？

        Security中有一个Filter实现了对token信息的转换，将token值转换成了调用者的用户信息。该filter就是 Oauth2AuthenticationProcessingFilter

        一、查看源码

        查看Oauth2AuthenticationProcessingFilter的doFilter方法

        通过查看Oauth2AuthenticationProcessingFilter的dofilter方法，重点有两点

        （1）将request中的token提取出来封装成Authentication对象

        （2）将Authentication交给authenticationManager进行鉴权处理

        下面我们重点看下这两处的处理。

        二、token到Authentication对象转换实现

        Authentication authentication = tokenExtractor.extract(request);

        tokenExtractor在Oauth2AuthencationProcessingFilter中的默认实现是BearerTokenExtractor，我们查看BearerTokenExtractor的extract()方法。

        三、Authentication对象的鉴权

        Authentication authResult = authenticationManager.authenticate(authentication);

        此处的authenticationManager的实现类是Oauth2AuthenticationManager，而不是我们之前一直提到的ProvicerManager。我们看下Oauth2AuthenticationManager中的authenticate()方法。

        RemoteTokenService 的 loadAuthentication() 方法

        用户认证转换类

        * 接口层注入的 OAuth2Authentication对象中的 principal属性即在该类的extractAuthentication() 方法中实现的。

        * security默认使用的是 DefaultAccessTokenConverter类中的extractAuthentication()方法中使用。

        * 通过继承UserAuthenticationConverter该类，实现其中的extractAuthentication()方法来满足我们自己构造 principal属性的需求。

        * 在ResourceConfig类中，继续使用DefaultAccessTokenConverter,但是类中的UserAuthenticationConverter我们里换成我们自己的CustomUserAuthenticationConverter实现类。

        *

        * 我们构造的principal属性是map类，里面包含phone和userId两个字段。

Spring Boot 之 Filter

        Filter是request/response执行过滤任务的对象，资源可以是一个servlet或者静态资源。Filter在 doFilter 方法中执行过滤逻辑。每个Filter都有一个FilterConfig对象，可以从FilterConfig对象获取初始化参数和ServletContext引用。

        Filter工作在客户端和Servlet之间，可以对客户端request以及服务器的response进行处理，基于此Filter可以用于实现以下功能：

        定义一个Filter需要 javax.servlet.Filter 接口， Filter 有如下三个方法：

        下面定义一个简单的Filter，在 init() 方法中初始化Filter的名字，在 doFilter 方法中简单的记录Filter被调用， destroy() 简单的记录方法被调用。

        FirstFilter：

        在完成Filter的创建后，还需要将Filter注册到Web容器（添加到Filter chain）才能对request/response进行过滤。在Spring Boot中注册Filter非常简单，下面是一个简单注册Filter的样例：

        启动Spring Boot并调用一个测试接口，测试接口可从 这里 获取。

        应用的输出如下：

        从输出中可以看出Filter完成了初始化，Filter的名字是“first filter”。

        如果定义了多个Filter，并期望request/response可以按照设定的顺序依次经过各个Filter（例如：request需要先经过鉴权Filter，鉴权通过后再进入参数校验Filter等），这种情况如何保证Filter的执行顺序呢？在注册Filter的时候可以给每个Filter设置一个数字表示的order，值越小Filter在chain中的位置越靠前。为了严重Filter的执行顺序，我们定义第二个Filter：SecondFilter，源码可从 这里 获取。然后将两个Filter添加到Web容器中：

        启动Spring Boot并调用一个测试接口，测试接口可从 这里 获取。

        应用的输出如下：

        request依次经过first filter -> second filter，response依次经过second filter - > first filter，Filter的执行顺序满足我们的期望。

        通过上面学习的知识，我们实现一个鉴权的Filter。假设客户端访问资源时需要在请求的header中携带两个参数：user和password（生成环境携带账号密码是十分危险的，应该考虑基于Token的鉴权），如果有一个参数没有携带则返回客户端错误的请求（ Bad Request），如果user和password不匹配或系统不存在用户则返回无权访问 （ Forbidden）。客户端每成功一次，系统都会记录用户的访问次数。

        Filter的实现如下：

        过滤步骤：

        完整的源码可以从 这里 获取。

JBoss反序列化漏洞（CVE--）

       JBoss存在一个严重的反序列化漏洞（CVE--），该漏洞源于HttpInvoker组件的ReadOnlyAccessFilter过滤器中的doFilter方法，该方法未经安全检查直接处理客户端提交的序列化数据，可能导致恶意用户通过精心构造的数据执行任意代码。最新发现，JBossAS 6.x版本也受此漏洞影响，攻击者无需用户验证即可获得服务器控制权。为防止潜在风险，强烈推荐尽快将系统升级至JBossAS 7版本。

       Java序列化和反序列化是Java编程中的常见操作，但若处理不当，会成为安全风险。漏洞具体表现为在HttpInvoker的源码中，doFilter函数对http中的数据直接调用readobject()进行反序列化操作。

       漏洞利用分为两个步骤：首先，通过浏览器访问目标服务器的默认页面，然后访问特定的反序列化漏洞页面，服务器会尝试解析用户提交的POST内容进行反序列化操作。攻击者可以借助ysoserial工具生成恶意序列化数据，构造Payload，利用Runtime.getRuntime().exec()的特性执行Shell命令，如bash反弹至本地指定端口。

       在利用过程中，需要注意对命令进行编码以避免被分割，同时可能利用${ IFS}字符进行绕过。实验中，通过CommonsCollections1库生成的POC文件发送至nc监听的端口，接收并执行反弹回来的Shell命令。然而，此类操作仅限于安全研究，切勿对未经授权的网站进行恶意操作。

       为了系统安全，建议对受影响的系统进行紧急修复，可以通过访问官方提供的修复文档来进行升级和配置更改。