💭 Spring Security

스프링 기반의 앱에서 보안(인증, 권한, 인가)등을 담당하기 위해 만들어진 하위 프레임워크이다.

Spring Security는 보안을 담당하는 프레임워크이다. 그래서 스프링 앱과의 의존성을 분리시키기 위해 기본적으로 서블릿 필터기반으로 동작하게끔 만들어져있다. 즉 스프링을 사용하지 않더라도 서블릿을 사용하고 있다면 따로 적용이 가능하다.

Spring Security가 없다고 스프링 웹앱의 보안을 만들 수 없는건 아니다. 하지만 보안과 관련해서 체계적으로 많은 옵션을 제공해주기 때문에, 개발자 입장에서는 일일이 보안 관련 로직을 고생해서 작성하지 않아도 쉽게 보안이 가능하다.

💭 스프링 시큐리티를 사용하는 방법

maven이나 gradle을 사용한다면 복잡한 설치과정 없이 아래 한줄이면 적용 가능하다.

해당 의존성을 추가하게되면 서버 (ex 스프링부트의 내장톰캣)에 스프링 시큐리티와 관련된 초기화 작업 및 보안 설정이 이루어진다. 즉 별도의 설정을 하지 않아도 기본적인 웹 보안 기능이 적용된다고 이해하면 된다.

더보기

 기본적인 웹 보안 기능이란 다음과 같다.

• 인증 방식으로 폼 로그인 방식 / httpBasic 로그인 방식을 제공한다.
• 모든 요청(Request)은 인증이 되어야 자원에 접근이 가능하다.
• 개발용으로 기본 로그인 페이지와 기본 계정을 한개를 제공해준다.
  참고로 개발용 기본 계정은 application.properties에서 변경 가능하다. 

spring.security.user.name=user
spring.security.user.password=1234​

---

• pom.xml (maven)

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

• build.gradle (gradle)

implementation 'org.springframework.boot:spring-boot-starter-security'

💭 스프링 시큐리티의 기본 구조

스프링 시큐리티의 각종 설정은 HttpSecurity로 대부분 하게 된다.

• 리소스(URL) 접근 권한
• 설정인증 전체 흐름에 필요한 Login, Logout 페이지 인증완료 후 페이지 인증 실패 시 이동페이지 등
• 설정인증 로직을 커스텀하기위한 커스텀 필터
• 설정기타 csrf, 강제 https 호출 등등 거의 모든 스프링시큐리티의 설정

HttpSecurity 는 WebSecurityConfigurer 를 통해 만들 수 있다.

즉, 스프링 시큐리티를 사용하기 위해서는 WebSecurityConfigurer 객체를 만들어서 빈으로 등록해야한다.

직접 만들기는 번거로우므로, 보통은 이를 구현한 추상클래스인 WebSecurityConfigurerAdapter 를 이용한다.

스프링은 스프링 시큐리티를 쉽게 사용할 수 있도록, @EnableWebSecurity라는 애노테이션을 제공한다.

그냥 애노테이션만 붙인다고 동작하는 건 아니고, Spring 시큐리티 모듈 의존성에 존재하는 상태에서 WebSecurityConfigurerAdapter 클래스 상속받으면 앱 실행 시점에서 스프링 빈으로 등록된다.

@EnableWebSecurity // @Configuration 을 포함하고 있다. 스프링 빈으로 등록됨.
public class SecurityConfig extends WebSecurityConfigurerAdapter {
 
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .anyRequest().authenticated(); // 어떤 요청에도 보안을 받도록 인가정책 설정.
 
        http.formLogin(); // form-login 인증 정책
    }
}

SecurityConfig 예제

@Configuration // 생략해도 상관없지만, 명시적으로 표시해주자
@EnableWebSecurity
public class SecuriyConfig extends WebSecurityConfigurerAdapter{
    
    /*
    	- Spring Security를 무시할 url을 선언
    	- 보통 정적 자원이 저장된 경로를 명시
    */
    @Override
    public void configure(WebSecurity web) throws Exception {
        web,ignoring().antMatchers("/webjars/**"); 
    }
	
