본문 바로가기
Java/spring

spring security를 알아보자 - 11

by 티코딩 2024. 4. 18.

ㅇ Spring Security에서 필터란?

https://docstore.mik.ua/orelly/xml/jxslt/ch08_04.htm

간단히 보면 클라이언트에서 오는 요청을 필터에서 한번 걸러서 서블릿으로 전달을 한다. 이때 필터는 어떤걸 걸러주는 걸까?

여러가지 필터가있지만 뭐 예를들어 보자면,

  • SecurityContextPersistenceFilter: 보안 컨텍스트를 로드하거나 저장함.
  • CsrfFilter: CSRF 공격을 방지함.
  • LogoutFilter: 로그아웃 처리를 함.
  • UsernamePasswordAuthenticationFilter: 폼 로그인 처리를 함.

각 필터는 요청을 처리하고, 다음 필터로 요청을 전달하거나, 필터 체인을 종료하고 응답을 반환할 수 있다. 필터는 요청 또는 응답을 수정할 수 있으며, 인증 실패와 같은 경우에 요청 처리를 중단하고 오류 응답을 반환할 수도 있다.

필터가 처리되는 과정은 필터체인으로 연쇄적으로 한개의 필터씩 거치게 된다.

 

ㅇ 유저 인증시 사용하는 내장 필터

애플리케이션 클래스 내에서 @EnableWebSecurity(debug=true) 를 추가해주자. 그리고 application.properties에 loggin.level.org.springframework.security.web.FilterChainProxy=DEBUG를 추가해주자. 이러면 우리의 filterchian을 살펴볼 수 있다. 실제 서비스에는 사용하면 안된다. 보안사항도 로그에 기록되기 때문이다. 

FilterChainProxy 내부에 들어가면 VirtualFilterChain이라는 내부클래스가 있다. 

doFilter라는 메서드가 있는데 SpringSecurity 필터 체인 내에서 사용가능한 모든 필터를 반복하는 로직이 있다.

 doFilter에 첫번째줄에 중단점 처리해놓고 디버그로 애플리케이션을 돌리고 로그인을 해보면 size에서 몇개의 필터가 거치는지 알 수 있다. 밑네 내려가면 additionalFilters를 자세히보면 어떤 필터들이 있는지도 알 수 있다. 한개의 필터를 처리하고나면 마지막에 doFilter를 다시호출해 다음 필터를 처리하게 된다.

 

ㅇ 커스텀 필터

Spring Security에서 제공하는 필터 말고도 커스텀으로 직접 필터를 만들어서 사용할 수도 있다. 어떻게 정의할까? jakarta.servlet 패키지내에 있는 Filter 인터페이스를 확장하면 된다. 이 필터를 구현 후 doFilter라는 메서드를 오버라이드해 로직을 구현해야한다. doFilter는 세가지 파라미터가 있는데, 첫번째는 ServletRequest. 엔드 유저로부터 오는 HTTP input 요청을 나타냄. 두번째 파라미터는 ServletResponse로 유저나 클라이언트에게 다시보낼 HTTP 응답이다. 세번째 파라미터는 FilterChain으로 정의된 순서대로 실행되는 필터들의 집합을 나타냄.

커스텀 필터를 완성했다면, 그다음단계는 Spring Security FilterChain에 주입하는 것이다. 이걸위한 메서드가 있다.

  • addFilterBefore(flter, class) - 첫번째 파라미터는 커스텀 필터 클래스의 객체, Springboot 내부 필터의이름이다. 이 필터 전에 실행하겠다는 뜻.
  • addFilterAfter(flter, class) - 첫번째 파라미터는 커스텀 필터 클래스의 객체, Springboot 내부 필터의이름이다. 이 필터 후에 실행하겠다는 뜻.
  • addFilterAt(flter, class) - 첫번째 파라미터는 커스텀 필터 클래스의 객체, Springboot 내부 필터의이름이다. 이 필터와 동일한 위치에서 실행하겠다는 뜻.

