Stateless는 각 프로세스가 시작과 닫음으로 동작하기 때문에, 프로세스 간의 정보 공유가 없다. 때문에 웹 서버 입장에서는 매 요청이 어떤 웹 브라우저가 보낸 것인지 알 수가 없다.
Cookie와 Session으로 Stateful HTTP를 만들 수 있다
웹 서버가 각 웹 브라우저가 누군지 이름표를 붙이기 위해 쿠키와 세션을 사용한다. 가장 처음, 웹 브라우저가 웹 서버에 요청을 보내면 응답과 함께 요청자의 정보(요청한 웹 브라우저)를 반환한다.
웹 브라우저는 이를 요청자 웹 브라우저의 쿠키에 저장한다. 이후부터 웹 브라우저는 서버에 요청을 보낼 때 쿠키에 저장되어 있는 요청자 정보를 헤더에 함께 전달해 "내가 누군지" 알려주며 요청을 보낸다.
이때, 2번에서 웹 서버가 웹 브라우저에게 최초로 요청자 정보를 전달해줄 때 헤더인 Set-Cookie로 전송해준다.
Cookie
웹 서버의 제어로 웹 브라우저에 저장되된다. 즉, 어떤 "요청"인지는 REST API를 통해 알 수 있고, "누가" 요청을 보냈는지는 Cookie(또는 Session)로 알 수 있는 것이다.
쿠키의 저장소
쿠키는 웹 브라우저에 저장된다. 어떤 값이든 가능하고, 일반적으로 노출 방지를 위해 인간이 이해할 수 없는 형태다. 쿠키는 크기가 크면 클수록 요청하는 양이 많고, 네트워크 overhead가 발생할 수 있다.
쿠키 사용의 기준
웹 서버로부터 최초로 요청자 정보를 저장한 웹 브라우저가 웹 서버에게 전송하는 기준이다. 즉, 해당 쿠키를 어떤 요청에 보낼 것인가? 그 기준은 도메인이다.
예를 들어 다음과 같이 웹 브라우저 쿠키가 저장되어 있다고 가정한다.
h1 = w1(Domain: a.com, Path: /hello)
웹 브라우저에서 a.com/hello를 호출하면 웹 서버에 h1 쿠키와 함께 전송된다.
중요한 점은, `/`와 같은 Path만 해당되며 ?와 = 같이 query는 해당하지 않는다.
쿠키의 유효시간
만약 쿠키의 유효 시간이 명시되어 있다면 Persistent Cookie라고 부른다. MaxAge 또는 Expires가 다 차지 않는 이상 계속 지속되기 때문이다.
명시되어 있다면 Session Cookie라 칭하는데, 세션의 특성 상 열고 닫는 순간 세션 쿠키는 사라진다.
Session 열고(connect) 닫힘(disconnect)의 하나의 Pair 예를 들어 로그인 세션(로그인 한 뒤에 로그아웃 까지), HTTP 세션(TCP/UDP 연결 후 request 전송 및 Response 받기 까지), 브라우저 세션(하나의 탭/창이 열리고 닫히기까지)
쿠키의 보안
일반적으로 웹 서비스를 제공할때 사용자들의 행동 패턴을 분석하기 위해 분석 도구를 사용한다. 그러려면 해당 고객의 행동 패턴을 기록해야 하는데, 그 때 사용하는 것이 google analytics API다.
보통 웹 페이지가 로드 될 때 HTML에 있는 <script> 태그 내에 포함된 Google Analytics의 JS 코드가 실행된다. 그 후 사용자가 어떤 이벤트를 발생하면(클릭이라든지, 폼 제출이라든지) 해당 정보를 GA 서버로 전송한다.
또한 GA는 사용자의 브라우저에 쿠키를 설정한다. 어떤 사용자가 서비스를 어떻게 이용하는지, 또한 재방문시에 사용자를 식별하고 세션을 추척하는데에도 사용한다.
이것이 쿠키의 본질이다. 웹 서버가 해당 방문자를 식별할 수 있고, 그것을 활용하는 것.
CSRF (Cross-Site Request Forgery)
엡 보안 취약점 중 하나로, 공격자가 사용자의 의도는 무관하게 사용자가 이미 인증된 웹 애플리케이션에 대해 원치 않는 작업을 수행하도록 만드는 공격이다.
간단히 정리해서 은행 사이트가 있다고 가정한다면, 궁금증을 유발하는 광고 이미지를 사용자에게 어필한다. 사용자가 그 광고를 클릭하면 사용자 정보(쿠키)와 함께 의도된 요청을 웹 서버에게 전송한다. 그러면 웹 서버는 전에 있던 요청자가 맞으니 원래 본 사용자가 요청한 내용이 아님에도 의도된 요청을 수행하게 된다.
이렇다보니 위와 같은 CSRF가 나타날 수도 있다. 이를 위한 3가지 보안 방법이 존재한다.
1. Http Only
XSS(자바스크립트) 공격에 의한 쿠키 접근을 제어한다. 즉, JS에서 쿠키를 접근할 수 없게 만들어버린다.
2. Secure
패킷 탈취를 예방하기 위해 HTTP가 아닌 HTTPS에서만 사용하는 것이다.
3. SameSite
웹 브라우저 주소란에 표시된 도메인과 동일한 도메인에 대한 요청(API)시에만 쿠키를 전송하도록 만든다.
만약 이런식으로 막지 않는다면 위에서 언급했던 CSRF 공격으로 크로스 사이트 요청 시 과거에 설정됐던 쿠키가 전송되어 의도된 요청을 보내게 된다.
보통 쿠키는 퍼스트파티 쿠이와 서드파티 쿠키로 나뉜다.
퍼스트파티 쿠키는 site Domain과 cookie Domain이 일치하는 것, 서드 파티 쿠키는 site Domain과 cookie Domain이 일치하지 않는 쿠키를 말한다. 많은 홈페이지들을 오가며 공통된 작업을 수행하는 Google Ads 광고 정보 등이 예로 있다.
서드 파티 쿠키는 위험할 수 있다. HTTPS를 사용하지 않을 때 쿠키를 탈취할 수 있기 때문이다.
아무튼 SameSite를 설정할 수 있는 방식은 3가지가 있다.
Strict 퍼스트파티 쿠키 전송만 허용한다. 즉, 쿠키 도메인과 사이트 도메인이 일치할 때만 쿠키를 전송할 수 있으므로 가장 보안성이 뛰어나다고 생각할 수 있다.
Lax 서드파티 쿠키라도 특수 케이스(GET, <a href>, <link>)에는 부분 허용한다. 보안 업데이트 후 최신 크롬의 Default 값이며, 우리가 어떤 웹 사이트를 방문했을 때 쿠키 허용 여부를 물어보는 이유와 같다.
None 서드파티 쿠키를 모두 허용한다. (하지만 Secure 설정은 강제된다.) 기존 크롬의 Default였으며 CSRF 요청에 가장 취약한 방식이다.
쿠키의 단점
쿠키는 웹 브라우저에 저장된다. 그렇기 때문에 안전하지 않은 채로 민감 정보를 저장하게 될수도 있고, 또 각 클라이언트(웹 브라우저)에 저장되다 보니 웹 브라우저 간 공유 불가라는 지역성 문제가 존재한다.
또한, Domain과 Path 일치 시에 해당 웹 서버로 모든 쿠키를 담아 보내니 쿠키를 저장하려는 정보량이 많아질수록 요청 크키가 커질 수밖에 없다. 네트워크 overhead가 발생하기 때문에 쿠키를 단지 저장소로 써서는 안 된다.
그러면 Storage를 서볼까
HTML5 표준에서 Storage 등장 전에는 웹 브라우저 저장소는 유일하게 Cookie였다. 하지만 앞선 단점들이 존재했고 그에따라 Storage가 등장했다. 웹 브라우저에서 필요에 따른 조회가 필요할 때, 판단해야 할 정보를 대신 전달할 때 나눠서 사용할 수 있다.
(FE가 웹 브라우저 안에서 잠깐 저장해놨다가 쓰고 싶은 값들을 저장하기 위한 공간)
예시로는 유저에 의해 변경된 옵션 상태가 있다. 필요에 따른 조회가 필요한 경우다! (마지막에 어떤 소셜 계정으로 로그인했는지 저장하고, 1년 뒤 로그인할 때 알려주기)
Local Storage
웹 브라우저 창이 닫혀도 영구적으로 저장된다. 길게 저장해도 되는 경우 사용한다. 앞서 예시로 들었던 로그인 정보가 해당된다.
Session Storage
웹 브라우저 창이 닫히면 삭제된다. 단발적이지만 중요한 내용을 저장할 때 사용한다.
Cookie vs Storage
_**이 Storage 는 Cookie, Session 처럼 Stateful HTTP 를 위한 기술은 아니다.
쿠키는 웹 서버에 반복적으로 전달하고, 작은 정보를 전달하며 세부 만료 설정이 가능하다. Storage는 웹 브라우저에서만 사용하고 쿠키보다 큰 정보를 사용하며, 세부 만료 설정을 할 수 없다.
또한, Storage는 Cookie, Session처럼 Stateful HTTP를 위한 기술이 아니라는 점을 명심하자.
Session
Session은 웹 브라우저 쿠키에 저장하던 값을 웹 서버측에 저장하기 위해 별개의 저장소 DB가 필요하다.
하지만 Session을 사용하다고 해서 Cookie를 사용하지 않는 것은 아니다. 각자의 장점을 활용해서 사용하면 된다.
웹 브라우저 내 Cookie에는 어떤 세션인지 알기 위한 ID값 저장이 필요하다. 웹 브라우저가 실종되면 Session에 저장하고 있는 정보를 시간이 흐름에 따라 삭제가 필요하다. 사용하지 않는 정보인데 자리를 차지하게 둘 수 없기 때문.
Session의 가장 대표적인 예는 웹 브라우저로부터 쿠키로 SESSION_ID를 받아 해당 요청 유저의 정보를 조회하는 것이다.
Session은 매번 WB 측에서 확인해야 하기 때문에 속도가 매우 중요하다. API 수천번의 호출마다 Session 조회가 필요하다.
쿠키의 단점과 세션의 장점?!
앞서 쿠키의 단점 2가지가 있었다. 민감 정보 저장, 웹 브라우저간 공유 불가.
Session은 정보를 웹 서버측에 저장하니 민감 정보가 웹 서버측에 안전하게 저장되고, 웹 브라우저 간 공유도 가능하다. 또한 쿠키는 웹 서버로 모든 쿠키를 담아 보내니 요청의 크기가 커질 우려로 웹 스토리지 사용이 권장되지만, Session은 웹 정보를 서버에 저장하기 때문에 요청을 방해받지 않는다. (단, 매 요청마다 Session Storage 조회가 필수다.)
