[Spring Boot] Spring Security Basic - 기본 API 및 Filter 이해편

이 글은 인프런 -  Spring Boot 기반으로 개발하는 Spring Security를 학습하면서 정리한 내용 입니다.

 

 

GIT HUB 주소 : https://github.com/junyharang-coding-study/spring-security

 

 

 

 

🗂 목차

● [Spring Boot] Spring Security Basic - 기본 API 및 Filter 이해편 
● [Stpring Boot] Spring Security Basic - Spring Security 주요 아키텍처 이해편
● [Stpring Boot] Spring Security 실전 프로젝트 - 인증 프로세스 Form 인증 구현(1)   
● [Stpring Boot] Spring Security 실전 프로젝트 - 인증 프로세스 Form 인증 구현(2)
● [Stpring Boot] Spring Security 실전 프로젝트 - 인증 프로세스 Ajax 인증 구현

 

 

 

 

 

🚀 Spring Security 이론

    🔽  준비하기

        📦 개발 환경

• JDK 1.8 이상
• Maven
• DB - H2 DB
• IDE - InteliJ

        📦 프로젝트 구성 및 의존성 추가

최초 Project 구성 시 의존성은 Spring Boot Web만 추가 하였습니다.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.0</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.example</groupId>
    <artifactId>security</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>junyharang-spring-secutiry</name>
    <description>junyharang-spring-secutiry</description>
    <properties>
        <java.version>1.8</java.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!-- Spring Security Dependency 추가 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

        <!-- Slf4J Dependency 추가 -->
        <!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <scope>provided</scope>
        </dependency>


        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

pom.xml

그런 뒤 위와 같이 Spring Security Dependency와 Log 출력을 위한 Slf4J Dependency를 추가해 주었어요!

    🔽  Spring Security Basic API & Filter 이해하기

        📦 인증 API - Spring Security 의존성 추가 시 일어나는 일

Spring Boot Server를 기동시키면 Spring Security의 초기화 작업 및 보안 설정이 이루어지게 되요.
별도의 설정, 구현을 하지 않아도 기본적인 웹 보안 기능이 작동하게 된답니다.

• 모든 요청은 인증이 되어야 자원 접근 가능
• 인증 방식은 Form Login 방식, Http Basic Login 방식 제공
• 기본 Login Page 제공
• 기본 계정 한 개 제공 - username(ID) : user / password : 랜덤 문자열 (Spring Boot 기동 시 아래와 같이 표시)

Spring Security 기본 Password

하지만, Spring Security 초기에는 아래와 같은 문제점이 있는 것이에요.

• 계정 추가
• Data Base 추가 및 연동
• 기본 보안 기능 외 세부적 추가적 보안 기능 구현 필요

 

 

 

 

        📦 인증 API - 이용자 정의 보안 기능 구현

최초 Spring Security를 이용하기 위해 아래와 같은 방식을 이용해서 설정을 해 주어야 해요.

1. 인증 API 제공 기능
• http.formLogin()
• http.logout()
• http.csrf()
• http.httpBasic()
• http.SessionManagement()
• http.RememberMe()
• http.ExceptionHandling()
• http.addFilter()


2. 인가 API 제공 기능
• http.authorizeRequests()
• .antMatchers("/{URI}")
• .hasRole({계정 권한명})
• .permitAll()
• authenticated()
• fullyAuthentication()
• access(hasRole({계정 권한명})
• . denyAll()

 

 

 

 

        📦 인증 API - SecurityConfig 구현

 

package com.junyharang.spring.security.config;

import lombok.extern.slf4j.Slf4j;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.AuthenticationException;
import org.springframework.security.web.authentication.AuthenticationFailureHandler;
import org.springframework.security.web.authentication.AuthenticationSuccessHandler;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

/**
 * Spring Security Config Class
 * <b>History:</b>
 * @author 주니하랑
 * @version 1.0.0, 2022.06.14 최초 작성
 */

@Slf4j
@Configuration @EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    /**
     * Spring Security 설정 Method
     * @param http - 세부 보안 기능 설정 API 제공 객체
     */

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                    .authorizeRequests()                                    // Client가 http 방식으로 요청을 보내면
                    .anyRequest().authenticated()                           // 모든 요청에 대해 인증 검사를 수행한다.
                .and()                                                      // 그리고,
                    .formLogin()                                            // 인증 방식은 formLogin 방식
    } // configure(HttpSecurity http) 끝
} // class 끝

최초 위와 같이 설정을 해 주었고, Client가 http 방식으로 요청을 보내면 모든 요청에 대해 인증 확인 처리를 하고, 인증 방식을 FormLogin 방식으로 처리하도록 설정하였어요.

        📦 인증 API - Form 인증

Form 인증 방식의 Login Logic은 아래와 같이 처리가 되요.

http.formLogin()	// Form Login 인증 기능 On

 

 @Override
    protected void configure(HttpSecurity http) throws Exception {
    
    http.formLogin()
    	.loginPage("/signin")					// 개발자 정의 Login Page URI
        .defaultSuccessUrl("/home")				// Login 성공 뒤 이동하게 될 Page URI
        .failureUrl("/login.html?error=true")	// Login 실패 뒤 이동하게 될 Page URI
        .usernameParameter("username")			// 이용자 ID 변수명 설정
        .passwordParameter("password")			// 이용자 비밀번호 변수명 설정
        .loginProcessingUrl("/signin")			// Login Form Action URI
        .successHandler(loginSuccessHandler())	// Login 성공 뒤 호출 될 Handler
        .failureHandler(loginFailureHandler())	// Login 실패 뒤 호출 될 Handler
        
}

 

 

        📦 인증 API - UsernamePasswordAuthenticationFilter

 

UsernamePasswordAuthenticationFilter 동작 방식

 

 

 

 

        📦 인증 API - Logout

 

이용자가 Logout 요청을 보내게 되면 Spring Security 내에서는 어떤 일이 발생하게 될까요?
위의 그림에서 나와 있 듯 Session을 무효화하고, 인증 토큰(이용자가 인증을 했을 때, 생성된 인증 객체)을 삭제하게 됩니다. 이 때, 인증 토큰이 저장되어 있는 객체인 Security Context를 함께 삭제하게 되요.

