18、SpringSecurity实战:会话管理之防御固定会话攻击

前言

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

今天 壹哥 就带各位学习另一个很重要的功能,就是会话管理!

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

我们的项目上线后,如果黑客对我们的项目进行会话固定攻击怎么办?

如果用户登录后,长时间不进行任何操作,要不要让用户重新登录?

如果你的登录账号,在多台设备上同时登录该怎么实现和处理?

......

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

一. 会话的概念

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

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. 会话概念

会话(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已经为我们提供了完善的会话管理功能,包括会话固定攻击、会话超时检测以及会话并发控制。

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 之后,返回给前端的响应头是这样的:

*

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

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

*

二. 防御会话固定攻击

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处存在的资源。

*

2. 会话固定攻击

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

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

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

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

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

3. Spring Security的防御机制

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

*

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

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

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

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

4. 防御会话固定攻击的策略

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

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

*

  1. none: 该策略对会话不做任何变动,登录之后会沿用旧的session;
  2. newSession: 用户登录后会创建一个新的session;
  3. migrateSession: 默认策略,用户登录后创建一个新的session,并将旧session中的数据复制过来;
  4. changeSessionId: 表示 session 不变,不会创建新的session,但是会修改 sessionid,内部使用由Servlet容器提供的会话固定保护。

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

三. 代码实现

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

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执行了...");
    }

}

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();
    }

}

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

现在对于如何防御会话固定攻击,你学会了吗?

版权声明:本文不是「本站」原创文章,版权归原作者所有 | 原文地址: