[06.30] Cookie/Session

목차

• Cookie
• Session

---

📌 Cookie

: 데이터이면서, 우리가 현재 사용하는 컴퓨터(브라우저)에 작은 텍스트 파일로 저장되어있는 것

• 예를 들어 장바구니를 담을 경우, '하루 이창을 보지 않기'클릭시 계속 안 볼수 있음, 로그인을 위해 로그인 정보 저장, 자동 로그인 같은 경우
  ➡️ 브라우저는 내용을 기억할 공간이 X, 기억해주는 것은 쿠키!
• 사용자 단위가 아닌 브라우저 단위로 생성이 됨
• 다른 도메인을 대신하여 쿠키 발급 불가
• 쿠키를 이용하는 것은 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하는 것이 아니라, 클라이언트에서 서버로 쿠키를 다시 전송하는것도 포함됨
• 쿠키의 저장방식은 key:value (ex, username = 홍길동)

  Q : 그렇다면, 쿠키는 왜 사용을 하는 걸까?
  A : 제일 큰 이유는 사용자의 편의를 위해서이다.
  상태를 저장할 수 없는 http, 프로토콜 특성상 쿠키를 이용해서 상태를 저장함

Cookie 인증 방식

1. 브라우저(클라이언트)가 서버에 요청을 보냄
2. 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라리언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담음
3. 이후 해당 클라이언트는 요청을 보낼때마다 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다. 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라리언트가 누군지 식별하거나 정보를 바탕으로 추천 광고를 띄우거나 한다

Cookie 옵션 종류

1. Domain

: 우리가 흔히 사용하는 www.google.com과 같은 서버에 접속할 수 있는 이름

• 해당 도매인의 서브 도메인까지 모두 포함, 세부 경로를 포함 X
  📍 서브 도메인이란? : www 같은 도메인 앞에 추가로 작성되는 부분