그리고, 삭제해야 할 쿠키 정보가 있다면 해당 쿠키를 삭제하고, 다시 Login Page로 이동할 수 있게 해 주는 것이에요.

Spring Secutiry Config Class에서 http.logout()을 설정하게 되면 Logout 기능을 활성화 할 수 있어요.

 

protected void configure(HttpSecurity http) throws Exception {
	http.logout()										// Logout 처리
    	.logoutUrl("/logout")							// Logout 처리 URI
        .logoutSuccessUrl("/signin")					// Logout 성공 뒤 이동할 Page URI
        .deleteCookies(" JSEESIONID", " remember-me " ) // Logout 뒤 Cookie 삭제 (발급 된 Cookie 명 기재)
        .addLogoutHandler(logoutHandler())				// Logout Handler(Logout 이 후 하고자 하는 작업이 있다면 Custom하게 처리하기 위해 호출)
        .logoutSuccessHandler(logoutSuccessHandler())	// Logout 성공 뒤 Handler
}

참고로 Spring Security는 기본적으로 Logout을 처리할 때, Post 방식으로 처리를 한답니다.
Get 방식으로도 처리가 가능하지만, 기본적으로는 Post 방식으로 처리한다는 것을 알아두면 좋을 거 같아요.

Logout 처리

 

최초 위와 같이 Login 정보를 입력하고, Sign in 단추를 눌러주었어요.

Logout 처리를 위해 URI에 logout을 입력해 줍니다.

이 Page는 Spring Security가 기본적으로 제공하는 Page입니다.

개발자 도구를 통해 확인 해보면 Post 방식을 이용해서 logout 처리를 하는 것을 확인할 수 있는 것이에요.

Debug Mode로 확인 해 보면 Logout Button을 눌렀을 때, Session을 무효화 하는 부분에 진입하는 것을 확인할 수 있어요.

그런 뒤 Success Handler를 통해 다시 Sign in Page로 이동 시키는 것을 확인 할 수 있어요.

        📦 인증 API - LogoutFilter

이번에는 Logout Filter에 대해서 공부해 볼게요.

최초 이용자가 Logout을 요청(Post 방식)하게 되면 LogoutFilter가 받아서 처리하게 되요.

그러면 AntPathRequestMatcher가 요청 URI가 Logout 처리를 위한 URI인지 검사를 하게 되요.
만약 URI가 일치하지 않는다면 doFilter가 받아 다음 Filter로 이동하게 처리를 하고, 일치하게 되면
Authentication이 호출되어 SecurityContext (현재 이용자의 인증 정보를 담고 있는 객체)로 부터 인증 객체를 꺼내 받아 SecutiryContextLogoutHandler 즉, LogoutHandler에게 전달을 하게 되는 것이에요. 해당 Handler는 Session을 무효화하고, Cookie를 삭제하고, SecurityContextHolder.clearContext()에서 SecutiryContext 객체를 삭제하게 되는 것이에요. 그리고, 인증 객체도 null로 초기화 하는 것이에요.

만약 Post가 아닌 Get 방식으로 처리하고자 할 때도 SecurityContextLogoutHandler를 통해 처리를 할 수 있어요.

위의 작업이 완료가 되면 LogoutFilter는 SimpleUrlLogoutSuccessHandler를 호출해서 Sign in Page로 이동하게 처리를 할 수 있는 것이에요.

        📦 인증 API - Remember Me 인증

위와 같이 Remember Me 기능을 이용하게 되면 어떤일이 벌어질까요?

위의 기능은 Session이 만료되고, 웹 브라우저가 종료된 뒤에도 Application이 이용자를 기억하게 하는 기능이에요.
즉, 자동 Login 기능과 유사한 기능이라고 보면 되는 것이에요.

Remember-Me Cookie에 대한 Http Request를 확인하고, Token 기반 인증을 이용해 유효성 검사를 하고, Token이 검증괴게 되면 이용자는 Login을 할 수 있어요.

이용자의 Life Cycle은 아래와 같아요.

• 인증 성공 ( Remember-Me Cookie 설정)
• 인증 실패 ( Cookie 존재 시 Cookie 무효화)
• Logout ( Cookie 존재 시 Cookie 무효화)

Spring Secutiry Config Class에서 http.rememberMe()을 설정하게 되면 RememberMe 기능을 활성화할 수 있어요.

protected void configure(HttpSecurity http) throws Exception {
	http.rememberMe()
    	.rememberMeParameter("remember")	// 기본 매개변수 명은 remember-me
        .tokenValiditySeconds(3600)			// 기본값은 14일
        .alwaysRemember(true)				// Remember Me 기능이 활성화 되지 않아도 항상 실행 false를 권고
        .userDetailsService(userDetailsService)
}

최초 userDetailsService를 이용하기 위해 @RequiredArgsConstructor Lombok을 이용하여 final member 변수 UserDetailsService를 주입해 주었어요.

강의에서는 @Autowired를 통해 UserDetailsService를 주입하는데, Member 변수에 대한 삽입은 권고 사항이 아니므로 위와 같이 생성자 주입을 할 수 있게 변경 해 주었어요.

그런 뒤 Logout 설정 밑에 위와 같이 Remember Me 관련 설정을 해 주었어요.

Server를 재 구동하고, 다시 Root Page에 접근을 하면 Login Page로 이동하게 되고, 위와 같이 Remember Me에 관련한 Check Box가 생긴걸 확인할 수 있어요.

Remember Me Check Box에 Check를 하고 Login을 해 볼게요.

이렇게 인증이 되었어요.
인증이 되었다는 것은 Spring Security에서 이용자 Session이 만들어 졌다는 것이고, 해당 Session이 성공한 인증 객체를 담고 있는 것이에요.

개발자 도구를 통해 Cookie를 확인해 보니 위와 같이 값이 담겨 있는 것을 확인할 수 있어요.

해당 Page를 종료했다가 다시 접근을 하게 되면 바로 접속이 가능한 걸 확인할 수 있어요.

