结合Spring-Security进行web应用会话安全管理

42次阅读

共计 1796 个字符,预计需要花费 5 分钟才能阅读完成。

在本文中,将为大家说明如何结合 Spring Security 和 Spring Session 管理 web 应用的会话。

一、Spring Security 创建使用 session 的方法

Spring Security 提供 4 种方式精确的控制会话的创建:

  • always:如果当前请求没有 session 存在,Spring Security 创建一个 session。
  • ifRequired(默认):Spring Security 在需要时才创建 session
  • never:Spring Security 将永远不会主动创建 session,但是如果 session 已经存在,它将使用该 session
  • stateless:Spring Security 不会创建或使用任何 session。适合于接口型的无状态应用,该方式节省资源。

在 Spring Security 配置中加入 session 创建的策略。继承 WebSecurityConfigurerAdapter,重写 configure(HttpSecurity http) 方法

@Override
protected void configure(HttpSecurity http) throws Exception {http.sessionManagement()
        .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
}

重要的是:该配置只能控制 Spring Security 如何创建与使用 session,而不是控制整个应用程序。如果我们不明确指定,Spring Security 可能不会创建 session,但是我们的应用程序可能会创建 session(一般 spring 应用的 session 管理交由 Spring Session 进行)!

二、会话超时管理

2.1 会话超时处理

会话超时之后,我们通常希望应用跳转到一个指定的 URL,显示会话超时信息。可以使用如下的配置的代码实现。

    http.sessionManagement()
          .expiredUrl("/sessionExpired.html")   // 超时 session
          .invalidSessionUrl("/invalidSession.html");    // 非法 session

2.2. 会话超时时间配置

在 Spring boot 应用中有两种设置会话超时时间的方式,Spring Security 对这两种方式完全兼容,即:当会话超时之后用户需要重新登录才能访问应用:

  • server.servlet.session.timeout=15m
  • spring.session.timeout = 15m

第一种方式是 springBoot 应用自带的 session 超时配置,第二种方式是我们使用 Spring Session 之后,提供的 session 超时配置。第二种方式的优先级更高。

三、Spring Security 的会话固化保护

session-fixation-protection 即 session 的固化保护功能,该功能的目的是一定程度上防止非法用户窃取用户 session 及 cookies 信息,进而模拟 session 的行为。
默认情况下,Spring Security 启用了 migrationSession 保护方式。即对于同一个 cookies 的 SESSIONID 用户,每次登录验证将创建一个新的 HTTP 会话,旧的 HTTP 会话将无效,并且旧会话的属性将被复制。

    http.sessionManagement() .sessionFixation().migrateSession()

如果这不是您需要的方式,则可以使用其他两个选项:

  • 设置为“none”时,原始会话不会无效
  • 设置“newSession”后,将创建一个干净的会话,而不会复制旧会话中的任何属性

四、Cookie 的安全

熟悉 Session 实现原理的朋友一定都知道,提高 Cookies 的安全性,实际上就是提高 session 的安全性。在 Spring Boot 中可以通过配置方式来实现:

server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true
  • httpOnly:如果为 true,则浏览器脚本将无法访问 cookie
  • secure:如果为 true,则仅通过 HTTPS 连接发送 cookie,HTTP 无法携带 cookie。

正文完
 0