Cookie 개요, 브라우저에서 쿠키의 작동

 

이미지 출처 : https://sumontasaha80.medium.com/basic-things-about-http-cookies-1c1290f31f7b

 

Cookie의 필요성?

➡️ HTTP가 어떤지 다시 생각해 볼 필요 있음.

 

HTTP는 Stateless Protocol이다.

✅ 웹 서버는 기본적으로 매 요청이 어떤 웹 브라우저가 보낸 것인지 알 수 없다. (stateless ; 불연속성)

JWT(JSON Web Tokens)와 같은 방식으로 이를 해결하는 방식도 있음.

사용자 정보와 인증 서명 같은걸 암호화 해둔것을 인코딩 해둔 값이라고 보면 된다.

로그인 기능을 구현할 때 초보자들에게 많이 추천되는 방식인데, 이때 보안의 결함 발생함.

secret 코드(암호화를 통해 전달되어야 하는 값)의 원본 secret을 쉬운것으로 적어놨다가

브루트포스에 의해 해킹당하는 경우가 있거나

alg : "none" 처럼 대충 만들거나

민감한 유저 정보를 그대로 다 집어 넣는 경우

등의 보안 문제가 있을 수 있다.

 

HTTP에 Stateful 한 방식을 부여하기 위해 Cookie와 Session을 쓴다.

웹 서버가 웹 브라우저의 요청이 어떤 User에 의해 요청된 것인지 알기 위해서

응답 반환 시 요청자 정보를 함께 반환. HTTP로도 stateful(연속성)한 요청과 반환을 할 수 있게 됨.

이 방식에서 사용되는게 Cookie와 Session이다.

 

더 나눠보자면 단순히 cookie만 사용하는 방식과 session과 cookie를 함께 사용하는 방법 두 가지가 있다.

(보통 쿠키의 크기가 웹 브라우저에 저장할 수 없을 정도로 크거나 복합적인 경우나
브라우저에 저장할 수 없는 민감한 정보인 경우, 서버의 session을 활용한 후자의 방식을 채용)

 

 

 

Cookie의 웹 브라우저에서 작동 방식

1. 웹 서버가 첫 요청에 대한 반환시 설정(Set-Cookie 헤더 통해) + 웹 브라우저 내 저장 및 전송
2. 이 헤더를 통해 어떤 데이터를 쿠키로 쓸 것인지, 유효 시간 및 보안 설정을 함.

• 쿠키 사용의 기준 : Domain + Path
  • 모든 쿠키에는 도메인이 연결 되어 있다.
  • 예를 들어, 1번 쿠키에는 Domain: a.com,  Path: / 이고
  • 2번 쿠키에는 Domain: a.com,  Path: /user  일 경우
  • a.com/user/name 호출 시 1+2번 쿠키를 동시에 전송해야함.
• 쿠키 유효 시간 : Max-Age / Expires
  • 이게 명시되어 있다면 Persistent Cookie ; 윈도우 창을 닫아도 유지 됨
    • Max-Age : 초 단위 설정. 쿠키가 설정된 시점부터 ~초 동안 유효함을 의미
      • Expires 보다 우선적으로 사용된다. (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)
    • Expires : 쿠키가 만료되는 정확한 날짜와 시간 지정 (보통 Max-Age 없을 때 사용)
    • 브라우저는 Max-Age를 우선적으로 사용하여 만료 시간을 계산, 둘 다 사용될 경우 Expires는 무시됨
  • 아니라면 Session Cookie ; 창이 떠져 있는 경우에만 적용

Session의 의미 : connect 후 disconnect의 하나의 pair 에서의 기간.
1. 로그인 세션 : 로그인 한 후 부터 로그아웃 하기 까지

2. HTTP 세션 : TCP/UDP 연결 후 Request 전송 후 Response 받기 까지

3. 브라우저 세션 : 하나의 탭/창이 열리고 닫히기까지

• 쿠키 보안 : HttpOnly, Secure, Samesite
  • HttpOnly : XSS(Cross Site Scripting; 외부에서 사용자의 특정 이벤트에 자바스크립트를 심어서 이를 통해 공격)을 막기 위해 HTTP 요청 보낼 때만 사용하는 옵션.
  • Secure : 패킷 탈취(Person-In-The-Middle ; 요청과 응답 사이에서 요청, 응답 탈취)를 막기 위해 HTTPS 채널에서만 사용
  • SameSite : 웹 브라우저 주소란에 표시된 도메인과 동일한 도메인에 대한 요청(API)에만 쿠키 전송
    • 보안 레벨 높음 - Strict : 퍼스트 파티 쿠키 전송만 허용
    • 보안 레벨 중간 - Lax : 서드 파티 쿠키라도 특수 케이스 시엔 부분 허용
      • 특수 케이스 : 서버 상태 변경하지 않고 조회만 하는 GET이나 <a href>, <link rel="prerender">
    • 보안 레벨 낮음 - None : 서드 파티 쿠키 모두 허용
    •  
    • CSRF(Cross Site Request Forgery) 사이트 간 요청 위조를 막고자
    • 동일 사이트의 정의 : www.web.dev = static.wed.dev
    • 크로스 사이트의 정의 : www.web.dev ≠ static.another.dev
    • 참고로, 크로스 사이트에 과거에 설정됐던 쿠키를 서드파티 쿠키라 함.

 

문제 상황) 2020년 1월 구글에서 SameSite default 상향 정책 공지

https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ko

새로운 SameSite=None; Secure 쿠키 설정에 대비  |  Google 검색 센터 블로그  |  Google for Developers

요약 : Chrome에서 SameSite default을 None -> Lax로 상향 조정하겠다.

SameSite=None; Secure 설정이 있는 쿠키만 외부에서 들어오는 액세스에 관해 보안 설정을 사용할 수 있다.

 

 

현재 방식 - 예시 )

• A 도메인의 페이지에서 B라는 서드 파티 API를 호출하여 사용자 데이터를 추적하거나 광고 목적으로 사용.
• B API는 쿠키를 사용하여 사용자를 식별하고, 해당 정보를 기반으로 광고를 타겟팅하는 방식.

위 정책 이후의 변화)

• 크롬 브라우저에서 기본적으로 서드 파티 쿠키를 차단하거나 제한
• A 도메인에서 B API를 호출하더라도 B가 설정한 쿠키가 차단되어 원활한 추적이 불가능.

해결책)

1. Server to Server 통신 이용.
   1. A 도메인에서 B 서드 파티 API 호출 X, A 도메인의 서버로 정보를 먼저 전송
   2. 필요한 경우 B 서드 파티 API로 요청을 보내서 SameSite 정책 우회
   3. + @)  SameSite=None; Secure 설정 추가해서 서드 파티 쿠키 차단되지 않도록 하는 방식
2. First-Party Data 활용
   1. 자사 도메인에서 직접 수집한 사용자 데이터를 바탕으로 맞춤형 콘텐츠, 광고 제공
3. Consent Management Platforms
   1. 사용자에게 명시적인 동의를 얻어 쿠키를 사용하는 방식.
   2. GDPR(General Data Protection Regulation : EU에서 개인정보 보호법)에 
    
4. Privacy Sandbox : 구글이 제공하고 도입하려하는 새로운 프레임워크.
   이 프레임워크는 서드파티 쿠키를 대체할 기술들을 제공. https://developers.google.com/privacy-sandbox/cookies?hl=ko

여러 페이지에서 쿠키를 사용하기 위해 사전에 유저에게 공지하는 모습