T_era

1. alg: None 공격취약점: JWT Header의 alg 값 선택 가능성을 악용한다. 서버가 alg: None 처리를 부적절하게 수행할 경우, 공격자는 alg 값을 None으로 설정하여 서명 검증 없이 임의 토큰 발행이 가능하다.대응 방안: 서버는 alg: None을 허용하지 않도록 엄격히 설정한다. 허용된 암호화 알고리즘만을 처리하도록 구현한다.2. 쉬운 디코딩취약점: JWT는 Base64 URL 인코딩을 사용하므로 디코딩이 용이하다. Payload에 민감 정보를 포함할 경우 정보 유출 위험이 증대된다.대응 방안: Payload에 민감한 개인 정보 또는 중요 데이터를 포함하지 않는다. 필요한 정보는 암호화하거나 서버 측 저장소에 보관하고, 토큰에는 식별자만 포함하는 방식을 고려한다.3. Secr..

JWT 인증 과정클라이언트는 로그인을 요청한다.로그인 성공 시 서버는 Header, Payload, Secret Key를 이용하여 Signature를 생성하고, 이를 Base64로 인코딩하여 JWT를 발급한다. 발급된 JWT는 통상적으로 Cookie에 담아 클라이언트에게 전달된다.클라이언트는 발급받은 JWT를 저장하고, 서버에 요청 시 Authorization Header에 JWT를 담아 전송한다. (일반적으로 "Bearer [JWT]" 형식)서버는 수신한 JWT의 유효성을 검사한다. 이는 JWT 만료 여부 및 위변조 여부(Signature 검증)를 포함한다. 유효성 검사를 통과하면 인증된 사용자로 간주하고 요청을 처리한다.JWT 유효성 검사 상세악의적 사용자 B가 정상 사용자 A의 JWT를 탈취하여 임..

Token 사용 이유서버 부담 경감: Token은 서버가 아닌 클라이언트에 저장되므로 서버 저장 공간 부담을 줄인다.다양한 클라이언트 지원: Cookie와 달리 웹 브라우저 외 모바일 앱 등 다양한 환경에서 인증 처리가 가능하다.높은 확장성 (Stateless 기반): 각 요청이 필요한 모든 정보를 포함하므로 서버는 이전 요청 상태를 기억할 필요가 없는 Stateless 방식으로, 서버 확장에 유리하다.위조 방지: Token은 고유 서명을 포함하여 인증된 사용자인지, 요청이 위조되지 않았는지 확인할 수 있다.Token 작동 순서Token 생성 시 사용자 고유 정보를 포함한다.데이터베이스 접근 없이 Token 자체의 서명 및 만료 시간 검증을 통해 유효성을 판단한다.Token의 단점데이터 용량 증가: Co..

Cookie정의: 웹 브라우저에 저장되는 작은 데이터 조각.생명주기: 세션 쿠키 (브라우저 종료 시까지), 영속 쿠키 (만료일 설정 가능).도메인: Cookie가 적용될 웹사이트 범위 지정.보안:Secure: HTTPS에서만 전송.HttpOnly: JavaScript 접근 차단 (XSS 방지).SameSite: 요청 도메인과 Cookie 도메인 일치 시 전송 (CSRF 방지).사용 예시: 로그인 상태 유지 (userId Cookie 생성 및 활용), 로그아웃 시 Cookie 만료.Session정의: 서버 측에서 사용자 상태를 유지하는 방식.동작: 로그인 성공 시 서버가 Session ID를 생성하여 Cookie로 클라이언트에게 전달. 클라이언트는 매 요청 시 Session ID Cookie를 서버에 전송..

일부에서 스프링 개발 시 Validation과 예외 처리를 함께 하지 말라는 주장이 제기된다. 이는 Validation 로직과 예외 처리 로직의 관심사 분리를 강조하는 것으로 이해해야 한다.1. 관심사의 분리 원칙Validation: 입력 데이터의 유효성을 검증하는 고유의 역할 수행. 데이터 형식, 길이, 필수 여부 등을 확인한다.예외 처리: 애플리케이션 실행 중 발생하는 예외 상황에 대한 대응 및 사용자 피드백 제공을 담당한다.각각의 책임 영역을 분리함으로써 코드의 명확성 및 유지보수성을 향상시킬 수 있다. 또한, Validation 로직의 재사용성을 높이는 이점이 존재한다.2. "함께 하지 말라"는 주장의 의미Validation 실패 시 발생하는 예외를 애플리케이션 로직 내에서 직접 처리하는 방식을 ..

