[ASAC 06] 웹 저장소 (쿠키, 세션, 웹 스토리지)

이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다. 

HTTP

HTTP는 Stateless하다는 특징을 가지고 있는 프로토콜이다. Stateless하다는 것은 어떤 웹사이트가 요청한 것인지 식별할 수 없는 것이다.
Stateless하게 관리되는 이유는 최소한의 자원으로 서버 유지를 가능케 하기 위함이다. 이처럼 서버는 HTTP 통신 자체만으로는 클라이언트를 식별할 수 없기 때문에 추가적인 도구들을 사용해야 한다. 그 도구들이 바로 쿠키와 세션이다.

Stateful HTTP : Cookie & Session

쿠키와 세션을 사용해 HTTP 통신의 상태 유지가 가능하다. 웹 서버는 웹 브라우저의 요청이 어떤 유저에 의한 요청인지 구분하기 위해 응답 반환 시 요청자 정보를 함께 반환하며, 요청자 정보가 담기는 곳이 바로 쿠키이다.
쿠키 설정을 위해서 HTTP 헤더를 사용한다.

• 서버 -> 브라우저 : Set-Cookie 헤더
• 브라우저 -> 서버 : Cookie 헤더

웹 서버는 HTTP 요청이 들어오면 REST API가 method + URI의 구조를 가지기 때문에, 어떤 요청인지는 알 수 있다.
그러나 Stateless하기 때문에 누가 요청한 지는 알 수 없다.

=> Set-Cookie 헤더에 요청자 정보를 담아서 응답을 반환하면 Stateful하게 통신이 가능하다.

Session : 웹 서버에 저장

세션에는 다음과 같은 정보들이 담기며, 웹 서버에 저장된다.

• 웹 브라우저에 저장할 수 없는 민감 정보
• 웹 브라우저에 저장할 수 없을 정도로 크거나 복합적인 정보

Cookie : 웹 브라우저에 저장

쿠키에는 민감하지 않은 정보들이 담기며, 웹 브라우저에 저장된다. 웹 서버-웹 브라우저 통신에서 일종의 전달 바구니 역할을 하게 된다.

• 노출 방지를 위해 인간이 이해할 수 있는 형태가 아닌 것으로 (ex. 인코딩된 데이터)

세션과 관련한 경우 다음과 같은 절차들을 거치게 된다.

1. 세션 정보는 서버에 저장되고, 세션 ID만 쿠키에 담아서 브라우저로 전달한다.
2. 브라우저는 브라우저 Cookie에 Set-Cookie에 담겨진 값을 저장한다.
3. 이후에 Cookie 헤더에 Cookie 값을 담아서 요청하면, 서버는 Cookie 헤더에 담긴 세션 ID를 가지고 세션 정보와 비교한다.

주의 : 쿠키 != 웹 스토리지

Cookie : 웹 브라우저 저장소 1

쿠키 사용의 기준 : Domain + Path

웹 브라우저에는 특정 페이지에 대한 쿠키 정보를 모두 가지고 있다.
웹 브라우저가 쿠키를 웹 서버에게 전송하는 기준 (전송할지, 말지) = 해당 쿠키를 어떤 요청에 보낼지?
구분하는 기준은 => Domain + Path이다.

• 특정 Domain + Path에 설정된 쿠키는, SubPath에도 모두 전송된다.
• 모든 Path에 대해서 쿠키를 적용하기 위해서는 *가 아닌 /를 사용한다.
• ex1) Path가 /이면, /user, /payment, /cart 모두에 쿠키가 전송됨.
• ex2) Path가 /user이면, /user/1, /user/profile 모두에 쿠키가 전송됨.
• Path는 Case Sensitive하다.

쿠키 세부 설정, 옵션

웹 서버가 key=value 형식으로 쿠키에 정보를 담고 세부 설정들을 하여 전송하면, 웹 브라우저가 쿠키를 저장한다.
즉, 설정 = 서버가, 저장 = 브라우저가.

• Domain
• Path
• Expires
• HttpOnly
• 보안 설정

쿠키 유효시간 : MaxAge / Expires

• 명시되어 있다면, Persistent Cookie (지속 쿠키) => 창을 닫아도 유지된다.
• 명시되어 있지않다면, Session Cookie (지속 쿠키) => 현재 세션에서만 유지된다. (창이 떠있는 상태)
  • Session의 의미 : 열고 (connect) -> 닫힘 (disconnect) 하나의 Pair에 모두 사용됨
    • 로그인 세션 : 로그인 한 뒤 로그아웃 하기까지
    • HTTP 세션 : TCP/UDP 연결 후 Request 전송 후 Response 받기까지
    • 브라우저 세션 : 탭 열고 닫힘