• 예를 들어, 요청해야 할 URL이 [http://www.localhost.com:3000/users/login]이라 하면 여기에서 Domain은 localhost.com이 됨
  

2. Path

: 세부 경로로써 서버가 라우팅할 때 사용하는 경로를 의미

• 쿠키에 해당 경로를 설정하면, 해당 페이지 경로에서만 쿠키 사용 접근이 가능
• 해당 경로의 하위 경로까지 모두 포함. 루트 경로 (/)로 설정하면 모든 경로에 쿠키가 유효하다는 뜻
  • path=/home 지정시
    • /home/level1 -> 접근 가능
    • /home/levelq/level2 -> 접근가능
    • /hello -> 접근 불가능 (다른 경로)
• path를 입력하지 않으면 루트 경로로 자동 입력됨
  

3. Expires/ Max-age

: 유효기간(만료일) 설정

• expires=Sat, 26-Dec-2020 04:39:21 GMT
  • 구체적인 날짜를 명시
  • 만료일이 지나면 쿠키 삭제
• max-age=3600
  • 초 단위로 유효 시간을 명시
  • 만일 0이나 음수로 지정할 경우 쿠키는 삭제 됨
• 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시까지만 유지
• 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지
  

4. Secure

: 사용하는 프로토콜에 따른 쿠키의 전송 여부를 결정하는 옵션

• 활성화하면 HTTPS 사용시에만 쿠키 정보 전달(미적용시 HTTP도 전달)
• 도메인이 localhost인 경우 HTTPS가 아니어도 쿠키 전송이 가능 (개발단계에서 localhost를 사용하는 경우가 많기 때문에 생긴 예외사항)
  

5.HttpOnly

: 자바스크립트로 브라우저의 쿠키에 접근이 가능한지 여부를 결정

• 해커가 자바스크립트로 쿠키를 탈취할 수 없어서, XSS 공격 방지가능
• 쿠키는 꼭 서버에서 만들어 반환하여야 클라이언트가 사용할 수 있는 것이 아닌 얼마든지 클라이언트에서도 사용할 수 있음

    document.cookie = "user=John; path=/; expires=Tue, 19 Jan 	2038 03:14:07 GMT";
	alert(document.cookie); // 모든 쿠키 보여주기

➡️ 콘소로그를 찍어보면 HttpOnly가 true인 test3는 보이지 않음

console.log(document.cookie); //test=100; test-200

6. SameSite

: 서드 파티 쿠키의 보안적 문제를 해결하기 위해 만들어진 기술

• 요청 도메인과 쿠키 정보 내의 도메인이 다른 크로스 사이트(cross site)로 전송하는 요청에 대해서 제한을 둘 수 있음
• Cross-Origin : 서버의 도메인, 프로토콜, 포트 중 하나라도 다른 경우
• Cross-Site : eTLD+1이 다른 경우
  • eTLD+1
    • TLD : .com, .org, .kr, .io 같이 도메인의 가장 마지막 부분
    • eTLD : 사이트를 식별할 수 있을 만큼 세분화된 TLD를 말하여, .kr, .io 같은 TML는 하위 도메인을 하나 더 더한 .co.kr, .github.io등을 eTLD라고 판단함
    • eTLD+1 : eTLD 바로 왼쪾의 하위 레벨 도메인을 합한 것
  • 예를 들어, [https://code.github.io] vs [https://states.github.io] ⇒ 두 주소 모두 eTLD가 github.io로 같지만, eTLD+1은 각각 code.github.io, states.github.io로 다르므로 Cross-Site

📍 서드 파티란?

: 쿠키 도메인 파라미터를 전혀 다른 도메인으로 설정된 쿠키

예를들어, 사용자가 Example 사이트에 방문해서 로그인을 했다면 다음 로그인할 때 정보를 다시 입력해야 하는 번거로움을 줄일 수 있도록 Example 사이트에서 사용자의 웹브라우저로 Cookie A가 부여된다. 그런데 이 웹페이지는 우측에 배너 광고가 표시되는데 이 배너 광고는 Adserver 사이트에서 전달되고 있다고 한다. 이 배너를 통해 사용자의 웹브라우저에 다른 도메인 파라미터를 갖는 Cookie B가 부여되게 된다.

사용자가 방문하고 있는 도메인에서 발행되는 Cookie A를 퍼스트 파티 쿠키(First-party Cookie) 이며, 타 도메인에서 발행되는 Cookie B를 서드 파티 쿠키(Third-party Cookie)라고 하는 것이다.

이 서드 파티 쿠키는 주로 타깃 마케팅 광고 목적으로 사용된다. 예를들어 신발 쇼핑몰 사이트를 자주 방문하게 되면 쿠키가 저장되게 되고 구글 애드센스가 이를 가져가 다른 사이트에서의 배너 광고에서 신발 광고가 화면에 나타나는 것이 서드 파티 쿠키를 이용한 원리라고 보면 된다.

Same-site 속성

• None : 쿠키는 크로스 사이트 요청의 경우에 항상 전송, 쿠키 옵션 중 Secure 옵션이 필요로 함
• Strict : 쿠키는 크로스 사이트 요청에는 항상 전송되지 않음 (가장 보수적), Same-site의 경우에만 쿠키 전송
• Lax : Strict에 비해 상대적으로 느슨한 속성
  

Cookie 방식의 단점

• 보안에 취약
  요청시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작을 당할 위험이 존재
• 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없음
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능
  
• 쿠키의 사이즈가 크면 클수록 네트워크에 부하가 심해짐

---

📌 Session

: 서버가 Client에 유일하고 암호화된 ID를 부여하고 중요 데이터는 서버에서 관리

Q : 세션 객체는 어떤 형태로 이루어져있나?
A: 세션 객체는 Key에 해당하는 SESSION ID와 이에 대응하는 Value로 구성되어 있따.
Value에는 세션 생성 시간, 마지막 접근 시간 및 User가 저장한 속성 등이 Map 형태로 저장된다.

Session 인증 방식

1. 유저가 웹사이트에서 로그인하면 세션이 서버 메모리(DB)상에 저장된다.
   이때, 세션을 식별하기위한 Session ID를 기준으로 정보를 저장한다.
2. 서버에서 브라우저에 쿠키에다가 Session ID를 저장한다.
3. 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session ID를 쿠키에 담아 전송한다.
4. 서버는 클라이언트가 보낸 Sesssion ID와 서버 메모리로 관리하고 있는 Session ID를 비교하여 인증을 수행한다.
   [예시]
   

Q : 세션을 사용하는 이유는 무엇일까?
A : 쿠키에 SessionId 외의 정보를 기록하지 않음으로써 안정성이 확보된다

Session 방식의 단점

• 쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않음
  그러나, 해커가 세션 ID 자체를 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재 (이는 서버에서 IP 특정을 통해 해결할 수 있긴함)
• 유저 정보가 서버에 있기 때문에 처리 속도에 대한 비용 발생이 됨
• 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해지고 서버 비용이 더 많이 듬

---