2024 스파르타 내일배움캠프 Sping 트랙 참여 // day31

Today I Learned

2024 스파르타 내일배움캠프 Sping 트랙 참여 // day31

shinelee26 2024. 11. 13. 23:28

오늘 진행한 학습 요약

1. Spring 숙련 - 2주차

Cookie
- Cookie
- Cookie Header
- Cookie로 로그인 상태 유지
- Cookie 문제점
Session
- Session
- Servlet의 HttpSession
- Spring의 Session
- Session 정보
- Session TimeOut
- Session의 한계
Token
- Token

JWT
- JWT(JSON Web Token)
- JWT 인증
- JWT 장단점
- Access Token, Refresh Token
Filter
- 공통 관심 사항(cross-cutting concerns)
- Servlet Filter
- Filter Interface

2. 알고리즘 코드카다 Day29(작성 생략)

CodingTest Git-hub 링크 : https://github.com/chews26/CodingTest

학습 정리

1. Spring 숙련 - 2주차

Cookie

Cookie
- 사용자의 웹 브라우저에 저장되는 정보로 사용자의 상태 혹은 세션을 유지하거나 사용자 경험을 개선하기 위해 사용
  - HTTP는 Stateless, Connectionless 특성
  - Client가 재요청시 Server는 이전 요청에 대한 정보를 기억하지 못함
  - 로그인과 같이 상태를 유지해야 하는 경우가 발생
  - Request에 사용자 정보를 포함하면 해결
  - 브라우저를 완전히 종료한 뒤 다시 열어도 사용자 정보가 유지
Cookie Header
- Set-Cookie
  - Server에서 Client로 Cookie 전달(Response Header)
- Cookie
  - Client가 Cookie를 저장하고 HTTP 요청시 Server로 전달(Request Header)
- Cookie의 생명주기
  - 1. 세션 Cookie
    - 만료 날짜를 생략하면 브라우저 완전 종료시 까지만 유지
  - 2. 영속 Cookie
    - 만료 날짜를 입력하면 해당 날짜까지 유지
- Cookie의 도메인
  - domain=spartacodingclub.kr를 지정하여 쿠키를 저장
- Cookie의 경로
  - 일반적으로 path=/ 루트(전체)로 지정
- Cookie 보안
  - Secure
    - Secure를 적용하면 https인 경우에만 전송
  - HttpOnly
    - XSS(Cross-site Scripting) 공격을 방지
    - 자바스크립트에서 Cookie 접근을 못하도록 함
    - HTTP 요청시 사용
  - SameSite
    - CSRF(Cross-Site Request Forgery) 공격을 방지
    - 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
Cookie로 로그인 상태 유지
- 한번 로그인에 성공하면 HTTP Response에 쿠키를 담아서 브라우저에 전달
- 브라우저는 요청마다 Cookie를 함께 전송
- 보안상의 문제로 name=곽두팔이 아닌 userId=1과 같은 index 정보를 저장
- 요구사항에 맞추어 세션 Cookie를 사용할지 영속 Cookie를 사용할지 결정
Cookie 문제점
- 쿠키 값은 임의로 변경할 수 있다.
- Cookie에 저장된 Data는 탈취되기 쉽다
- 보안 대처방법
  - 쿠키에 중요한값을 저장하지 않는다.
  - 사용자 별로 일반 유저나 해커들이 알아보지 못하는 값을 노출한다.
  - 토큰은 해커가 임의의 값을 넣어도 동작하지 않도록 만들어야 한다.
  - 해커가 토큰을 탈취해도 사용할 수 없도록 토큰 만료시간을 짧게 설정한다.
  - 탈취가 의심되는 경우 해당 토큰을 강제로 만료시키면 된다.

Session

Session
- 결국 보안 문제를 해결하려면 중요한 정보는 모두 서버에서 저장해야한다.
- Client와 서버는 예측이 불가능한 임의의 값으로 연결해야 한다.
- 서버에서 중요한 정보를 보관하며 로그인 연결을 유지하는 방법
- Session 특징
  - Session을 사용하여 서버에서 민감한 정보들을 저장
    - 예측이 불가능한 세션 ID를 사용하여 쿠키값을 변조해도 문제가 없다.
    - 세션 ID에 중요한 정보는 들어있지 않다.
    - 시간이 지나면 세션이 만료되도록 설정한다.
    - 해킹이 의심되는 경우 해당 세션을 제거하면 된다.
  - Session은 특별한것이 아니라 단지 Cookie를 사용하여 클라이언트가 아닌 서버에서 데이터를 저장해두는 방법
  - Servlet은 Session 을 자체적으로 지원

Servlet의 HttpSession
- Servlet이 공식적으로 지원하는 Session인 HttpSession은 Session 구현에 필요한 다양한 기능들을 지원
Spring의 Session
- Spring에서는 Session을 쉽게 다루도록 @SessionAttribute라는 어노테이션이 제공
Session 정보
- HttpSession은 Session을 간편하게 사용할 수 있도록 다양한 기능을 지원
Session TimeOut
- Session은 logout 기능을 사용하여 session.invalidate(); 가 되어야 삭제되지만 대부분의 사용자들은 로그아웃을 굳이 하지않고, 브라우저를 종료
- Session의 문제점
  - 서버가 브라우저 종료 여부를 판별하지 못한다.
  - 서버에서 Session을 언제 삭제해야 하는지 판단하기 힘들다.
  - JSESSIONID의 값을 탈취 당한 경우 해당 값으로 악의적인 요청을 할 수 있다.
  - 세션은 서버 메모리에 생성되고 자원은 한정적이기 때문에 꼭 필요한 경우만 생성해야 한다.
