웹 브라우저와 웹 서버의 저장소

Stateless : 불연속성 - 웹 서버 입장에서는 매 요청이 어떤 웹 브라우저가 보낸것인지 알 수없다
Stateful : 연속성 - 웹 서버가 이전에 요청받았던 웹 브라우저와 현재 요청의 웹 브라우저를 구별할 수 있다

HTTP는 Stateless 하기에 웹 서버는 웹 브라우저의 요청이 어떤 유저에 의해 요청된 것인지 알기 위해 응답 반환시 요청자 정보를 함께 반환한다

• 웹 브라우저는 응답을 받아, 응답 헤더에 붙어있던 요청자 정보를 웹 브라우저 쿠키에 저장한다.
• 웹 브라우저는 이후 요청부터 웹 서버에게 요청자 정보를 함께 전달하면, 웹 서버는 누구의 요청인지 알 수 있다

요청자 정보를 어디에 저장하는지에 따라 Cookie 혹은 Session으로 나뉨

• Cookie : 웹 브라우저에 저장
• Session : 웹 서버에 저장(웹 브라우저 쿠키에 세션 ID를 저장하긴 한다)
  • 웹 브라우저에 저장할 수 없는 민감 정보일 경우
  • 웹 브라우저에 저장하기에 너무 크거나, 복합적인 정보일 경우

1. Cookie

웹 서버의 제어 : Set-Cookie 헤더를 통해 웹 브라우저 저장 제어

웹 브라우저가 쿠키를 웹 서버에게 전송하는 기준 : Domain + Path

• 예) 웹 브라우저 내 저장되어있는 쿠키 리스트
  • 1번 쿠키 : h1 = w1(Domain:a.com, Path:*)
  • 2번 쿠키 : h1 = w1(Domain:a.com, Path:/)
  • 3번 쿠키 : h1 = w1(Domain:b.com, Path:/hello)
  • 4번 쿠키 : h1 = w1(Domain:c.com, Path:/world)
• 예) 위 리스트 기반으로 아래 웹 서버에 대한 요청에 따라 전송되는 쿠키 예
  • 웹 브라우저에서 a.com/user/name 호출 시 1번 쿠키 전송
  • 웹 브라우저에서 a.com/ 호출 시 1번쿠키 + 2번 쿠키 전송
  • 웹 브라우저에서 b.com/hello 호출 시 3번 쿠키 전송
  • 웹 브라우저에서 c.com/ 호출 시 어떤 쿠키도 전송하지 않음

웹 브라우저 내 저장

• 쿠키 유효시간 : MaxAge or Expires
  • 명시되어 있다면 : Persistent Cookie(지속쿠키)
  • 명시되어 있지않다면 : Session Cookie(세션쿠키)
    • Session의 의미 : 열고(connect)->닫힘(disconnect)의 하나의 Pair에 모두 사용됨
      • 로그인 세션 : 로그인 한 뒤->로그아웃 하기까지
      • HTTP 세션 : TCP/UDP 연결 후 Request 전송 후 Response 받기까지
      • 브라우저 세션 : 하나의 탭/창이 열리고 닫히기까지

웹 브라우저가 해당 Domain + Path 웹 서버에 요청 시 전달(Stateful HTTP)