쿠키에 있어서 보안이 중요한 이유

광고 및 마케팅 목적을 위해서 쿠키를 사용하기도 한다.
특정 사이트들은 사용자가 접속하자마자 쿠키에 ID를 부여한다.
=> 유저 식별자 생성 및 기록을 위해서

ex) Google Analytics 행동 수집 서버

1. InitJS
   • Google Analytics 툴과 관련된 스크립트를 블로그에 import 하여서 채번. -> 방문자 분석에 사용
   • Load
   • Generate : 채번. google.api로부터 생성된 번호를 받아온다. 쿠키에는 google.api의 서드파티 쿠키로 저장한다.
     • 행동 분석용 식별 쿠키
2. SendJS
   • 버튼에 모두 스크립트를 심기. -> 쿠키를 가진 사용자가 버튼을 누르면 어떤 행위를 하게끔한다.
   • Send
   • google.api로 요청을 한다. (Id. 행동)

쿠키 보안

HttpOnly

• XSS (자바스크립트) 공격에 의한 쿠키 접근 제거
• XSS 공격 : 해커가 버튼에 스크립트를 심어서 해당 버튼 클릭 시 스크립트가 실행되도록 함
• 오직 HTTP 요청으로만 쿠키에 접근 가능.

Secure

• 패킷 탈취 (Man-in-the-Middle 공격) 방지를 위해 HTTPS에서만 쿠키를 사용할 수 있도록 함
• MITM 예시 : 요청 - 응답 사이에서 요청, 응답 탈취

SameSite

• 웹 브라우저 주소란에 표시된 도메인과 동일한 도메인에 대한 요청(API)시에만 쿠키 전송
• Cookie가 First-Party 일 때만 전송해야 한다.
• Third-Party Cookie : 브라우저의 도메인과 쿠키에 있는 도메인이 다른 경우 Third-Party Cookie
  • 크로스 사이트에 의해 과거에 설정된 쿠키.
• Third-Party 쿠키에 민감한 인증 정보를 담아서 해당 쿠키를 사용하여 Cross Site 비의도 공격 가능성
  • CSRF 공격

Same Site와 Cross Site의 구분

• TLD(Top Level Domain)과 SLD(Second Level Domain)에 의해서 구분된다.
• Same Site : TLD, SLD 모두 동일
• Cross Site : TLD, SLD 하나라도 동일하지 않음

퍼스트파티 쿠키(인증정보 등)가 설정된 페이지는 cdn에 캐싱하면 안된다. => 보안 위험

• 퍼스트파티 쿠키는 인증에 사용
• 서드파티 쿠키는 마케팅을 위해 사용

CSRF(Cross Site Request Forgery) 공격

쿠키를 사용하면 악의적 요청도 허용된다.
유저가 의도하지 않았는데, 해커가 심은 스크립트에 의해 크로스 사이트에 요청 전달한다.

XSS이든 CSRF든 내가 의도하지 않은 요청이다.
=> 비의도 공격

• SameSite 설정 : Cross Site 요청 시 Third-Party Cookie를 담는가 담지 않는가?

https://www.geeksforgeeks.org/what-is-samesite-cookies-and-csrf-protection/

What is SameSite Cookies and CSRF Protection? - GeeksforGeeks

 

 

이제 브라우저는 보안 문제 때문에 SameSite 설정이 기본이 되었다.
고로 프론트엔드에서 API를 호출하는 것은 Cross Site 요청이다.

SameSite 보안 레벨

• 보안 레벨 높음 - Strict : 퍼스트파티 쿠키만 전송 허용
• 보안 레벨 중간 - Lax : 서드파티 쿠키라도 특수 케이스시엔 부분 허용. 보안 업데이트 후 최신 크롬 default
  • 특수 케이스 = 상태 서버 변경하지 않고 조회만 하는 경우 : GET, ,
• 보안 레벨 낮음 - None : 서드파티 쿠키 모두 허용. 과거 크롬 default.
  • 단, Secure true가 강제된다. HTTPS 미사용시 MITM 탈취에 대한 문제를 방지하기 위해서이다.

쿠키 단점

1. 쿠키 정보가 웹 브라우저에 저장되다 보니
   1-1. 민감 정보 저장 문제.
   • HttpOnly, Secure, SameSite 보안 처리 필요
   • 저장 정보를 암호화 해두고 읽어서 복호화 하는 처리
     1-2. 웹 브라우저 간 공유 불가
   • 웹 브라우저 단위의 저장소이다보니 지역성 문제
     • 매 웹 브라우저에서 하는 검색과 같은 행위들이 해당 브라우저에만 저장