이는 위에 개발자 도구에서 보았듯이 Client가 Server가 준 JSessionID 값을 가지고 있었고, 이를 다시 진입할 때, Server에게 넘겨 인증을 통과했기 때문이에요.

EditThisCookie

그럼 크롬 확장 프로그램 중 EditThisCookie를 통해 Cookie를 확인해 볼게요.

이렇게 Cookie 정보를 개발자 도구 보다 더 간편하게 확인할 수 있어요.

이 곳에서 휴지통 모양을 눌러 Cookie를 한번 날려 볼게요!

어떤 일이 발생할까요?

Remember-Me는 제외하고, JSessionID를 지우고 나서 다시 접속을 하게 되면 마찬가지로 인증 절차 없이 접속을 하는 것을 확인할 수 있어요. 

다시 Cookie를 확인해보면 JSessionID도 다시 받아온 것을 확인할 수 있습니다.



이번에는 둘 다 한번 지워볼게요.

모든 Cookie를 다 날렸고, 새로고침을 해 볼게요.

그럼 Server는 '처음 뵙겠습니다!'를 하면서 누구인지를 물어보는 것이에요.

        📦 인증 API - RememberMeAuthenticationFilter

 

최초 RememberMeAuthenticationFilter가 이용자의 요청을 받게 되면 어떤 일이 일어날까요?

첫번째는 바로 Authentication 즉, 인증 객체가 Null일 경우가 있는데, 인증 객체는 위에서도 언급했지만, SecurityContext에 저장이 되어 있어요. 즉, 이용자가 인증을 하게 되면 인증 객체를 생성하게 되고, 이 인증 객체를 SecurityContext에 담게 되는 것이에요. 그렇기 때문에 이용자가 인증을 하였다는 것은 바로 Authentication이 Null이 아니라는 것이에요.

만약 이용자의 Session이 만료되었거나, Session이 어떠한 이유로 끊겨져서 더 이상 Session 안에서 SecurityContext를 찾지 못하고, SecurityContext가 존재하지 않으므로, SecurityContext 안에 Authentication 객체도 없는 경우가 바로 첫번째 경우에요. 이 때 바로 RememberMeAuthenticationFilter가 동작하게 되는 것이에요.

만약 Authentication이 Null이 아니라면 RememberMeAuthenticationFilter는 동작하지 않는데, 그 이유는 이미 인증 객체가 있다는 이야기이기 때문에 다시 인증을 받을 필요가 없기 때문이에요.

즉, RememberMeAuthenticationFilter가 동작했다는 것은 인증 처리를 위해 동작한다고 보면 되는 것이에요.

두번째는 이용자가 Form 인증을 받을 당시 Remember Me 기능을 활성화한 뒤 인증을 한 뒤 Server로 부터 Remember Me Cookie를 발급 받은 경우에 동작하는 것이에요.

위의 경우 이용자가 브라우저를 종료했거나 했을 시 이용자의 Session은 무효화되나, 다시 Server에 접근할 때, Request Header에 Remember Me Cookie 값을 가지고, 접근하게 되면 해당 Cookie를 이용하여 인증을 시도하게 된답니다.

RememberMeAuthenticationFilter가 동작하게 되면 RememberMeServies가 호출 되게 되는데, 이 친구는 두 개의 구현체를 보유하고 있는 친구에요. 바로 TokenBasedRememberMeServices와 PersistentTokenBasedRememberMeServices에요. 이 두 친구가 바로 Remember Me 인증 처리를 하는 친구들이에요.

TokenBasedRememberMeServices는 Memory에 저장된 Token과 이용자가 요청을 보냈을 시 보낸 Cookie안에 있는 Token과 비교해서  인증처리를 하는 친구에요. 

기본적으로 이 Token은 14일이라는 기간 만료가 정해져 있어요.

PersistentTokenBasedRememberMeServices는 Persistent 즉, 영구적으로 이용하는 방식인데, DB에 Token값을 저장하고,  이용자가 요청을 보냈을 시 보낸 Cookie안에 있는 Token과 비교해서  인증처리를 하는 친구에요. 

이제 Remember Me Token Cookie를 추출하게 되고, Token이 존재하지 않으면 doFilter를 통해 다음 Filter가 동작하게 처리가 되고, Token이 있다면 Remember Me Token은 나름의 규칙들이 있는데, 이 규칙들이 잘 지켜져서 왔는지는 확인하게 되요. 만약 아니라면 Exception이 터지게 되고, 잘 지켜져서 왔다면 저장되어 있는 Token과 이용자가 보낸 Token이 일치하는지 확인을 합니다.

일치하지 않으면 역시 Exception이 터지게 되고, 일치하면 해당 이용자 계정이 DB에 존재하는지 확인을 하고, 존재한다면 새로운 Authentication 객체를 생성해서  AuthenticationManager에게 전달하여 인증을 처리하는 것이에요.

역시 이용자가 존재하지 않으면 Exception이 터진답니다.

Remember Me Token에는 이용자의 Password 정보, ID 정보, Token 만료일 정보 등이 담겨 있어요.

 

        📦 인증 API - AnonymousAuthenticationFilter

 

AnonymousAuthenticationFilter는 아래와 같이 동작하는 친구에요.

• 익명 이용자 인증 처리 Filter.
• 익명 이용자와 인증 이용자를 구분해서 처리하기 위한 용도로 사용.
• 화면에서 인증 여부 구현 시 isAnonymous()와 isAuthenticated()로 구분해서 사용.
• 인증 객체를 Session에 저장하지 않음.

원래 이용자가 인증을 하게 되면 인증 객체에 해당 이용자에 정보를 담게 되고, 이를 Session으로 가지고 있습니다.
그런데, 인증을 받지 않게 되면 인증 객체 값은 당연히 Null이 될거에요.

하지만, AnonymousAuthenticationFilter는 인증 받지 않은 이용자에 대한 인증 객체를 Null로 두는 것이 아니고, 별도 익명 이용자용 인증 객체를 만들어서 이용하는 것이에요.

