IT LAB

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

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

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

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

* 이전 포스팅에서 다루었던 JWT 토큰 기반 인증의 구현에 대한 포스팅입니다 0. Dispatch Type서블릿 기반의 웹 애플리케이션에서 사용되는 개념서블릿이나 필터가 어떤상황에서 요청을 처리하는 지 나타냄Type설명주요 사용 상황관련 메서드/상황REQUEST클라이언트로부터 직접 들어온 요청브라우저에서 URL 입력 또는 링크 클릭일반적인 요청 처리FORWARD서버 내부에서 다른 리소스로 요청 전달다른 서블릿이나 JSP로 제어를 넘길 때RequestDispatcher.forward()INCLUDE다른 리소스의 내용을 현재 응답에 포함공통 헤더, 푸터, 메뉴 포함 등RequestDispatcher.include()ASYNC비동기적으로 처리되는 요청서블릿 3.0 이상에서 비동기 처리startAsync() ..

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

1. AccessToken인증된 사용자가 자원 서버에 보안 리소스를 요청할 떄 인증을 대신하는 권한 토큰항목설명클레임 (Claims)- 인증 외의 부가 정보 저장- 사용자 정의 클레임 추가 가능 (예: IP, 기기 정보 등)유효기간 (Expiration)- 보안을 위해 짧게 설정 (예: 1시간)- 노출 시에도 장시간 사용 방지 목적- 만료 시 토큰은 무효 처리되고, 재요청 필요 2. RefreshTokenAccessToken 갱신용 토큰AccessToken이 만료될 때, 새로운 AccessToken을 요청하기 위한 토큰항목설명사용자 경험 향상- Access Token 만료 시 재로그인 없이 자동 재발급 가능- 사용자 인증 요청을 줄여 UX 개선유효기간- Access Token보다 긴 유효시간을 가짐 (보..

1. JWTJSON 형식의 표준 토큰 (RFC 7519)URL의 일부 혹은 HTTP 헤더에 포함시켜 토큰을 전달합니다. 특징항목설명경량성- 구조가 간결하고 크기가 작음→ 제약된 환경에서 효율적으로 사용 가능 (모바일, IoT 등)보안성- 데이터 무결성: 서명 포함 → 위조 여부 검증 가능 (알고리즘: HMAC, RSA)- 암호화: 민감한 데이터 보호자급자족(Self-contained)- 필요한 정보를 토큰 내에 포함 가능- 서버가 별도의 세션/DB 상태를 유지할 필요 없음 2. 구성구성 요소설명구성상세 정보Header토큰의 메타데이터alg: 서명에 사용된 알고리즘typ: 토큰 타입 (보통 "JWT")- HS256(HMAC + SHA-256): 하나의 비밀키로 서명+검증 수행- RS256(RSA + SHA..

1. 로그아웃 아키텍쳐Spring Security는 기본적으로 로그아웃 기능을 지원함소제목설명GET /logout- 로그아웃 확인 페이지 제공- CSRF 토큰 포함 가능※ CSRF 비활성화 시 확인 페이지 없이 바로 로그아웃POST /logout- 로그아웃 처리 동작 수행① SecurityContextLogoutHandler: 세션 무효화② SecurityContextLogoutHandler: SecurityContext 제거③ TokenRememberService: RememberMe 제거④ CsrfLogoutHandler: CSRF 토큰 제거⑤ LogoutSuccessEventPublishingLogoutHandler: LogoutSuccessEvent 발행→ /login?logout 으로 리디렉션됨..

1. PasswordEncoder비밀번호 암호화를 담당하는 객체 one-way hashing한 번 해싱하면 원래 입력값으로 되돌릴 수 없음 (복호화 불가)항목설명목적비밀번호를 안전하게 저장하기 위함인증 방식입력된 비밀번호를 해싱하여, DB에 저장된 해시값과 비교장점원문 비밀번호를 저장하지 않으므로 데이터 유출 시 위험 최소화 2. Password Storage History구분설명문제점 / 대응초기 보안 처리비밀번호를 평문으로 저장DB 접근 제어 기능에 의존계정 정보 탈취 위험- SQL Injection: 입력값 공격단방향 해싱 도입단방향 해시 함수 사용 (해시값은 복호화 불가능)→ 입력 비밀번호를 해시하여 저장된 값과 비교사전 공격 가능성 존재- 레인보우 테이블: 다양한 해시값을 미리 계산해둔 테이블S..