2. 쿠키는 Domain + Path 만 일치한다면 해당 웹 서버로 모든 쿠키를 담아 보내다보니
   • 저장하려는 정보량이 크면, 네트워크 요청 사이즈 커짐
     -> 불필요한 Network Overhead
     -> 웹 서버에게 알려주지 않아도 되는 정보의 경우 웹 스토리지 사용을 권장한다.

Web Storage : 웹 브라우저 저장소 2

쿠키는 웹 스토리지가 아니다. 스토리지와 쿠키는 다음과 같은 특징들에 의해서 구분된다.

• Storage : 웹 브라우저 저장소
  • 유저에 의해 변경된 옵션 상태 등 -> 필요에 따른 조회가 필요할 때 (진짜 저장소)
    ex) 마지막에 어떤 소셜 계정으로 로그인했는지 저장하고, 1년 뒤 로그인할 때 표시하여 알려주기
• Cookie : 웹 서버에게 웹 브라우저가 매번 전달할 특정 정보를 위한 저장소 (Stateful)
  • 로그인 인증 정보 등 -> 웹 서버가 매번 요청마다 필요한 정보를 웹 브라우저에 넣어두고 전달 받아 씀

결론적으로 다음과 같이 정리할 수 있다.

• Cookie : 웹 서버에게 반복적으로 전달하기 위한 + 작은 정보 + (만료 시간을 갖고)
• Storage : 웹 브라우저에서만 사용가능한 + 큰 정보 + (만료 시간 없이)

유효시간에 따른 Storage 종류

• Local Storage : 웹 브라우저 창이 닫혀도 영구적 저장. 용량 처리 조심할 것!
• Session Storage : 웹 브라우저 창이 닫히면 삭제
• 프론트엔드 개발자가 무언가를 저장한다 하면, => Storage를 쓸 것
• 단발적인 내용은 Session Storage, 길게 저장해도 되는 내용은 Local Storge

쿠키는 XSS 공격에 취약하지만, HTTPOnly 설정(Javascript로 접근 불가능)을 통해서 XSS 공격에 대응할 수 있었다.
웹 스토리지도 XSS 공격에 취약하지만, 쿠키와 달리 보안 처리가 불가능하다.
웹 스토리지의 목적 자체가 클라이언트 측에서 Javascript로 데이터에 접근하고 관리하는 것이기 때문에 Javascript로의 접근을 막는 것은 애초에 모순적인 일이다.

세션 관리

• 저장소를 한정짓고 새값이 들어오면 과거의 값들을 버릴까?
  => Batch 활용. 쓰지 않는 세션들을 모아서 처리하면 된다.

Batch는 여러 작업을 쌓아두고 몰아서 처리하는 것이다. (병렬 처리 X. 특정 시점에 여러 작업을 순차적 처리)
ex 1) 스크립트를 짤 때
Docker를 구동시키는 Shell Script를 짤 때 수행하는 스크립트 5~6개를 넣어둠.
ex 2) 데이터를 일괄적으로 삭제하거나 생성 혹은 분석할 때 매 특정 시간에 매번 똑같은 서버가 돌아가서 처리를 한다.
하루에 한 번씩 배치 프로세스를 돌려서 처리한다.

백엔드 개발자가 Batch 로직을 작성하고, 사용하지 않는 세션들을 정리한다.

쿠키와 세션의 처리 과정 차이

쿠키 사용 : 웹 브라우저에 주요 정보를 저장하는 경우
=> 1. 요청 2. 처리 3. 반환

세션 사용 : 웹 서버에 주요 정보를 저장하는 경우
=> 1. 요청 2. 조회 3. 처리 4. 반환

서버에 저장된 수 많은 세션들 중 특정한 세션을 찾기 위한 조회 과정이 포함된다.

세션 저장소 사용

웹 서버에 세션을 저장하는 경우 다음과 같은 문제들이 발생한다.

1. SPOF 문제
   • 서버에 이상이 생기는 경우, 세션 데이터들이 안전하지 않음
2. 서버 부하 문제
   • 서버에 모든 세션을 저장하게 되는 경우 서버의 부하가 커진다. 세션 조회를 위한 성능 문제가 있을 수 있다.

매 요청마다 세션 ID와 세션 대조 필요하기 때문에. 조회를 위해 긴 시간이 소요된다.
그러나 수천 수만번의 API 호출하기 때문에, 그때마다 세션 데이터를 조회해야한다.
즉, 세션을 사용할 경우 고려해야할 점은 바로 속도이다.
=> 세션 저장소로 Redis 사용을 고려해볼 수 있다.

Redis는 메모리 기반의 DB로, 빠르지만 높은 비용이 요구된다. 또한 확장성 이슈가 있다. (비싼 인스턴스)