- Session 생명주기
  - 기본적으로 30분을 기준으로 세션을 삭제
- HttpSession 사용
  - 세션 생성시점 30분이 아닌 서버에 최근 Session을 요청한 시간을 기준으로 30분을 유지한다.
Session의 한계
- Session은 서버의 메모리를 사용하여 확장성이 제한
- 서버가 DB 혹은 메모리에 저장된 세션 정보를 매번 조회하여 오버헤드가 발생
- 서버가 상태를 유지해야 하므로 사용자 수가 많아질수록 부담
- Cookie는 웹 브라우저에만 존재하여 모바일 앱 등의 다양한 클라이언트에서 인증을 처리할 수 없다.
- Scale Out(수평적 확장)에서 서버간 세션 공유가 어렵다.

Token

Token
- Web Application이나 API에서 인증(Authentication)과 인가(Authorization) 과정에서 사용되며 사용자 또는 시스템의 신원과 권한을 증명하고 요청의 유효성을 검증하는 데 사용되는 디지털 문자열
- Token은 서버가 아닌 클라이언트에 저장되어 서버의 부담을 덜 수 있다.
- Token 방식은 Stateless를 기반으로 하여 확장성이 뛰어나다.
- 인증된 사용자임을 확인하기 위한 고유한 서명을 포함하여 위조된 요청인지 확인할 수 있다.
- Token의 단점
  - Cookie/Session 방식보다 Token 자체의 데이터 용량이 많다.
  - Payload(전송되는 데이터)는 암호화되지 않아서 중요한 데이터를 담을 수 없다.
  - Token을 탈취당하면 대처하기 어려워 만료 시간(30분)을 설정한다.

JWT

JWT(JSON Web Token)
- 인증에 필요한 정보들을 암호화시킨 JSON 형태의 Token
- JSON 데이터 포맷을 사용하여 정보를 효율적으로 저장하고 암호화로 서버의 보안성을 높였다.
JWT 인증
- JWT는 Base64로 인코딩되어 쉽게 복호화 할 수 있다.
- Payload가 그대로 노출되기 때문에 비밀번호나 민감한 정보를 저장하지 않는다.
JWT 장단점
- JWT 장점
  - Signature로 서버의 보안성이 증가
  - Token 자체가 필요한 정보(유저 및 검증 정보)들을 모두 가지고 있다.
  - 서버는 인증 정보와 관련된 별도의 저장소를 사용하지 않는다.
  - 서버의 수평 확장성(Scale Out)이 높아진다.
  - Cookie가 없는 다른 환경에서도 인증/인가를 적용할 수 있다.
  - DB를 조회하지 않아도 된다.
- JWT 단점
  - Payload는 암호화 된 것이 아니라 민감한 정보를 다루지 못한다.
  - Token의 길이가 길어서 트래픽이 증가하면 네트워크에 부하가 증가
  - 클라이언트 측에서 Token을 관리하기 때문에 탈취당하면 대처하기 어렵다.
Access Token, Refresh Token
- Token은 클라이언트에서 관리하여 탈취당할 위험성이 높기 때문에 만료 시간 설정이 필요
- 단점을 극복하기 위해 Access Token과 Refresh Token을 사용
- Access Token
  - 사용자 인증 후 서버가 발급하는 유저 정보가 담긴 토큰
  - 유효 기간 동안 API나 리소스에 접근할 때 사용
- Refresh Token
  - Access Token은 보안을 위해 짧은 수명
  - Access Token이 만료된 경우 재발급 받기위해 사용
  - 주로 데이터베이스에 유저 정보와 같이 저장

Filter

공통 관심 사항(cross-cutting concerns)
- 같은 말로 횡단 관심사 라고 하며 여러 위치에서 공통적으로 사용되는 부가 기능
- Filter가 나오게된 이유는 공통 관심사(Cross Cutting Concern)의 처리
- 핵심 기능
  - 비지니스 로직
- 부가 기능
Servlet Filter
- Servlet Filter는 보안, 로깅, 인코딩, 인증/인가 등 다양한 작업을 처리하기 위해 사용
- 1. 공통 관심사 로직 처리
- 2. HTTP 요청 및 응답 필터링
- 3. Filter Chain
- 4. doFilter()
- Servlet Filter 적용
  - Filter를 적용하면 Servlet이 호출되기 이전에 Filter를 항상 거치게된다.
  - 공통 관심사를 필터에만 적용하면 모든 요청 or 응답에 적용
  - Filter는 특정 URL Pattern에 적용할 수 있다.
  - Spring을 사용하는 경우 Servlet은 Dispatcher Servlet이다.
Filter Interface
- Java Servlet에서 HTTP 요청과 응답을 가로채고, 이를 기반으로 다양한 처리 작업을 수행하는 데 사용되는 Interface
- 주요 메서드
  - init()
    - Filter를 초기화하는 메서드이다.
    - Servlet Container가 생성될 때 호출된다.
    - default method이기 때문에 implements 후 구현하지 않아도 된다.
  - doFilter()
    - Client에서 요청이 올 때 마다 doFilter() 메서드가 호출
    - Filter Chain에 따라서 순서대로 doFilter() 를 호출
    - 더이상 doFilter() 를 호출할 Filter가 없으면 Servlet이 호출
  - destroy()
    - 필터를 종료하는 메서드이다.
    - Servlet Container가 종료될 때 호출
    - default method이기 때문에 implements 후 구현하지 않아도 된다.