@Transactional 어노테이션 정리주요 목적:하나의 논리적인 작업 단위 (Unit of Work) 정의해당 작업 단위 내의 여러 데이터 접근 작업을 원자적으로 (Atomically) 관리성공 시 커밋 (Commit): 모든 작업 성공 시 데이터베이스에 변경 사항 반영실패 시 롤백 (Rollback): 하나라도 실패 시 모든 변경 사항 이전 상태로 복구 (데이터 일관성 유지)예시:@Transactional 적용 메서드 내 2개 이상 DB 연산 시, 전체 성공 시 커밋, 하나라도 실패 시 전체 롤백적용 위치:Service 계층 (일반적): 여러 데이터 접근 로직을 묶어 트랜잭션 관리 (예: 스케줄 생성 시 스케줄 저장 + 사용자 정보 업데이트)핵심 원리:원자성 (Atomicity): DB 연산을 불가..

프로젝트를 작성하면서 sql을 사용할 때 두 sql의 결과가 다르게 나온다1. String sql = "SELECT " + attributeName + " FROM user WHERE user_id = ?", userId;2. String sql = "SELECT ? FROM user WHERE user_id = ?", attributeName, Key;위의 코드 중 1번만 제대로 작동한다물론 둘다 좋은 예가 아니다왜그럴까? 문제점:SQL Injection 위험:attributeName 변수는 외부로부터 입력받거나 동적으로 생성될 수 있습니다.만약 attributeName에 악의적인 SQL 코드가 포함된다면, 쿼리 실행 시 해당 코드가 그대로 실행되어 데이터베이스가 손상되거나 정보가 유출될 수 있다.예를..

@Valid와 BindingResult는 Spring Framework에서 데이터 유효성 검증을 처리하는 데 핵심적인 역할을 하는 어노테이션과 인터페이스이 둘은 밀접하게 연관되어 함께 사용되며, 컨트롤러에서 클라이언트로부터 받은 데이터를 검증하고 그 결과를 처리하는 데 활용된다.1. @Valid 어노테이션:역할: @Valid 어노테이션은 컨트롤러의 메서드 파라미터에 적용되어 해당 파라미터로 전달되는 객체에 대해 유효성 검증을 수행하도록 Spring에게 지시적용 대상: 주로 @RequestBody, @ModelAttribute 등으로 바인딩되는 객체에 적용동작 방식:@Valid가 적용된 객체가 컨트롤러 메서드에 전달되기 전에, Spring은 해당 객체에 설정된 **유효성 검증기(Validator)**를 찾..

Service계층에서는 비지니스 로직 Repository계층에서는 데이터 관리를 하는게 일반적이다근데 데이터를 전체 조회할 때 반복문을 사용해 데이터를 가져오는 과정을 설계했을 때 이 반복문은 어디에 들어가는게 합리적일지 궁금해서 알아보았다Data Access Layer (Repository Layer)의 책임데이터를 관리하는 역할여러 개의 레코드를 조회하는 것은 데이터 접근 계층의 기본적인 기능에 해당반복문을 사용하여 여러 개의 데이터를 조회하고 이를 리스트 형태로 만드는 작업은 데이터베이스와의 통신 및 데이터 변환 로직이므로 Repository Layer에서 처리하는 것이 자연스럽다Business Layer (Service Layer)의 책임비즈니스 로직을 수행하는 역할조회한 여러 개의 데이터를 기반..

Layered Architecture (계층형 아키텍처)Layered Architecture는 애플리케이션을 Presentation Layer, Business Layer (Service Layer), Data Access Layer (Repository Layer) 세 가지 주요 계층으로 분리하여 구조화하는 방식이다. 각 계층은 특정 책임을 가지며, 계층 간 명확한 역할 분담을 통해 코드 재사용성, 유지보수성, 확장성을 확보한다.MVC 패턴의 한계기존 MVC 패턴에서 Controller는 요청 처리, 예외 처리, View Template 또는 Data 응답, 비즈니스 로직 처리, DB 상호작용 등 다양한 역할을 수행하여 책임이 과중해진다. 이는 유지보수 어려움, 코드 재사용성 저하 등의 문제점을 야기한..