    // - Spring Security 적용 규약 명시
    @Override
    protected void configure(HttpSecurity http) throws Exception {
 
        http.authorizeRequests()
		    .antMatchers("/**").permitAll() //명시된 경로에 대해서는 모두 접근 가능
			.anyRequest().authenticated();
 
		http.formLogin()
		   	.loginPage("/loginPage") //명시된 경로를 로그인 페이지로 사용
		   	.loginProcessingUrl("/login") //명시된 경로를 로그인 url로 사용
		   	.usernameParameter("usrId") //파라미터와 동일한 name을 가지는 input 태그로부터 아이디값을 받아옴
			.passwordParameter("usrPw") //파라미터와 동일한 name을 가지는 input 태그로부터 비밀번호값을 받아옴
			.successHandler(successHandler()).failureHandler(failureHandler());
 
		http.logout()
			.logoutUrl("/logout") //명시된 경로를 로그아웃 url로 사용
			.logoutSuccessUrl("/") //로그아웃 성공시 리디렉션될 url을 지정
			.invalidateHttpSession(true) //인증 관련 세션 정보 삭제
			.deleteCookies("JSESSIONID"); //쿠키 삭제
 
		http.exceptionHandling()
			.accessDeniedPage("/");  
    }
	
    // - 사용자 인증 방법 명시(여기서는 인메모리방식을 사용)
    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
            	.passwordEncoder(encoder())
            	.withUser("admin")
            	,password("admin")
            	.authroties("USER","ADMIN");
    }
 
    @Bean
    public BCryptPasswordEncoder encoder(){
        return new BCryptPasswordEncoder();
    }
    
    // Sucess, Failure Handler 구현하여 Bean으로 등록
    @Bean
    public AuthenticationSuccessHandler successHandler(){
        return new AuthSuccessHandler("/");
    }
    
    @Bean
    public AuthenticationFailureHandler failureHandler(){
        return new AuthFailureHandler();
    }
}

이처럼 어댑터를 이용하게되면 내부의 configure() 메서드만 적절하게 바꿔서 편하게 사용가능하다.

• configure(WebSecurity web) : WebSecurity를 설정할 수 있다. 특정 요청을 무시하거나 할 수 있다.
• configure(HttpSecurity http) : HttpSecurity를 설정할 수 있다. 접근권한, 로그인 등등 요청 경로 지정가능
• configure(AuthenticationManagerBuilder) : 사용자 인증 정보를 구성한다. in-memory 기반 유저를 생성할 수 있다.

물론 스프링부트를 사용하고 있다면 apllication.yml에서도 설정이 가능하지만, 모든 설정을 yml에서 처리할 수 없기에 보통 위의 코드처럼 Configuration Class를 만들어서 함께 사용한다.

📑 어? 그런 설정없이도 스프링 시큐리티는 동작하던데요?

그건 우리가 스프링 부트를 사용해서 프로젝트를 만들었기 때문이다.

implementation 'org.springframework.boot:spring-boot-starter-security'

스프링부트는 SecurityAutoConfiguration 클래스를 설정파일로 참고하는데,

해당 객체는 DefaultAuthenticationEventPublisher를 @Bean으로 등록한다.

@Configuration
@ConditionalOnClass(DefaultAuthenticationEventPublisher.class)
@EnableConfigurationProperties(SecurityProperties.class)
@Import({SpringBootWebSecurityConfiguration.class, WebSecurityEnablerConfiguration.class,
    SecurityDataConfiguration.class})
public class SecurityAutoConfiguration {
 
    @Bean
    @ConditionalOnMissingBean(AuthenticationEventPublisher.class)
    public DefaultAuthenticationEventPublisher authenticationEventPublisher(
        ApplicationEventPublisher publisher) {
        return new DefaultAuthenticationEventPublisher(publisher);
    }
 
}

이렇게 등록된 publisher는 아래와 같은 기본 이벤트를 매핑해서, 인증 이벤트를 발생시킨다.

• BadCredentialsException
• UsernameNotFoundException
• AccountExpiredException 등등..