최초 이용자가 요청을 보내게 되면 AnonymousAuthenticationFilter가 요청을 받게 됩니다.
그러면 현재 요청을 보낸 이용자가 인증 객체가 존재하는지 여부를 먼저 판단하게 됩니다.

인증을 받았다면 SecurityContext에 해당 이용자에 인증 객체가 저장이 되어 있을 것이에요.

SecurityContext 안에 인증 객체가 없다는 것은 해당 이용자는 인증을 받지 않았다고 판단할 수 있어요.

만약 인증 객체가 존재한다면 AnonymousAuthenticationFilter는 별다른 작업없이 doFilter를 통해 다음 Filter로 작업을 넘깁니다.

인증 객체가 존재하지 않는다면 익명 이용자로 판단해서 AnonymousAuthenticationToken 즉, 익명 이용자용 Token을 생성을 해서 Null로 처리하지 않는 것이에요.

그런 뒤 SecurityContextHolder 안에 SecurityContext에 익명 이용자용 객체를 저장하게 됩니다.

그래서 인증을 거치지 않았지만, 인증을 받았을 때와 동일하게 SecurityContext 안에 인증 객체를 저장하도록 처리를 하는 것이에요.

isAnonymous() 값이 True일 때 익명 이용자라는 것이 확인되기 때문에 Menu를 구성할 때, Login Page로 이동하게 처리를 할 수 있고, 

isAuthenticated() 값이 True라는 것은 인증을 받은 이용자라는 것이기 때문에 Menu를 구성할 때, Logout Button과 기능이 활성화 되도록 처리할 수 있는 것이에요.

 

 

 

 

        📦 인증 API - 동시 Session Controll / Session 고정 보호 / Session 정책

동시 Session 제어란 무엇일까요? 하나의 계정으로 여러개의 인증을 받을 때, 생성 된 Session에 개수가 초과되었을 때, 어떤식으로 이런 Session을 제어할 것인지를 정하는 부분 입니다.

Spring Security는 이럴 때, 두 가지로 Handling이 가능하도록 기능을 제공하고 있습니다.


최초 최대 Session 허용 개수가 초과했다고 가정을 해 볼게요. 이 때, 하나의 계정으로 생성될 수 있는 Session에 최대 개수는 하나라고 가정을 해 볼게요.

이 때, 이전 이용자 Session을 만료 시키는 전략을 한번 살펴 볼게요.

최초 이용자 1이 Server에 Login을 하고, Server는 해당 이용자에게 Session을 생성해서 전달해 줍니다.
그렇다면 Server에는 이용자 1에 대한 Session이 생성되어 있을 거에요.

그런 뒤 이용자 2가 Login을 요청을 해요. 당연히 이용자 1이 이용했던 계정 정보를 동일하게 이용하여 Login을 하는 것이에요.

그러면 이용자 2에 대한 Session이 새롭게 만들어져서 발급됩니다.

Server에는 이용자 1과 이용자 2에 대한 Session이 저장되어 있겠네요.
그렇다라는 건 Server에는 동일한 계정에 대한 Session이 두 개가 생성되었다는 것이에요.

위에서 예시는 최대 Session 허용 개수가 1개라고 했어요.
그럼 초과가 된 것이고, 이 때, Server는 이 전 Login 인증에 대한 Session 만료가 되도록 설정하게 되면
Server는 이 전 이용자인 이용자 1에 대한 Session을 즉시 만료 시켜 버려요.

이 방식이 바로 동시 Session 제어에서 이전 이용자 Session을 만료 시키는 전략이에요.


두번째는 현재 이용자 인증을 실패하도록 하는 전략이에요.
최초 이용자 1이 Login을 시도해서 Server는 Session을 생성하고, 발급을 해 줍니다.
그런 뒤 이용자 2가 동일 계정으로 Login을 시도하게 되면 인증 예외를 발생시켜 Login이 불가능하게 처리해 버리는 전략이에요.

첫번째는 첫번째 이용자에 대한 Session을 만료 시키고, 두번째는 두번째 이용자에 대해 인증을 하지 못하도록 막는 전략이에요.


동시 Session 제어는 http.sessionManagement()를 통해 구현하는데, 이는 Session 관리 기능이 작동하게 하는 부분입니다.

