16. 会话管理之防御固定会话攻击

PangHu大约 14 分钟

1. 前言

在前面几个章节中，带各位学习了如何实现基于数据库进行认证授权，如何给登录界面添加图形验证码，如何进行自动登录和注销登录，那么Spring Security的功能难道只有这些吗？肯定不是的，它的宝藏还有很多，我们还需要继续往下学习研究。

今天就带各位学习另一个很重要的功能，就是会话管理！

你可能会问：会话管理？干嘛的？有哪些效果？我们想一下：

我们的项目上线后，如果黑客对我们的项目进行会话固定攻击怎么办？
如果用户登录后，长时间不进行任何操作，要不要让用户重新登录？
如果你的登录账号，在多台设备上同时登录该怎么实现和处理？
……

这些问题会话管理都可以替我们解决！所以会话管理是不是很重要？别激动，接下来跟着一点点往下学吧！

2. 会话的概念

在实现会话管理之前，我们还是先来了解一下协议和会话的概念，连协议和会话都不知道是啥，咋个管理嘛。

2.1 http协议

因为我们现在的会话，基本上都是基于HTTP协议的，所以在讲解会话之前，我再带各位复习一下HTTP协议。

1.1 概念

HTTP: 超文本传输协议(HyperText Transfer Protocol)****，是一种用于分布式、协作式和超媒体信息系统的应用层协议，是一种在客户端(用户)和服务器端(网站)之间进行请求和响应的规范标准(TCP)，HTTP是万维网中数据通信的基础。

1.2 起源&发展

HTTP的发展是由蒂姆·伯纳斯-李于1989年在欧洲核子研究组织（CERN）所发起。HTTP的标准制定由万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（Internet Engineering Task Force，IETF）进行协调，最终发布了一系列的RFC。其中最著名的是1999年6月公布的 RFC 2616，定义了HTTP协议中现今广泛使用的一个版本——HTTP 1.1。

2014年12月，互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小组将HTTP/2标准提议递交至IESG进行讨论，于2015年2月17日被批准。HTTP/2标准于2015年5月以RFC 7540正式发表，取代HTTP 1.1成为HTTP的实现标准。

1.3 特点

基于请求-响应模式：
HTTP协议规定,请求是从客户端发出的,最后由服务器端接受并响应该请求。
无状态保存：
HTTP是一种不保存用户状态，即无状态(stateless)的协议。HTTP协议自身不对请求和响应之间的通信状态进行保存，也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。
HTTP协议的无状态，指的是每当有新的请求发送时，就会有对应的响应产生，HTTP协议本身并不保留之前一切的请求或响应的报文信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。可随着Web的不断发展，因无状态而导致业务处理变得棘手的情况也增多了。比如用户登录到一家购物网站，然后他跳转到该站的其他页面，也需要能继续保持登录状态。针对这个实例，网站为了能够掌握是谁发送的请求，需要保存用户的状态。HTTP/1.1虽然是无状态的协议，但为了实现期望的保持状态的功能，于是就引入了Cookie和Session技术。有了Cookie和Session，再用HTTP协议通信，就可以管理状态了。
无连接：
无连接的含义就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间，并可以提高并发性能，不用和每个用户建立长久的连接，请求一次响应一次，服务端和客户端就中断了。

2.2 会话概念

会话(Session)：在计算机中，尤其是在网络应用中，称为“会话控制”，它是以无状态的HTTP协议来维持用户状态的一种解决方案。

我们知道HTTP是无状态的协议，这意味着每次客户端检索网页时，都要单独打开一个服务器连接，因此服务器不会存储先前客户端请求的任何信息。

**HTTP 本身的无状态使得用户在与服务器的交互过程中，每个请求之间都没有关联性。这意味着用户的访问没有身份记录，站点也无法为用户提供个性化的服务，而Session的诞生解决了这个难题。**服务器通过与用户约定，发起每个请求时都要携带一个id类的信息，从而让不同请求之间有了关联，而id又可以很方便地绑定具体用户，所以我们可以把不同请求归类到同一用户。**基于这个方案，为了让用户每个请求都携带同一个id，在不妨碍体验的情况下，cookie是很好的载体。**当用户首次访问系统时，系统会为该用户生成一个sessionld，并添加到cookie中。在该用户的会话期内，每个请求都自动携带该cookie，因此系统可以很轻易地识别出这是来自哪个用户的请求。

**尽管 cookie 非常有用，但有时用户会在浏览器中禁用它，这么做可能是出于安全考虑，也可能是为了保护个人隐私。**在这种情况下，基于cookie实现的 sessionld 自然就无法正常使用了。因此，有些服务还支持用 URL重写 的方式来实现类似的体验，例如：http://yyg.com;jsessionid=xxx。URL 重写原本是为了兼容禁用cookie的浏览器而设计的，但也容易被黑客利用。黑客只需访问一次系统，将系统生成的sessionld提取并拼凑在URL上，然后将该URL发给一些取得信任的用户。只要用户在session有效期内通过此URL进行登录，该sessionld就会绑定到用户的身份，黑客便可以轻松享有同样的会话状态，完全不需要用户名和密码，这就是典型的会话固定攻击。