addFilterBefore과 addFilterAt은 이해가가는데 addFilterAt은 이해가 가지않는다. 필터체인은 한번에 하나의필터만 거치게되는데 어떻게 동일한 위치에서 실행된다는걸까? 지피티에게 물어보니 " addFilterAt 메서드로 필터를 추가할 경우, 동일한 위치에 두 개의 필터가 존재하게 됩니다. 이 경우, Spring Security의 내부적인 필터 등록 순서나 필터의 구성 방식에 따라 실행 순서가 결정될 수 있습니다. 일반적으로, 후에 등록된 필터가 먼저 실행되는 경향이 있습니다. 즉, addFilterAt으로 추가한 CustomFilterUsernamePasswordAuthenticationFilter보다 먼저 실행될 가능성이 높습니다. 그러나 이는 보장된 동작은 아니며, 구체적인 실행 순서는 Spring Security의 버전이나 구현에 따라 다를 수 있습니다. addFilterAt 메서드를 사용할 때는 같은 위치에 여러 필터가 등록될 수 있으며, 이 경우 실행 순서는 내부적인 구현에 따라 결정됩니다. 필터의 실행 순서를 보다 엄격하게 제어하고자 할 때는 addFilterBeforeaddFilterAfter를 사용하는 것이 더 적합할 수 있습니다. 이 방법은 필터의 순서를 더 명확하고 예측 가능하게 관리할 수 있게 도와줍니다."

라고 말한다. 강의에서도 addFilterAt은 무작위로 실행된다고 한다. 실제로 대부분의 프로젝트에서도 addFilterBefore과 addFilterAt를 쓰는 경우는 잘 없다고 한다.



RequestVaildationBeforeFilter(), AuthoritiesLoggingAtFilter(), AuthoritiesLoggingAfterFilter() 라는 커스텀필터를 만들었다면 SecurityConfig에 아래와같이 상황에 맞게 설정해주면 적용된다.

.csrf((csrf) -> csrf.csrfTokenRequestHandler(requestHandler).ignoringRequestMatchers("/contact","/register")
                        .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()))
                        .addFilterAfter(new CsrfCookieFilter(), BasicAuthenticationFilter.class)
                        .addFilterBefore(new RequestValidationBeforeFilter(), BasicAuthenticationFilter.class)
                         .addFilterAt(new AuthoritiesLoggingAtFilter(), BasicAuthenticationFilter.class)
                        .addFilterAfter(new AuthoritiesLoggingAfterFilter(), BasicAuthenticationFilter.class)

어느 커스텀 필터든 시간이 오래걸리는 로직을 사용하지 않는것이 좋다. 모든 요청은 커스텀필터로 인해 걸리지기때문에 성능저하가 될 수 있다.

위처럼 적용하면 Before , At, After순으로 필터가 적용되는걸 확인할수있다.

 

ㅇ 다른 옵션들

위에선 Filter 인터페이스를 구현하고 doFilter라는 메서드를 오버라이딩 했다. 필터인터페이스 말고 다른 옵션을 살펴보자.

  • GenericFilterBean : 추상클래스로, Filter를 구현한다. Spring의 InitializingBeanDisposableBean 인터페이스도 구현하고 있어서, 필터의 초기화와 소멸 단계에서 필요한 작업을 구현할 수 있다. Spring의 빈 생명주기에 맞추어 초기화와 소멸 메서드(afterPropertiesSetdestroy)를 오버라이드하여 사용할 수 있고 Spring의 환경 설정과 DI(Dependency Injection) 기능을 필터에 적용할 수 있어, 필터 구현이 간편하다는 장점이 있다.
  • OncePerRequestFilter : 추상 클래스로, 하나의 요청에 대해 필터가 한 번만 실행되도록 보장한다. 이는 서블릿 필터가 여러 번 실행될 수 있는 문제를 예방하기 위해 사용됨. 디스패처 서블릿을 통해 들어오는 요청에 대해서는 문제가 없으나, 서블릿 필터가 직접 관리되는 요청에서는 필터가 중복으로 적용될 가능성이 있다.

'Java > spring' 카테고리의 다른 글

QueryDsl에 대해 알아보자.  (0) 2024.05.27
spring security를 알아보자 - 12  (0) 2024.04.19
spring security를 알아보자 - 10  (0) 2024.04.15
spring security를 알아보자 - 9  (1) 2024.04.02
spring security를 알아보자 - 8  (0) 2024.03.29