하지만 스프링 부트를 사용한다고 해도, 결국 동작원리는 같다. 스프링 부트가 제공하는 시큐리티 설정객체를 보면 위에서 설명한 것 처럼 WebSecurityConfigurerAdapter를 그대로 사용한다.

@Configuration
@ConditionalOnClass(WebSecurityConfigurerAdapter.class)
@ConditionalOnMissingBean(WebSecurityConfigurerAdapter.class)
@ConditionalOnWebApplication(type = Type.SERVLET)
public class SpringBootWebSecurityConfiguration {
 
    @Configuration
    @Order(SecurityProperties.BASIC_AUTH_ORDER)
    static class DefaultConfigurerAdapter extends WebSecurityConfigurerAdapter {
 
    }
 
}

참고로 앱이 실행될 때 생기는 기본 user 계정은 UserDetailsService를 상속받아서 재정의하면 만들어지지 않는다.

궁금하면 UserDetailsServiceAutoConfiguration 객체를 구글에 검색해서 찾아보자.

💭 시큐리티 사용해보기 - 세션기반 웹 로그인

스프링 시큐리티를 처음 적용하면, 아래처럼 전통적인 세션 웹 로그인 방식의 form 인증을 기본적으로 제공해준다.

이는 아래와 같이 configure 메서드안에서, http.formLogin() 설정을 통해 쉽게 커스텀이 가능하다.

@EnableWebSecurity // @Configuration 을 포함하고 있다. 스프링 빈으로 등록됨.
public class SecurityConfig extends WebSecurityConfigurerAdapter {
 
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .anyRequest()
                .authenticated()
        .and() // 이렇게 and()를 이용해서 인증, 인가를 한번에 설정할 수도 있다.
            .formLogin()
                .loginPage("/loginPage") // 내가 만든 로그인 페이지
                .defaultSuccessUrl("/") // 로그인 성공시 이동 경로
                .failureUrl("/login.html?error=true") // 로그인 실패시 이동 경로
                .loginProcessingUrl("/login_proc") // form 태그의 Action URL. 기본값은 "/login"
                .usernameParameter("userId")
                .passwordParameter("passwd")
                .successHandler(new AuthenticationSuccessHandler() {
                    @Override
                    public void onAuthenticationSuccess(HttpServletRequest request,
                        HttpServletResponse response, Authentication authentication)
                        throws IOException, ServletException {
 
                        System.out.println("인증성공(authentication) : " + authentication.getName());
                        response.sendRedirect("/");
                    }
                })
                .failureHandler(new AuthenticationFailureHandler() {
                    @Override
                    public void onAuthenticationFailure(HttpServletRequest request,
                        HttpServletResponse response, AuthenticationException exception)
                        throws IOException, ServletException {
 
                        System.out.println("인증실패(exception) : "+exception.getMessage());
                        response.sendRedirect("/login");
                    }
                })
                .permitAll() // loginForm 접속 허용. 이게 없으면 loginPage도 인증없이는 요청하지 못한다.
        ;
 
    }
}

참고로 Login HTML 폼을 설정 값과 다르게 작성한다면 Bad crednetials 등의 예외를 발생시킨다.

나중에 언급할거지만, 스프링 시큐리티 (@EnableWebSecurity)는 기본적으로 CSRF 공격방어등의 다양한 보안 기능을 제공한다. 이런것들도 configure 에서 http 객체를 통해 쉽게 설정을 바꿀 수 있다.

CSRF (Cross-Site Request Forgery)가 뭔데요?

더보기

직역하면 '사이트 간 공격 위조'라고 불리며, 인증(로그인) 후 이용자의 의도하지 않은 요청을 통한 공격을 말한다.

즉 사용자의 인증 이후, 스크립트나 폼 태그를 통해 특정 웹사이트에 본인이 의도하지 않은 요청을 하도록 만드는 공격이다. 실제 한국에서도 2008년 옥션의 개인정보 유출사건에 CSRF 공격을 이용해 관리자계정을 탈취하였다.

 

