[네트워크] HTTP에 대해 (4) - HTTP 쿠키, 세션

HTTP에 대해 공부하며 정리한 글입니다.

 

이전 글에서도 보다시피 세션, 쿠키는 HTTP의 무상태라는 특징으로 무상태로 설계할 수 없는 케이스(로그인 유지)에 사용된다고 했습니다.

그런데 서버는 클라이언트의 상태를 기억하지 않는다면 쿠키, 세션을 사용하지 않고 클라이언트의 모든 요청에 사용자 정보를 포함하면 되지 않을까? 라는 생각을 할 수도 있지만 그렇게 되면 보안 이슈도 있고 개발자는 모든 요청에 사용자 정보를 포함하도록 개발해야 하기에 굉장히 번거로워질 수 있습니다.

그러면 쿠키, 세션은 무엇일까요?

 

쿠키

쿠키 정의

• HTTP 쿠키는 클라이언트(브라우저) 로컬에 저장되는 key, value 형태의 작은 데이터 파일
• 문자열 형태만 가지며, 최대 4KB의 제한 용량을 가짐

 

쿠키 매커니즘 (로그인으로 가정)

1. 로그인 완료시, 서버는 응답 헤더에 Set-Cookie를 설정해 key=value형식으로 지정하여 클라이언트에게 응답
2. 웹 브라우저에서는 쿠키 저장소에 key-value형태로 쿠키를 저장
3. 웹 브라우저는 서버에 요청시 항상 도메인에 맞는 쿠키를 가져와 요청 헤더에 Cookie를 설정해 서버로 요청 전송

 

쿠키 구성 요소

ex) set-cookie: sessionId=abc123; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

• Expires, max-age (생명주기)
  • Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
    • 쿠키가 삭제되는 만료 날짜를 지정
  • Set-Cookie: max-age=3600 (3600초)
    • 쿠키가 삭제될 시간을 초 단위로 설정
    • 0이나 음수로 지정할 경우 쿠키 삭제됨
  • 세션 쿠키 - 만료 날짜 생략시 브라우저 종료시까지만 유지
  • 영속 쿠키 - 만료 날짜를 입력하면 해당 날짜까지 유지
• Domain (도메인)
  • 예) domain=example.org
  • 명시한 경우 - 명시한 문서 기준 도메인 + 서브 도메인 포함 (서브 도메인 : 도메인으로 웹사이트 섹션 구별을 위해 도메인명에 추가되는 prefix)
    • domain=example.org을 지정해서 쿠키 생성
      • example.org → 쿠키 접근 O
      • dev.example.org → 쿠키 접근 O
  • 생략한 경우 - 현재 문서 기준 도메인만 적용
    • example.org에서 쿠키를 생성하고 domin 지정을 생략
      • example.org → 쿠키 접근 O
      • dev.example.org → 쿠키 접근 X 
• Path (경로)
  • 예) path=/home
  • 해당 경로를 포함한 하위 경로 페이지만 쿠키 접근 O
  • 일반적으로 path=/ root로 지정 (보통 한 도메인 안에서 쿠키 전송을 원하는 경우가 많음)
  • path=/home 지정
    • /home → 쿠키 접근 O
    • /home/level1 → 쿠키 접근 O
    • /home/level1/level2 → 쿠키 접근 O
    • /hello → 쿠키 접근 X
• Secure, HttpOnly, SameSite (보안)
  • Secure
    • 쿠키는 http, https를 구분하지 않고 전송
    • Secure 적용시 https인 경우에만 전송
  • HttpOnly
    • XSS 공격 방지 (유해한 사용자의 의해서 나의 쿠키 정보가 유출되는 것을 방지)
    • 자바스크립트에서 접근 불가 (document.cookie)
    • HTTP 전송에만 사용
  • SameSite
    • CSRF 공격 방지
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

 

Q) XSS, CSRF란 무엇인가요?

XSS(Cross-Site Scripting)

• 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법
• 웹 어플리케이션에서 사용자 입력 값에 대한 필터링이 제대로 이루어지지 않을 경우, 이용자가 입력이 가능한 폼에 악의적인 스크립트를 삽입하여 해당 스크립트가 다른 이용자 측에서 동작하도록 하여 악의적인 행위를 수행하는 취약점
• 쿠키나 세션 토큰 등의 민감한 정보를 탈취
• 종류로 Reflected-XSS, Stored-XSS로 나뉨

 

CSRF(Cross-Site Request Forgery)

• 사이트 간 요청 위조로 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹 사이트에 요청하게 하는 공격

CSRF 공격 방식

1. 공격자는 이메일이나 게시판에 CSRF 스크립트가 포함된 게시물을 전송
2. 관리자는 공격자가 등록한 CSRF 스크립트가 포함된 게시물을 확인
3. 관리자가 CSRF 스크립트가 포함된 게시물 열람시, 관리자 권한으로 공격자가 원하는 CSRF 스크립트 요청이 발생
4. 공격자가 원하는 CSRF 스크립트가 실행되어, 관리자 및 사용자의 피해가 발생

 

XSS와 CSRF의 차이

• XSS는 사용자가 웹사이트를 신용하여 악성 스크립트가 실행 (악성 코드가 클라이언트에서 발생)
• CSRF는 특정 웹사이트가 사용자의 브라우저를 신용해 발생하는 공격 (악성 코드가 서버에서 발생)

 

 

