Spring 115

[Spring Boot] 1-1. Spring Boot 사용하기

1. Build SystemSpring Boot는 의존성 관리를 위한 build system을 선택하여 사용할 수 있습니다. build system은 repository에 있는 공개된 artifact들을 가져오는 기능을 지원합니다.Spring Boot에서는 Maven, Gradle이 자주 사용됩니다.Ant, lvy 등도 지원되지만 기능이 제한되어 있습니다. Dependency Management각 Spring Boot 버전별로 사용하는 의존성의 버전을 큐레이션 해 두었습니다.각 Spring Boot 버전은 특정 Spring 버전을 바탕으로 두고 있습니다.Spring Boot 버전이 올라가면 해당 버전의 적절한 의존성 버전이 제공됩니다.사용자는 Spring Boot 버전별 의존성에 대한 버전을 따로 지정하..

Spring/Spring Boot 2023.10.07

[Spring Security] 4-1. 보안: CSRF

1. CSRF 공격이란? 위조된 사이트에서 클릭을 통해 사용자가 의도하지 않은 요청을 특정 사이트로 전송하는 공격입니다. 공격자가 피해자의 웹 브라우저를 통해 웹 사이트에 대한 위조된 요청을 생성하는 공격입니다. 의도하지 않은 요청에 대한 인증은 브라우저의 쿠키정보를 사용하여 통과합니다. 사용자의 쿠키정보가 브라우저에 남아있는 점을 이용합니다. example 사용자가 은행 웹사이트에서 이체 거래를 마쳤습니다. 사용자는 메일 확인중, 모르는 자로부터 링크가 담긴 메일을 받았습니다. 사용자는 경각심없이 메일의 링크를 클릭하였습니다. 링크를 통해 이동한 웹 페이지에는 클릭만 하면 상품을 준다는 버튼이 있었습니다. 사용자는 클릭을 하였습니다. 이 버튼은 이전에 사용자가 사용했던 은행 웹사이트로 송금을 요청하는 ..

[Spring Security][KoLiving] 4-5. BlackList Token