쉽게말하면 인증된 사용자에게 아래와 같은 HTML 코드를 이용해 해커가 원하는 서버 요청을 발생시키는 것이다.

<!-- 사용자가 해당 링크를 클릭하면 요청이 발생됨 -->
<a href="http://bank.com/transfer?accountNumber=5678&amount=10000">
Pictures@
</a>
 
<!-- 페이지 로드시 이미지를 불러오기위해 해당 링크를 사용자 계정으로 요청하게됨 -->
<img src="http://bank.com/transfer?accountNumber=5678&amount=10000"/>

물론 1990년대 웹도 아니고, 위와 같은 Get 요청으로 데이터가 변경될 일은 없다.
하지만 아래와 같이 Post 요청도 HTML form을 이용하는 경우 인라인 스크립트를 이용해서 요청을 할 수 있다.

<!-- Post를 이용하는 Form 태그도 아래와 같이 HTML 인라인 자바스크립트를 통해 공격가능. -->
<body onload="document.forms[0].submit()">
<form action="http://bank.com/transfer" method="POST">
    <input type="hidden" name="accountNumber" value="5678"/>
    <input type="hidden" name="amount" value="10000"/>
    <input type="submit" value="Pictures@"/>
</form>
...

 

이러한 CSRF를 막을려고 Http의 Referrer 헤더를 검증해서 요청이 기존 domain url이랑 동일한지 검증하기도 한다. 스프링 시큐리티는 CSRF Token을 발급하여 토큰과 함께 요청을 받아 공격을 방지한다.

(* X-XSRF-TOKEN 값이 없다면 403 Forbidden을 반환하도록 기본으로 설정되어있다.)

 

그러나 위의 예제에서도 보다싶이, CSRF는 서버 측에서 HTML을 생성하는 구조 (Thymeleaf, JSP)에서만 발생하는 문제이다.

 

REST API처럼 매번 HTML 페이지를 주는게 아니라 API만 노출하고 JSON으로 통신하는 경우 스크립트 코드를 추가할 수 없기 때문에 CSRF는 전혀 문제가 되지 않는다. 즉 추가적인 CSRF 보안을 할 필요가 전혀없기에 http.csrf.disable()로 비활성화 해주는게 좋다. ➡ permitAll()을 했는데 403 forbidden이 뜬다면 이를 확인해보자.

 

💭 스프링 시큐리티의 동작과정

기본적으로 자바 서블릿 필터의 경우, FilterChain을 구성하여 서블릿이 실행되기 전 필터를 거치게 된다.

스프링 시큐리티의 경우 서블릿 필터체인에 DelegatingFilterProxy를 등록한다. 이는 서블릿 필터의 구현체이다.

그리고 해당 필터가 SecurityFilterChain을 호출하고, 스프링에 등록된 빈을 가져와서 의존성을 주입하게 된다.  

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    // Lazily get Filter that was registered as a Spring Bean
    // For the example in DelegatingFilterProxy delegate is an instance of Bean Filter0
    Filter delegate = getFilterBean(someBeanName);
    // delegate work to the Spring Bean
    delegate.doFilter(request, response);
}

DelegatingFilterProxy 는 스프링 빈이 아닌, 서블릿 필터라서 실제 동작은 FilterChainProxy에 위임하게된다.

• FilterChainProxy는 요청과 응답을 스프링 시큐리티 필터 체인에 위임하는 역할을 담당한다.
  [서블릿 ➡ 스프링 시큐리티의 진입점]이며, 서블릿에서 문제가 발생한다면 해당 객체에서 예외가 발생한다.

• 참고로 SecurityFilterChain은 여러 개로 구성할 수도 있다.
  즉 아래 그림처럼 DelegatingFilterProxy에서 URL에 따라 다른 스프링 시큐리티가 작동하도록 구성할 수도 있다.
  

  

  

시큐리티 필터는 SecurityFilterChain API를 통해 FilterChainProxy에 삽입되고, 스프링 빈으로 등록된다.

즉, 필터로 동작은 하지만 '시큐리티 필터' 자체가 서블릿 필터로 바로 등록되는게 아니라는 것을 이해하고 있자.