쿠키 특징 및 사용처

• 사용자 로그인 세션 관리 (세션 id)
• 광고 정보 트래킹
• 로그인 화면에서 '아이디 자동완성' 기능
• 팝업 화면에서 '오늘 하루 보지 않기' 기능
• 쿠키 정보는 항상 서버에 전송됨
  • 네트워크 트래픽 추가 유발
  • 따라서 최소한의 정보만 사용하는 것이 좋음 (ex : 세션 id, 인증 토큰)
  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 사용
• 또한 탈취 위험이 있기에 보안에 민감한 데이터는 저장하면 안됨 (주민번호, 신용카드)

 

세션

세션 정의

• 일정시간동안 브라우저로부터 요청되는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술
• 일정시간이란 클라이언트가 서버와의 접속이 종료되기 전까지의 시점
• 즉, 클라이언트가 웹서버에 접속해있는 상태를 하나의 단위로 보고 세션이라고 칭함

 

세션 매커니즘 (로그인으로 가정)

1. 로그인 성공시, 서버는 클라이언트의 정보를 담는 세션 생성
2. 세션 ID를 담은 쿠키를 생성하고, HTTP 응답 헤더의 set-cookie 옵션을 통해 쿠키를 포함한 응답 전달
3. 클라이언트는 해당 쿠키는 쿠키 저장소에 저장 후 서버에 다른 요청시 HTTP 요청 헤더의 cookie 옵션을 이용해 쿠키를 담아서 전송
4. 서버는 전달 받은 쿠키를 읽어 쿠키 안의 세션 ID를 이용해 클라이언트를 식별

 

 

세션 특징

• 서버는 일종의 저장소에 세션을 저장하는데 접근 속도가 빠른 in-memory db(ex: redis)를 주로 사용
• 서버에 세션을 저장하기에 사용자가 많아질경우, 서버의 부하 발생
• 브라우저 종료시 소멸 (서버 기준이 아닌 브라우저 기준!)
  • 세션 쿠키는 브라우저 종료시 삭제되는 쿠키이고 세션 ID를 저장하고 있는 쿠키를 세션 쿠키라고도 함
  • 브라우저 종료시 세션 id를 저장한 쿠키는 소멸되지만 서버 입장에서는 웹 브라우저 종료 여부를 인식할 수 없음
• 세션 정보 삭제 시점
  • 사용자 로그아웃시 세션 삭제
  • 서버에서 세션의 종료 시점을 지정
    • 예를 들어 세션 생성 시점으로부터 30분으로 지정시, 사용자가 서버에 마지막으로 요청한 시간을 기준으로부터 30분 후에 세션을 종료

 

Q) in-memory database란 무엇인가요?

디스크(HDD, SSD)가 아닌 메모리에 모든 데이터를 저장하고 관리하는 데이터베이스를 뜻하며 Redis, H2, memcached 등이 이에 속합니다.

여기서 디스크와 메모리의 특징은 다음과 같습니다.

 

디스크

• 데이터를 영구적으로 저장하는 스토리지
• 디스크에 있는 데이터는 CPU가 처리하는 속도가 메모리보다 느림
• 저장할 수 있는 용량이 메모리보다 훨씬 크고, 컴퓨터 전원이 꺼진 상태에서도 데이터를 보관할 수 있음

메모리(RAM - Random Access Memory)

• 빠른 액세스를 위해 데이터를 임시로 저장하는 스토리지
• 메모리에 올라간 데이터는 컴퓨터 전원이 꺼지면 휘발되는 특성이 있음
• 메모리에 올라간 데이터는 매우 빠르게 작업할 수 있음

 

인메모리 데이터베이스는 모든 작업을 메모리에서 수행하기에 디스크 기반의 데이터베이스보다 데이터 접근 속도가 빠릅니다.

인메모리 데이터베이스의 사용이 적합한 경우는 microsecond 단위의 응답시간을 요구하는 애플리케이션이나 실시간 분석, 세션 저장 등 트래픽이 비교적 많이 몰리는 상황에 적절하다고 합니다.

 

쿠키와 세션의 차이

• 저장 위치
  • 쿠키 → 클라이언트에 저장
  • 세션 → 서버에 저장
• 보안
  • 쿠키는 클라이언트에 저장되기에 탈취 및 변조 위험성이 있음
  • 세션은 서버에서 관리하기에 비교적 보안성이 좋음
• 생명 주기 (브라우저 기준)
  
  • 쿠키 → 만료 시간을 설정한 경우라면 브라우저가 종료돼도 시간이 경과되지 않았다면 소멸되지 않음
  • 세션 → 만료 시간이 상관 없이 브라우저 종료시 소멸 

 

그러면 로그인 할 때 쿠키/세션 방식을 사용하면, 해커가 쿠키를 가로채 치명적 보안 문제를 일으킬 수 있고, 서버는 수많은 사용자의 세션을 저장하고 요청이 올 때마다 확인 작업을 하느라, 서버에 부담이 커질 수도 있지 않을까요?

 

이런 문제점을 해결해주는 것이 바로 토큰(Token)입니다.

토큰 기반 인증은 위의 쿠키/세션보다 보안성도 높고 서버에게도 효율적인 방식입니다.

 

 

토큰 (Token)

토큰 정의

 

 

토큰 매커니즘

 

 

토큰 특징