BlacklistToken 시스템은 AccessToken의 보안 취약성을 보완하는 방법입니다. AccessToken은 짧은 유효기간으로 설정되도록 설계되어 탈취되더라도 오랫동안 사용할 수 없습니다. 그러나 그 기간동안 악의적인 공격자로 인해 피해를 받는 것은 사실이며 짧은 기간내에도 큰 피해를 줄 수 있습니다. 이러한 위험으로부터 보호하기 위해 유효하지 않은 AccessToken를 무효화하기 위해 도입되었습니다. 1. 인증 시 검증 절차로 확인 @Slf4j @RequiredArgsConstructor public class JwtAuthenticationFilter extends OncePerRequestFilter { private final JwtProvider jwtProvider; private ..

[Spring Security][KoLiving] 4-4. RefreshToken Rotation

* 이전 포스팅의 시리즈입니다. 3. RefreshToken Rotation RefreshToken Rotation은 RefreshToken 의 보안 취약점을 최소화하는 기법입니다. 만약 RefreshToken가 탈취되었다면, 서버는 RefreshToken 사용자가 악의적인 사용자인지 식별할 수 없습니다. RefreshToken Rotation은 이러한 취약점을 보완하고자 도입되었습니다. 클라이언트가 새로운 AccessToken을 요청할 때마다 RefreshToken도 함께 새로 발급해주는 방식을 말합니다 RefreshToken를 통해 AccessToken를 새로 발급받을 경우 만약 AccessToken을 요청할 때마다 RefreshToken을 새로 발급하게 되면 공격자가 RefreshToken를 새로 ..

[Spring Security][KoLiving] 4-3. RefreshToken

RefreshToken는 AccessToken을 재발급 받기 위한 토큰입니다. 노출되면 여러 문제가 발생하므로 보안에 각별히 주의해서 관리해야 하는데요. 구현하면서 어느 지점에서 어떻게 쓰이고 관리하는지 포스팅하겠습니다. 1. 최초 생성 보안을 강화하고 발급한 AccessToken을 효과적이고 중앙 집중적으로 관리하기 위해 RefreshToken을 저장합니다. 회원가입 완료 후 Redis에 저장됩니다. Redis는 다른 클라우드 인스턴스에 위치하여 클러스터로 구성합니다. Hash 자료구조에 {email : RefreshToken} 형식으로 저장합니다. RefreshToken 유효기간을 TTL로 설정합니다. 2. AccessToken 만료 사용중인 AccessToken이 만료된다면, RefreshToken..

[Spring Security][KoLiving] 4-2. JwtProvider

이전 포스팅에서 JwtAuthenticationFilter는 OncePerRequestFilter를 확장하여 구현하였습니다. JwtAuthenticationFilter 필터를 생성할 때 인증 작업을 AuthenticationManager에 위임해야 하나 말아야 하나 고민했습니다. AuthenticationManager는 Filter들의 인증을 담당하는 Spring Security의 중요 컴포넌트입니다. AuthenticationManager에 인증을 위임하게 될 경우 Spring Security의 인증 메커니즘 통합이 가능하여 확장성이나 유연성이 좋아집니다. 하지만 저는 AuthenticationManager에 위임하지 않고 직접 구현하였습니다. JWT는 이미 잘 정의된 표준을 가지고 있으므로 표준을 준..

[Spring Security][KoLiving] 4-1. JwtAuthenticationFilter

* 이전 포스팅에서 다루었던 JWT 토큰 기반 인증의 구현에 대한 포스팅입니다 0. Dispatch Type 서블릿 기반의 웹 애플리케이션에서 사용되는 개념으로 서블릿이나 필터로 전달될 때 요청이 어떤상황에서 처리되는 지를 나타냅니다. REQUEST 클라이언트로부터 웹 애플리케이션에 직접 요청이 들어올 때 처리되는 타입입니다. 브라우저에서 URL이나 링크를 클릭할 떄 발생하는 요청 FORWARD RequestDispatcher의 forward() 메서드를 사용하여 특정 리소스로 요청을 전달할 때 사용되는 타입입니다. 다른 서블릿이나 JSP로 넘겨 처리할 수 있습니다. INCLUDE RequestDispatcher의 include() 메서드를 사용하여 현재 처리 중인 요청에 다른 리소스의 내용을 포함할 때..

[Spring Security][KoLiving] 4. JWT 토큰 기반 인증

* 이전 포스팅에서 다루었던 JWT 토큰 설명을 참고해주세요 인증 시스템을 개발하면서 사용해야 할 기술을 정하는 중에 세션과 토큰 두개의 선택지가 있었습니다. 장점 단점 세션 - 서버에서 사용자 세션을 제어할 수 있다 - 서버에서 사용자 세션 관리를 위한 자원소모가 크다. - 세션 유지로 인해 서버의 확장성에 제약이 생길 수 있다. 토큰 - 서버의 확장성에 제약이 없다. - 플랫폼간의 인증방식을 일관되게 관리할 수 있다. - 여러 서비스간의 통합 인증이 용이하다. - 토큰이 탈취되면 클라이언트의 연결을 제어할 수 없다. - 사용자 세션을 제어할 수 없다 저희는 '토큰' 기반으로 인증을 구현하기로 결정하였습니다. '토큰' 기반의 장점과 단점을 고려하여 시스템 구현 방향을 설정하였습니다. KoLiving은 ..

[JWT] 2. AccessToken과 RefreshToken

1. AccessToken권한 토큰보안 리소스를 접근하고자 하는 유저에게 부여사용자 정의 클레임을 두어 사용할 수 있습니다. (IP 등) 유효기간보안상 을 짧은 시간으로 설정 (1시간)공격자에 의해 노출되더라도 오랜시간 사용하지 못하게 하기 위함입니다.만료 시, 재요청이 필요합니다 (만료되면 효과가 없습니다.) 2. RefreshToken권한 토큰 갱신AccessToken이 만료될 때, 새로운 AccessToken을 요청하기 위한 토큰입니다. 유효기간AccessToken과 다르게 긴 유효시간을 가집니다. 사용자 경험 향상주기적인 AccessToken 발급에 대한 사용자 인증 요청을 줄일 수 있음AccessToken이 만료되면, 클라이언트는 새로운 AccessToken을 받기위해 인증서버에 새로운 요청을..

[JWT] 1. JWT Token

1. JWTJSON 형식의 토큰 표준입니다. (RFC 7519)URL의 일부 혹은 HTTP 헤더에 포함시켜 토큰을 전달합니다. 특징경량성간결하고 크기가 작음제약된 환경에서 정보를 간단하게 전달하는데 사용됨 보안성서명된 토큰무결성 보장: 정보가 위조되지 않았음을 검증할 수 있음Algorithm: HMAC, RSA 데이터 암호화 가능 (민감데이터 보호) 자급자족필요한 정보를 자체적으로 포함하고 있음서버측에서 별도의 상태를 유지할 필요가 없음서버는 토큰의 클레임 정보를 통해 별도의 데이터베이스 조회 없이 요청을 처리할 수 있음 2. 구성{ { "alg": "HS256", "typ": "JWT" }, { "sub": "1234567890", "name": "Jo..