스프링 시큐리티는 기본적으로 많은 필터를 제공해주는데, 적용되는 순서와 종류는 공식문서를 참고하자.

알고있으면 좋긴한데, 워낙 종류가 많기도하고 모른다고해서 사용하는데 문제가 생기지는 않는다.

조금 더 자세한 동작원리는 해당 블로그를 참고하면 이해하는데 도움이 될 것 같다.

📑 Login-Form은 어떻게 동작했을까

Login-Form에는 이미 만들어져있는 UsernamePasswordAuthenticationFilter를 사용하여 동작하는데, 해당 시큐리티 필터의 동작구조는 아래와 같다.

이렇게 인증에 성공하면, SecurityContext에 인증 객체가 저장되며, 나중에 인증이 필요할 때 이를 꺼내 쓸 수 있게된다.

조금 더 자세한 클래스 구조(Spring Security Flow Communication Diagram)

더보기

📑 Logout은 어떻게 처리하죠?

로그아웃도 LogoutFilter를 통해 동작한다.

사용법은 아래와 같다.

참고로 익명클래스 대신 람다식을 사용하면 훨씬 간결하게 코드를 작성할 수 있다.

@EnableWebSecurity // @Configuration 을 포함하고 있다. 스프링 빈으로 등록됨.
public class SecurityConfig extends WebSecurityConfigurerAdapter {
 
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .anyRequest()
            .authenticated();
 
        http.formLogin()
        .and()// 물론 http.logout()으로 따로 작성해도 됨.    
        .logout()
            .logoutUrl("/logout") // 로그아웃 요청 URL
            .logoutSuccessUrl("/login") // 로그아웃 성공 후 이동
            .deleteCookies("JSESSIONID","remember-me") // 로그아웃 후 세션쿠키 삭제
            .addLogoutHandler(new LogoutHandler() {
                // handler 를 직접 작성해서 추가적인 로그아웃 처리가 가능.
                @Override
                public void logout(HttpServletRequest request, HttpServletResponse response,
                    Authentication authentication) {
                    System.out.println("Logout 처리 핸들러");
                    HttpSession session = request.getSession();
                    session.invalidate();
                }
            })
            .logoutSuccessHandler(new LogoutSuccessHandler() {
                @Override
                public void onLogoutSuccess(HttpServletRequest request,
                    HttpServletResponse response, Authentication authentication)
                    throws IOException, ServletException {
                    System.out.println("로그아웃 이후");
                    response.sendRedirect("/login");
                }
            });
    }
}

동작과정은 로그인과 비슷하다.

📑 마지막, Remember Me 기능 사용하기

참고로 이는 세션이 만료되고, 웹 브라우저가 종료된 후에도 앱이 사용자를 기록하는 기능이다.

사용자가 Remember-me 쿠키를 요청에 보내면, 유효성을 검사하고 별도의 인증과정 없이 로그인을 유지해준다.

Login과 Logout을 봐서 이미 알겠지만, 이것도 configure 메서드의 http를 이용해서 쉽게 사용가능하다.

세션 쿠키기반 로그인에서, 클라이언트가 로그인에 성공하면 JSessionID와 함께 Remember-me 쿠키를 함께 전달한다.

해당 remeber-me 토큰에는 [암호화된 UserID, Password]와 만료일이 적혀있다. 

1. 웹브라우저를 종료해서 JSESSIONID가 없거나 서버의 세션이 만료되었더라도

2. remember-me 토큰을 쿠키로 보내면

3. 현재 Security Session ➡ Security Context에 일치하는 토큰이 있는지 비교하고, 있다면 새로운 인증개체를 생성하고 새로운 JSESSIONID를 응답에 보낸다.

물론 [서버의 세션 메모리 or 서버 토큰 DB]에 유효한 토큰이 있어야한다. 그것도 없다면 당연히 로그인되지 않는다.

💭 정리

스프링 시큐리티는 어떤 식으로 동작하는지, 대략적인 감을 잡아보았다.

다음 글에서는 세션제어필터, 예외처리 필터등에 대해서 알아보도록 하자.