• 쿠키 보안 : HttpOnly, Secure, SameSite
  • HttpOnly : JS에서 접근 가능 여부
  • Secure : 패킷 탈취(Man-In-The-Middle) 방지를 위해 HTTPS 요청에 대해서만 전송할지 여부
  • SameSite : 웹 브라우저 주소란에 표시된 도메인과 동일한 도메인에 대한 요청(API)시에만 쿠키 전송
    • 퍼스트파티 쿠키 : 현재 보고있는 페이지의 도메인과 쿠키를 가져온 도메인이 같을때
    • 서드파티 쿠키 : 현재 보고있는 페이지의 도메인과 쿠키를 가져온 도메인이 다를때
    • SameSite 설정
      • Strict : Same Origin 쿠키 전송만 허용
      • Lax(현재 크롬 기본값) : 서드파티 쿠키라도 특수 케이스(GET을 사용하는 요청들)엔 부분 허용
      • None(과거 크롬 기본값) : 서드파티 쿠키 모두 허용
    • 막지 않는다면 CSRF 공격으로 크로스 사이트 요청 시 크로스 사이트에 과거에 설정됐던 쿠키가 전송
      = 크로스 사이트 요청 시, 서드파티(크로스 사이트) 쿠키가 함께 전송된다면 아래의 문제 발생
      • HTTPS 미사용 시 : MITM로 요청을 가로챈다면 서드파티 쿠키를 외부에서 볼 수 있다
      • HTTPS 사용 시 : 서드파티 쿠키가 로그인, 인증 정보를 담고 있다면 admin(관리자) API 호출도 가능
        • 전체 유저 정보 조회, 대량 삭제 등 권한이 필요한 API호출이 인증정보 쿠키로 손쉽게 가능

Cookie 단점

• 쿠키 정보가 웹 브라우저에 저장되다 보니
  • 민감 정보 저장 : 안전하지 않은채로 저장되어있음
  • 웹 브라우저간 공유 불가 : 웹 브라우저 단위의 저장소다보니 지역성 문제
• 쿠키는 Domain+Path일치 시 해당 웹 서버로 모든 쿠키를 담아 보내다보니
  • 쿠키로 저장하려는 정보량이 많아질수록 -> 요청 크기가 커진다
    • 불필요한 Network Overhead : 비대해질수록 요청 사이즈도 커진다
      • 쿠키를 단지 저장소로 사용해선 안되는 이유
    • 웹 서버에게 알려주지 않아도 되는 정보의 경우 웹 스토리지 사용 권장

Cookie와 Storage

Storage는 Cookie, Session처럼 Stateful HTTP를 위한 기술은 아니다

• Storage : 유저에 의해 변경된 옵션 상태 등 필요에 따른 조회가 필요할 때
  • Storage의 종류
    • Local Storage : 웹 브라우저 창이 닫혀도 영구적으로 저장(용량 처리 조심할 것)
    • Session Storage : 웹 브라우저 창이 닫히면 삭제
• Cookie : 웹 서버에게 웹 브라우저가 매번 전달할 특정 정보 전달을 위한 저장소(Stateful)

	Cookie	Storage
저장 가능 용량	4KB	10MB
만료 시간 세부 설정	가능	불가능
범위	지정된 Domain+Path 유효	지정된 Domain 내 모두 유효
보안	노출 제어 가능	스크립트 접근 가능
브라우저간 공유	불가	불가

2. Session

• Session은 웹 브라우저 쿠키에 저장하던 값을 웹 서버측에 저장하기 위해 별개의 저장소 DB가 필요
• 웹 브라우저 내 Cookie에는 어떤 세션인지 알기 위한 Session ID값 저장 필요
  • 웹 브라우저가 실종되면, Session에 저장하고 있는 정보는 시간이 흐름에 따라 삭제 필요
    • 그렇지 않다면 사용되지 않는 정보인데 계속해서 자리를 차지
• Session의 대표적인 예는 웹 브라우저로부터 쿠키로 SESSION_ID를 받아 해당 요청 유저의 정보 조회
  • 속도가 매우 중요 : API 수천번의 호출마다 Session 조회가 필요
    • 메모리 기반 DB인 Redis를 많이 사용

Session의 장점

위에 Cookie의 단점을 뒤집으면 Session의 장점이 된다

• Session은 정보를 웹 서버측에 저장하다 보니
  • 민감 정보들이 웹 서버측에 안전하게 저장되고
  • 웹 브라우저간 공유 가능
• Session은 정보를 웹 서버측에 저장하는 것이기에, 아무리 많은 정보를 저장하더라도 Cookie에 비해 요청을 방해하지 않는다