protected void configure(HttpSecurity http) throws Exception {
	http
    	.sessionManagement()
    	.maximumSessions(1)						// 최대 허용 가능 Session 수 지정 ( -1은 무제한 Session 허용)
        .maxSessionsPreventsLogin(true)			// 동시 Login 차단(이전 이용자 Session을 만료 시키는 전략), flase일 경우 기존 Session 만료로 동작(Default) 이용자 인증을 실패하도록 하는 전략
        .invalidSessionUrl("/invalid")			// Session이 유효하지 않을 때, 이동할 Page 지정
        .expiredUrl("/expired")					// Session이 만료되었을 경우 이동할 Page 지정

반응형

이번에는 세션 고정 보호에 대해 공부 해 볼게요.

위에 그림에 대해 하나하나 살펴 볼게요.

최초 공격자가 Server에 접속을 합니다.

그러면 Server는 공격자에게 JSessionID가 담긴 Cookie를 발급해 줍니다.

그런 다음 공격자는 자신이 Server에게 받은 JSessionID 값을 설량한 이용자에게 심어 놓는 작업을 합니다.

그런 뒤 이용자는 공격자가 심어놓은 JSessionID를 가지고, Login을 시도하게 됩니다.

Server는 정상적인 이용자라 판단하고, Login 처리를 할 것이에요.

이 때부터 공격자는 엄청난 일을 해낼 수 있게 되는데, 공격자와 이용자의 JSessionID 값이 같다는 건 공격자는 이용자의 정보를 확인할 수 있다는 것이 됩니다.

즉, 공격자는 따로 인증을 받지 않아도 이용자인 척 위장이 가능하다는 것이에요.

이 공격 기법이 바로 Session 고정 공격 기법이에요.

위의 공격 기법을 방어하기 위해 Spring Security는 Session 고정 보호 기법을 만들어 놨어요.

그런 어떤 방법으로 이 공격을 막아내도록 만들어 놨을까요?

이용자가 공격자가 심어놓은 JSessionID 값을 가지고 인증 시도를 할 때, Server가 새로운 Session을 발급하고, 새로운 Cookie를 만들어 주는 방법으로 이 공격을 막아내고 있어요.


Session 고정 보호는 http.sessionManagement()를 통해 활성화 할 수 있어요. 이 친구를 이용하면 Session 관리 기능이 활성화 된답니다.

protected void configure(HttpSecurity http) throws Exception {
	http
    	.sessionManagement()
        .sessionFixation().changeSessionId() 	// Default Value -> non, migrateSession, new Session이 존재
}

changeSessionId() 는 이용자가 인증에 성공하게 되면 해당 이용자에 Session은 그대로 두고, Session ID 값만 변경을 합니다. 참고로 이 친구는 서블릿 3.1에서 기본값이에요.

migrateSession()의 경우는 Session과 Session ID값 모두 새롭게 만들어 지는 것이에요. 그리고 이 친구는 서블릿 3.1 이하에서 기본값이에요.

위 두 친구들은 새롭게 Session이 생성되기 이 전에 설정된 값을 모두 그대로 사용하게 할 수 있는 친구들이에요.


newSession()의 경우 Session과 JSessionID 모두 새롭게 발급되며, 이 전에 설정된 값 모두를 사용하지 못하고, 새롭게 설정해야 하는 친구에요.

마지막으로 none은 의미가 없어요. 이렇게 해 놓으면 위의 공격 기법에 당할 수 밖에 없습니다.

위의 내용은 우리가 실제적으로 Coding을 하지 않아도 기본적으로 작동되게 Spring Security가 작동하고 있어요.

이번에는 Session 정책에 대해 공부해 볼게요.

protected void configure(HttpSecurity http) throws Exception {
	http
    	.sessionManagement()
        .sessionCreationPolicy(SessionCreationPolicy. If_Required)
}

• SessionCreationPolicy.Always : Spring Security가 항상 Session 생성.
• SessionCreationPlicy.If_Required : Spring Security가 필요 시 Session 생성 (Default Value).
• SessionCreationPolicy.Never : Spring Security가 Session을 생성하지 않지만, 이미 Session이 존재하면 사용.
• SessionCreationPolicy.Stateless : Spring Security가 Session을 생성하지 않고, Session이 존재해도 사용하지 않음. (Session 방식을 사용하지 않을 때 사용)

        📦 인증 API - SessionManagementFilter

1. Session 관리

  • 인증 시 이용자의 Session 정보를 등록, 조회, 삭제 등 Session 이력 관리.

2. 동시적 Session 제어

  • 동일 계정으로 접속이 허용되는 최대 Session 수 제한.

3. Session 고정 보호

  • 인증 할 때마다 Session Cookie를 새로 발급하여 공격자의 Cookie 조작 방지.

4. Session 생성 정책

  • Always, If_Required, Never, Stateless

        📦 인증 API -  ConcurrentSessionFilter

이 친구는 위의 SessionManagementFilter에서 동시적 Session 제어를 함께 처리하는 친구에요.
즉, 서로 연계에서 동시적 Session 제어를 처리하게 됩니다. 

  • 매 요청 마다 현재 이용자의 Session 만료 여부 확인.
  • Session 만료 시 즉시 만료 처리.

Session.isExpired() == true

  • Logout 처리.
  • 즉시 Error Page 응답 : " This session has been expired "

이번에는 SessionManagementFilter와 ConcurrentSessionFilter를 함께 공부해 볼게요.
이 두 친구가 동시적 Session 제어를 처리할 때, 어떻게 동작하는지 알아봐요.

최초 이용자가 Login을 하려고 할 때, 이미 누군가 Login을 하였고, Session이 생성된 상황이에요.
만약 최대 허용 Session 개수가 1개라고 했을 때, 최대 허용 Session 개수가 초과가 된 것이고, 이 때, 동시 Session 제어에서 ⌜ 이전 이용자 Session 만료 ⌟ 정책을 이용한다고 가정했을 때, 이전 Login을 한 이용자에 Session을 만료 시키는데, 이를 session.expireNow()를 통해서 처리를 하게 됩니다.

이 때, 이 전에 접속했던 이용자가 Login 외에 다른 Request를 보낸다고 하면 session.expireNow()를 통해 이미 Session이 만료가 되도록 처리가 된 뒤의 Request가 들어온 것이에요.

이 때, 이 전 이용자에 Request를 ConcurrentSessionFilter가 매 Request 마다 이용자의 Session 만료 여부를 확인하게 되는데, 이 전 이용자에 대한 Session 만료 여부를 확인할 때, SessionManagementFilter 안에서 이 전 이용자의 Session을 만료 시켰던 설정값을 참조하게 됩니다.

이 때, SessionManagementFilter 안에서 이 전 이용자의 대한 Session이 만료되도록 설정이 되어있다면 즉시, 이 전 이용자를 Logout 처리 하고, Error Page를 응답하게 처리가 됩니다.

이번에는 두 친구들의 전반적인 처리 과정을 한번 살펴 볼게요.

최대 Session 허용 개수는 1개라고 가정을 합니다.

최초 이용자 1과 2가 Login을 시도합니다.
이 때, UsernamePasswordAuthenticationFilter(인증 처리 Filter)가 인증 처리를 하게 되는데, 최초 UsernamePasswordAuthenticationFilter는 ConcurrentSessionControlAuthenticationStrategy Class를 호출하게 됩니다.

ConcurrentSessionControlAuthenticationStrategy Class는 동시적 Session 제어를 처리하는 Class에요.

ConcurrentSessionControlAuthenticationStrategy는 인증 요청을 한 이용자에 Session 개수가 몇개인지를 확인합니다. 현재 상황에서는 이용자 1이 인증 요청을 했을 때는 당연히 Session 개수가 0개 일 것이고, ConcurrentSessionControlAuthenticationStrategy Class를 호출할 때 아무런 문제없이 통과 처리가 됩니다.

그런 뒤 ChangeSessionIdAuthenticationStrategy Class(Session 고정 보호 처리)가 호출이 되는데, session.changeSessionId()가 Default Value이기 때문에 새로운 Session을 발급하게 될 것입니다.

그 다음으로 호출 되는 Class는 RegisterSessionAuthenticationStrategy인데, 이 친구는 이용자의 Session을 등록하고, 저장하는 역할을 합니다. 이 친구가 Session을 등록하고 저장을 해야만 Session이 Server 안에 저장되고, 그제서야 Session Count 값이 1로 바뀌게 됩니다.

여기까지 내용이 이용자 1이 인증 요청을 보냈을 때, UsernamePasswordAuthenticationFilter가 각각의 Class들을 호출하면서 작업하는 내용을 알아보았어요.

이 때, 이용자 2가 동일한 계정으로 인증 요청을 보냅니다.

이용자 2에 대한 인증 요청도 동일하게 UsernamePasswordAuthenticationFilter(인증 처리 Filter)가 인증 처리를 하게 되는데, 최초 UsernamePasswordAuthenticationFilter는 ConcurrentSessionControlAuthenticationStrategy Class를 호출하게 됩니다.

ConcurrentSessionControlAuthenticationStrategy는 인증 요청을 한 이용자에 Session 개수가 몇개인지를 확인합니다. 현재 상황에서는 이용자 1이 인증이 된 상황이기 때문에 당연히 Session 개수가 1일 것이고, 최대 허용 Session 개수는 1이라고 가정을 한 상태입니다.

session count 1 (sessionCount == maxSessions) 라는 상태입니다.

이렇다라는 건 최대 허용 Session 개수를 초과한 상태이고, 두 가지 전략으로 이 내용을 처리를 할 수 있습니다.

인증 실패 전략과 세션 만료 전략이 있는데, 먼저 인증 실패 전략인 경우 SessionAuthenticationException (인증 예외)를 발생 시키고, Session이 만들어지지 못하고, 인증 실패 처리를 하게 되 버립니다.

두번째 세션 만료 전략인 경우에는 session.expireNow()를 통해 이 전에 인증한 이용자 1에 대한 Session을 만료 시켜 버립니다.

이렇게 되면 이용자 2는 인증에 성공한 상태가 됩니다. 
인증에 대한 처리는 위에서 최초 이용자 1이 인증 처리를 할 때와 동일한 절차를 밟게 됩니다.

이 때, Server에는 이용자 1과 이용자 2에 대한 Session이 각각 한 개씩 저장되어 있는 상태 입니다.

그리고, 이용자 1이 다시 어떤 자원에 접근을 위한 요청을 보내게 되면 ConcurrentSessionFilter가 이용자 1과 이용자 2에 Session 만료 여부를 확인 합니다. ConcurrentSessionFilter는 Client에서 요청이 올 때마다 Session 만료 여부를 확인 합니다. 

이 확인을 위해 ConcurrentSessionControlAuthenticationStrategy의 session.expireNow() : 이용자 1 처리를 한 내용을 가져오게 됩니다.

이렇게 되면 session.isExpired() 값은 이용자 1에 대해 true가 되고, ConcurrentSessionFilter는 즉시 이용자 1을 Logout 처리 해버리고, 응답값으로 " this session has been expired "와 같은 내용을 반환해 주게 됩니다.

        📦 인증 API -  권한 설정 및 표현식

1. 선언적 방식

    •  URL : http.antMatchers("/users/**").hasRole("USER")
    • Method : @PreAuthorize("hasRole('USER')")
       public void user() { System.out.println("user") }

2. 동적 방식 - Data Base 연동 Programming

    • URL   
• Method 

이번에는 선언적 방식에서 URL 설정 방식에 대해 공부해 볼게요.

 

@Override
protected void configure(HttpSecurity http) throws Exception {
	http
    	.antMatcher("/shop/**")
        .authorizeRequests()
        	.antMatchers("/shop/login", "/shop/users/**").permitAll()
            .antMatchers("/shop/mypage").hasRole("USER")
            .antMatchers("/shop/admin/pay").access("hasRole('ADMIN')");
            .antMatchers("/shop/admin/**").access("hasRole('ADMIN') or hasRole('SYS')");
            .anyRequest().authenticated()
}

위의 URL 설정 시 주의사항은 구체적인 경로가 먼저 오고, 그것보다 큰 범위의 경로가 뒤에 오도록해야 하는 점 입니다.

최초 .antMatcher("/shop/**") 은 이용자가 /shop 하위(**)에 대해 요청을 보냈을 때에만 그 하위에 설정된 내용이 적용되도록 하겠다는 의미에요.

따라서 위와 같이 설정했을 때, /shop/** 이 아닌 다른 URI에 요청을 보내게 된다면 위에 설정은 작동하지 않게 됩니다.

.antMatchers("/shop/login", "/shop/users/**").permitAll()
위의 내용에서 antMatchers() 괄호안에 여러가지 URI를 문자열로 넣을 수 있어요. 이것은 이용자가 요청한 URI 정보와 Server 내에 등록된 URI가 일치하면 권한 심사를 하겠다는 의미에요. 그런 뒤 .permitAll()을 하면 인증 절차 없이 접근을 허용하겠다는 의미입니다.

.antMatchers("/shop/mypage").hasRole("USER")
위의 내용에서 .hasRole("USER")는 USER 권한 인지에 대한 인가 심사를 처리하겠다는 의미에요.

위의 내용에 적은 내용 중 하나라도 적용되지 않으면 인가 처리를 받을 수 없어요.

.anyRequest().authenticate()는 위에 모든 조건에 만족하지 않으면 모든 요청은 인증 처리를 받아야 한다.라는 내용이에요.

Method	동작 방식
authenticated()	인증된 이용자 접근 허용.
FullyAuthenticated()	인증된 이용자 접근 허용. 단, rememberMe 인증 제외. ID, Password로만 인증 처리를 하고자 할 때 사용.
permitAll()	인증을 받지 않아도 접근 허용.
denyAll()	인증을 받아도 무조건 접근 허용하지 않음.
anonymous()	익명 이용자에 대한 접근 허용.
rememberMe()	인증 정보 기억하기를 통해 인증된 이용자 접근 허용.
access(String)	주오진 SpEL 표현식("hasRole('ADMIN')") 평가 결과가 true 일 때, 접근 허용.
hasRole(String)	요청 이용자가 주어진 역할을 가지고 있다면 접근 허용.
hasAuthority(String)	요청 이용자가 주어진 권한이 있다면 접근 허용.
hasAnyRole(String...)	요청 이용자가 주어진 권한이 있다면 접근 허용.
hasAnyAuthority(String...)	요청 이용자가 주어진 권한 중 어떤 것이라도 있다면 접근 허용.
hasIpAddress(String)	등록된 IP로부터 요청이 왔다면 접근 허용.

이제 Code를 작성해서 해당 Code를 분석하면서 공부를 해 볼게요.

public class SecurityConfig extends WebSecurityConfigurerAdapter

먼저 configure(AuthenticationManagerBuilder auth)를 통해 auth.inMemoryAuthentication()으로 Memory 내에 임시 계정을 생성해 볼게요.

.password() 안에 noop은 위와 같이 계정을 만들 때, Password안에 어떤 방식의 Hash 암호화를 사용할 것인지를 작성해 줘야 나중에 Login을 할 때, 해당 Hash 암호화 방식을 이용해 값을 비교해 볼텐데, 작성해 주지 않으면, 비교 자체가 안되어 문제가 발생합니다.

바로 이렇게 인증 요청을 보내게 되면 Exception이 발생하게 될 거에요.




그래서 noop으로 평문으로 저장하게 하겠다를 명시한 것이에요.

Test로 사용될 Controller에 위와 같이 4개의 Method를 만들어 주었어요.

각각의 Method에 요청이 들어오게 되면 Web Page 상에 요청 이용자의 ID (principal.getName()) 과 요청 이용자 권한 정보를 가져올 수 있도록 처리 해 주었어요.

getRoleinfo()는 최초 SecurityContextHoder에는 인증 요청 이용자에 정보가 담겨 있다고 위에서 공부해 보았어요.
그래서 주니하랑은 이 안에 getContext().getAuthentication()을 통해 인증 정보를 가져오도록 하였고, 그 인증 객체 안에 권한 정보 목록을 반환하도록 처리하여 응답을 주도록 처리했어요.

최초 user 계정으로 인증을 받아 볼게요.

인증을 정상적으로 받았어요.
이 때, 권한 확인을 위해 /user로 접근해 볼게요.

아주 접근이 잘 되고 있어요.

user 권한을 가진 user 계정으로 /admin URI Get 요청을 보내니 위와 같이 Forbidden (권한 없음) Error 가 발생하고 있어요.

/admin/pay 도 동일하게 접근할 수 없네요!

이번엔 sys 권한에 대해 Test를 진행 해 볼게요.

 

 

인증이 정상적으로 되었고, Home에 접속이 되었어요.

 

SYS 계정은 /admin/** 하위 모든 URI에 대해서는 접근이 가능하게 설정을 해주었기 때문에 위의 URI 요청에 대해서는 문제 없이 접근이 가능해요.

하지만, /admin/pay에 대해서는 ADMIN 권한을 가진 이용자만 접근할 수 있도록 했기 때문에 접근이 불가합니다.

또한 /user 역시 USER 권한만 접근이 가능하게 했기 때문에 접근이 불가해요.

public class SecurityConfig extends WebSecurityConfigurerAdapter

하지만, 위와 같이 각 계정에 맞게 여러 권한들을 내부 정책에 맞게 설정을 해주면 SYS는 USER 권한을 갖게 되었음으로 접근이 가능하게 됩니다.

 

이렇게 접근할 수 있어요.

이번에는 /admin 하위 모든 자원을 접근할 수 있는 내용이 /admin/pay보다 위에 있을 때, 즉, 구체적인 경로가 먼저 오고, 그것보다 큰 범위의 경로가 뒤에 오도록해야 하는 점에 위반 되었을 때를 Test 해볼게요.

결과적으로 /admin/** 에 대한 설정값이 먼저 처리가 되기 때문에 /admin/pay는 도달할 수 없는 코드가 되어버립니다.

위에서 SYS 계정은 /admin/pay에 접근할 수 없었으나, 지금은 이렇게 접근을 할 수 있습니다. 이유는 위에 설명한 바와 같습니다.

        📦 인증 API -  예외 처리 및 요청 캐시 필터 : ExceptionTranslationFilter / RequestCacheAwareFilter

먼저 ExceptionTranslationFilter에 대해 공부해 볼게요.

1.  AuthenticationException

    • 인증 예외 처리
      - AuthenticationEntryPoint 호출
         -> Login Page 이동, 401 Error Code 전달 등

    • 인증 예외가 발생하기 전 요청 정보 저장
      - RequestCache - 이용자의 이전 요청 정보를 Session에 저장하고, 이를 꺼내오는 방식.
      - SaveRequest - 이용자가 요청했던 Request Parameter 값들, 그 당시 Request Header 값 등을 저장.

2.  AccessDeniedException

    • 인가 예외 처리
      - AccessDeniedHandler 에서 예외 처리하도록 제공.

 

위 두가지 Exception을 Throw (발생) 시키는 주체 Filter는 바로 FilterSecurityInterceptor에요.

위 Filter는 Spring Security가 관리하는 Filter 중 맨 마지막에 위치한 Filter에요. 이 앞에 위치한 Filter가 바로 

ExceptionTranslationFilter에요.

ExceptionTranslationFilter가 이용자 요청을 받아 그 다음 Filter에게 전달할 때, try catch {}로 감싸서 FilterSecurityInterceptor를 호출합니다.

따라서 FilterSecurityInterceptor에서 발생된 인증, 인가 Exception은 해당 Filter를 호출한 ExceptionTranslationFilter에게 인증, 인가 Exception을 Throw 즉, 전달하고 있어요.

최초 이용자가 /user URI에 접근 요청을 보내게 됩니다.
해당 URI 자원은 인증을 받아야만 접근이 가능한 자원입니다.
만약 이 이용자가 인증을 받지 않았다면 FilterSecurityInterceptor가 이용자의 요청을 받게 됩니다. 

이 상황에서 FilterSecurityInterceptor는 인증을 받지 않고, 접근했기 때문에 인증 예외를 발생 시키게 되요.
정확하게 이야기 하자면 인증 예외가 아니고, 인가 예외를 발생시킨다고 봐야해요. 왜냐하면 인증을 받지 않고, 접근을 했기 때문에 익명 이용자가 접근하는 상황이라고 볼 수 있어요.

그렇기 때문에 인증 예외가 아니라, 권한이 없다고 판단을 하기 때문에 인가 예외가 발생하는 상황이 되요.

이 때, ExceptionTranslationFilter가 바로 AccessDeniedException으로 예외를 전달하기는 하는데, AccessDeniedHandler를 호출하지는 않아요. 익명 이용자에 접근 요청이던지 remember Me 인증 이용자의 경우 
AuthenticationException으로 예외를 전달하게 되요. 즉, 인증 예외 처리 과정으로 넘어가게 되는 것이에요.

은 Class에 인증 예외가 발생한 이용자 요청 관련 정보를 저장해요. 해당 정보는 객체 안에 저장이 되며, 이 객체는 에 다시 저장이 됩니다.AuthenticationExceptionHttpSessionRequestCacheDefaultSavedRequestSession

그런 뒤 AuthenticationException은 AuthenticationEntryPoint Interface 구현체를 호출하여 인증 실패 이후 작업을 처리하도록 전달해요.

그러면 인증 예외가 발생했기 때문에 보통 Login Page로 이동하게 처리를 해요. 그 전에 객체안에 인증 객체를 Null로 만드는 작업을 선행합니다.만약 요청 이용자가 인증은 받았는데, 권한이 맞지 않을 때는 어떤일이 발생할까요?이럴 때는 인가 예외가 발생하게 되는데, 이 때는SecurityContext



ExceptionTranslationFilter 가AccessDeniedException를 처리하게 되요.

AccessDeniedHandler가 호출되고, 그 안에서 그 다음 작업을 처리하게 되는데, 보통은 /denied와 같은 Error Page로 이동을 시켜요. 그렇게 해서 이용자에게 자원에 접근할 권한이 없다는 것을 알려줄 수 있어요.


ExceptionTranslationFilter를 어떻게 이용할 수 있을까요?

: 예외 처리 기능 활성화http.exceptionHandling()

protected void configure(HttpSecurity http) throws Exception {
	http
    	.exceptionHandling()
        .authenticationEntryPoint(authenticationEntryPoint())	// 인증 실패 시 처리
        .accessDeniedHandler(accessDeniedHandler())				// 인가 실패 시 처리

public class SecurityConfig extends WebSecurityConfigurerAdapter

위에서 설명한 내용을 기반하여 코드를 작성해 주었어요.

public class SecurityConfig extends WebSecurityConfigurerAdapter

그런 뒤 이용자가 인증에 성공하면 불리게 되는 successHandler에 인증 성공 요청자가 요청한 URI 정보를 저장하고, 그 URI로 이동하게 코드를 수정해 주었어요.

그리고, Controller에 인가 예외가 발생할 시 들어올 Page URI에 대한 Method를 작성해 주었어요.

 

인가를 처리하는 코드부에 /signin은 인증 없이 접근이 가능하도록 하고, 나머지 모든 URI 요청에 대해서는 인증 예외가 발생하게 될 것이고, AuthenticationException이 AuthenticationEntryPoint를 호출하여 171번째 코드와 같이 /signin (Spring security가 제공하는 Login Page 아님)으로 이동하게 처리가 되도록 해 두었어요.

root page로 접근을 하게 되면 어떤일이 일어날까요?

바~로 signin Page로 넘어가게 되고, 요청 이용자의 권한은 익명 이용자인것을 확인할 수 있어요.

이번에는 인증 예외 처리하는 부분을 주석 처리하고, 인증이 성공하면 해당 이용자가 요청한 URI로 바로 접근을 하는지 Test 해 볼게요.

최초 /admin/test URI 자원 접근 요청을 보낼게요.

그러면 Spring Security가 제공하는 Sign in Page에 접근이 되고, SYS 계정으로 Login을 해 볼게요.

이 전에 이용자가 요청한 URI로 바로 이동하는 것을 확인할 수 있습니다.



해당 계정이 접근할 수 없는 /admin/pay로 접근 요청을 하게 되면 어떻게 될까요?

 

이렇게 인가 예외 처리가 발생하여 /denied Page로 이동하는 걸 확인할 수 있어요.

 

 

        📦 Form 인증 -  CSRF, CsrfFilter

먼저 CSRF(Cross Site Request Forgery - 사이트 간 요청 위조 공격)에 대한 내용은 이 곳에 정리 해 두었어요.

그럼 CSRF 공격을 막으로면 Spring Security로 어떻게 막을 수 있는지를 공부해 볼게요.
이를 위해 CsrfFilter를 공부해야 합니다.

 

    •  모든 Request에 Random하게 생성된 Token을 HTTP Parameter로 요구.
    • Request에 전달되는 Token값과 Server에 저장된 Token 값이 같은지를 비교하고, 일치하지 않으면 실패 처리.

1. Client

    •       - Front End 에서는 hidden type으로 name을 Server에서 발급한 Token 이름과 값은 Token 값으로 설정. <input type = "hidden" name = "${_csrf.parameterName}" value="${_csrf.token}" />

    • HTTP Method : PATCH, POST, PUT, DELETE
       - 위의 Method를 이용할 때는 반드시 Server에서 발급한 Token을 요청시 함께 Server에 제출해야 함.

2. Spring Security

    • http.csrf() : 기본 활성화.
http.csrf.disabled() : 비 활성화 처리. 
ForgeryF

 

 

 

다음 글 : [Stpring Boot] Spring Security Basic - 주요 아키텍처 이해편