我们只需在两个浏览器中用同一个账号登录就会发现，默认情况下，我们的系统并未有任何会话并发的限制，也就是一个账户能在多处同时登录，这并不是一个好的策略。而Spring Security已经为我们提供了完善的会话管理功能，包括会话固定攻击、会话超时检测以及会话并发控制。

2.3 HttpSession

**HttpSession 是一个服务端的概念，服务端生成的 HttpSession 都会有一个对应的 sessionid，这个 sessionid 会通过 cookie 传递给前端，前端以后每次发送请求的时候，都会带上这个 sessionid 参数。**服务端看到这个 sessionid 就会把这个前端请求和服务端的某一个 HttpSession 对象对应起来，形成“会话”的感觉。

浏览器关闭并不会导致服务端的 HttpSession 失效，想让服务端的 HttpSession 失效，要么手动调用 HttpSession#invalidate()方法，要么等到 session 自动过期，要么重启服务端。

**但是为什么有的人会感觉浏览器关闭之后 session 就失效了呢？**这是因为浏览器关闭之后，保存在浏览器里边的 sessionid 就丢了(默认情况下)。所以当浏览器再次访问服务端的时候，服务端会给浏览器重新分配一个 sessionid，这个 sessionid 和之前的 HttpSession 对应不上，所以用户就会感觉 session 失效。

但是我们也可以通过手动配置，让浏览器重启之后 sessionid 不丢失，但是这样会带来安全隐患，所以一般不建议。

以 Spring Boot 为例，服务端生成 sessionid 之后，返回给前端的响应头是这样的：

Spring Security系列教程18--会话管理之防御固定会话攻击_spring

在服务端的响应头中有一个 Set-Cookie 字段，该字段指示浏览器更新 sessionid，同时大家注意还有一个 HttpOnly 属性，这个表示通过 JS 脚本无法读取到 Cookie 信息，这样能有效的防止 XSS 攻击。

下一次在浏览器中发送对某个接口的请求时候，就会自觉的携带上这个 jsessionid 了：

Spring Security系列教程18--会话管理之防御固定会话攻击_spring_02

3. 防御会话固定攻击

3.1 URL重写

在上面的小节中，我给大家提到了URL重写的概念，那URL重新到底是怎么回事呢？

URL重写(URL rewriting)，其实就是先获得一个进入的 A URL，然后把 A URL 重新写成网站可以处理的另一个 B URL 的过程。

举个例子，如果通过浏览器进来的 A URL是“/show.do?ID=1”，那么它可以被重写成“/show/1.do” 这样的URL，这样的网址可以更好的被网站所阅读。

另外如果浏览器不支持Cookie或用户阻止了所有的Cookie，我们可以把SessionID附加在HTML页面中所有的URL后面，比如http://yyg.com;jsessionid=xxx，然后把这些页面作为响应发送给客户。这样，当用户请求URL时，SessionID会被自动作为请求行的一部分，而不是作为头行发送回服务器，这也是URL重写。

URL重写是一种位于服务器端的操作，URL重写不需要往返服务器。重写的URL不会被返回客户端，也不会出现在浏览器地址栏。比如/resource 重写到 /different-resource 时，客户端会请求 /resource ，而服务器会在内部提取 /different-resource 处的资源。客户端能够检索到已重写的URL处的资源，但是客户端发出请求并收到响应时，并不会知道已重写URL处存在的资源。

Spring Security系列教程18--会话管理之防御固定会话攻击_服务端_03

3.2 会话固定攻击

我们在上面讲了什么是URL重写，知道 URL重写原本是为了兼容禁用cookie的浏览器而设计的，但是很多技术都有两面性，URL重写其实存在被黑客利用的风险，其中黑客较为常用的一种攻击手段就是会话固定攻击****(session fixation attack)。

一般情况，只要我们不关闭浏览器，并且服务端的 HttpSession 也没有过期，那么维系服务端和浏览器的 sessionid 是不会发生变化的。而会话固定攻击，则是利用这一机制，借助受害者用相同的会话 ID 获取认证和授权来进行攻击。黑客只需访问一次系统，将系统生成的sessionld提取并拼凑在URL上，然后将该URL发给一些取得信任的用户。只要用户在session有效期内通过此URL进行登录，该sessionld就会绑定到用户的身份上，黑客便可以轻松享有同样的会话状态，完全不需要用户名和密码。这种利用会话 ID 劫持受害者的会话以成功冒充受害者的攻击方式，就是所谓的会话固定攻击。

一般来说，会话固定攻击的流程是这样，以淘宝为例：

攻击者自己可以正常访问淘宝网站，在访问的过程中，淘宝网站给攻击者分配了一个 sessionid；
攻击者利用自己拿到的 sessionid 构造一个淘宝网站的链接，并把该链接发送给受害者；
受害者使用该链接登录淘宝网站(该链接中含有 sessionid)，登录成功后，一个合法的会话就成功建立;
攻击者利用手里的 sessionid 冒充受害者。

在这个过程中，如果淘宝网站支持 URL 重写，那么攻击还会变得更加容易。

3.3 Spring Security的防御机制

其实在Spring Security中，即便我们不做什么特别的配置，也不用担心会被会话固定攻击。**这是因为Spring Security中自带的HTTP防火墙机制会帮助我们拦截不合法的URL，**当我们视图访问带有sessionId的URL时，实际上会被重定向到类似于下图中：

Spring Security系列教程18--会话管理之防御固定会话攻击_HTTP_04

Spring Security 之所以可以实现上述防御效果，主要是从以下三个方面来完成：

**「首先」**会利用StrictHttpFirewall防火墙，如果发现请求地址中带有 “;”，则该请求会被直接拒绝；

**「然后」**就是响应的 Set-Cookie 字段中有 HttpOnly 属性，这种方式会避免通过 XSS 攻击来获取 Cookie 中的会话信息，进而达成会话固定攻击。

**「最后」**则是让 sessionid 改变一下。既然问题是由于 sessionid 不变导致的，那我们就让 sessionid 变一下，利用Spring Security提供的防御会话固定攻击的策略即可实现。

3.4 防御会话固定攻击的策略

我在上面分析了防御的实现机制，其中第三步就是更改sessionid，这种策略是抓住了会话固定攻击的根源，即在于会话的 sessionid 不变！如果用户在未登录时拿到的是一个 sessionid，登录之后服务端给用户重新换了一个新的 sessionid，就可以防止会话固定攻击了。

而在Spring Security中，防御会话固定攻击的方法则非常简单，我们只需要在用户登录之后重新生成新的session即可。在我们编写的SecurityConfig类继承WebSecurityConfigurerAdapter时，Spring Security默认已经启用了该配置，主要是利用SessionManagement这个配置器来实现，并且提供了防御会话固定攻击的4种策略。

Spring Security系列教程18--会话管理之防御固定会话攻击_spring_05

none: 该策略对会话不做任何变动，登录之后会沿用旧的session;
newSession:
migrateSession:
changeSessionId: 表示 session 不变，不会创建新的session，但是会修改 sessionid，内部使用由Servlet容器提供的会话固定保护。

默认的防御策略是 migrateSession ，在用户匿名访问的时候是一个 sessionid，当用户成功登录之后，又是另外一个 sessionid，这样就可以有效避免会话固定攻击。

4. 代码实现

上面讲解了这么多的底层原理，接下来壹哥就带各位进行代码的具体实现，创建项目的过程，请参考我之前的案例，具体过程这里就不再详细展示了。

4.1 创建测试接口

为了方便后面的测试，这里还是创建几个测试接口。

@RestController
public class UserController {

    @GetMapping("/user/hello")
    public String helloUser() {

        return "hello, user";
    }

    @GetMapping("/admin/hello")
    public String helloAdmin() {

        return "hello, admin";
    }

    @GetMapping("/app/hello")
    public String helloApp() {

        return "hello, app";
    }
    
    @RequestMapping("/logout")
    public void logout(HttpSession session){
        session.invalidate();
        System.out.println("logout执行了...");
    }

}

4.2 配置会话策略

定义一个SecurityConfig类，在这里配置会话生成策略，主要是在sessionManagement中进行配置。

/**
 * 会话管理设置
 */
@EnableWebSecurity(debug = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/admin/**")
                .hasRole("ADMIN")
                .antMatchers("/user/**")
                .hasRole("USER")
                .antMatchers("/app/**")
                .permitAll()
                .anyRequest()
                .authenticated()
                .and()
                .csrf()
                .disable()
                .formLogin()
                .permitAll()
                .and()
                .logout()
                .logoutUrl("/logout")
                //注销成功，重定向到该路径下
                .logoutSuccessUrl("/login")
                //使得session失效
                .invalidateHttpSession(true)
                //清除认证信息
                .clearAuthentication(true)
                .and()
                //进行会话管理
                .sessionManagement()
                .sessionFixation()
                .migrateSession();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {

        return NoOpPasswordEncoder.getInstance();
    }

}

这样，我们就实现了对会话固定攻击的防御，其实相关代码也就三四行，是不是很简单？具体的测试效果，请按之前的方式启动项目进行测试即可，这里我就不再截图展示了。