쿠키(Cookie)란 무엇인가? (+ Session 추가정리)

서버가 클라이언 인증을 확인하는 방식에 대표적으로 쿠키, 세션, 토큰이 있다.

그중에 세션과 JWT 인증 방법에 대해 알아봤었는데, 세션과 JWT의 근간이 되는 쿠키에 대한 내용이 없고 둘의 차이점에만 집중하다보니, 내용이 너무 부족했던거 같다. 그래서 이번에 포스팅하면서 이전 내용을 보충하고 추가적으로 공부하고자 한다.

https://hsch19.tistory.com/7

JWT와 Session

지난 포스팅에서도 언급했었지만 HTTP는 비연결성(Connectionless)와 무상태성(Stateless)라는 특성을 가지고 있어서 매번 확인을 통해서 클라이언트가 누구인지 확인해야한다.

이런 HTTP프로토콜의 특성을 보완하기 위해서 쿠키 또는 세션을 사용하게 된다. 

---

쿠키(Cookie)란?

쿠키란 클라이언트(브라우저) 로컬에 저장되는 키와 값(key-value)이 들어있는 작은 데이터 파일이다.

 

서버는 클라이언트가 사이트에 방문 했을 때, 누구인지 계속해서 식별하기 위해(HTTP특성으로 계속해서 인증을 요구하거나 정보가 날아가는 것을 막기 위함) 식별 가능한 정보를 응답헤더의 Set-Cookie에 담아서 응답을 보낸다.

이 후, 해당 클라이언트는 서버에 요청을 보낼 때 마다 저장된 쿠키를 요청헤더의 Cookie에 담아서 보내게 되고 서버는 쿠키에 대한 정보를 바탕으로 클라이언트가 누구인지 식별할 수 있게 되는 것이다.

 

쿠키의 활용

쿠키의 활용은 크게 세션관리, 개인화, 트래킹이다.

 

세션관리
사용자의 정보를 세션에 관리한다. (로그인 관리, 장바구니 목록, 게임 스코어 등)

개인화

사용자의 개인 맞춤 세팅을 저장한다.(언어 설정, 다크모드 등)

트래킹

사용자 분석 및 광고 개제를 위해 웹사이트 내 사용자 행동 기록, 관리

쿠키의 구성요소

• 이름(Name) : 각각의 쿠키를 구별하는데 사용되는 이름 
• 값(Value): 쿠키의 이름과 관련된 값
• 만료시간(Expires/Max-Age) : 쿠키의 유지시간
• 도메인(Domain) : 쿠키를 전송할 도메인(만약 현재 도메인과 일치하지 않으면, 타사 쿠키로 간주되어 브라우저에서 거부)
• 경로(Path) : 쿠키를 전송할 요청 경로
• HttpOnly 여부(Http Only) : 쿠키는 클라이언트에서 자바스크립트로 조회할 수 있기 때문에 해커들은 자바스크립트로 쿠키를 가로채는 것을 시도하게 된다. 가장 대표적인 공격중 하나가 XSS(Cross Site Scripting)이다.
  이러한 스크립트를 통한 탈취방법을 막고자 브라우저에서는 쿠키에 접근할 수 없도록 제한하기 위한 옵션이 HTTP Only이다.
• 보안연결 여부(Secure) : 자바스크립트가 아닌 네트워크를 직접 감청하여 쿠키를 가로챌 수도 있다.
  때문에 HTTPS 프로토콜을 사용하여 데이터를 암호화하면 쿠키 또한 암호화가 된다.
  secure 접미사를 사용하면 브라우저는 HTTPS가 아닌 통신에서는 쿠키를 전송하지 않습니다.

XSS(Cross Site Scripting) : 게시판 제목 또는 이미지 src에 해커사이트로 연결되게 작성해서 쿠키를 탈취한다.

https://unabated.tistory.com/entry/7-XSSCSS

7. XSS(CSS)

쿠키 발급 과정

쿠키 발급 과정

쿠키의 단점

• 보안이 취약하다.(요청시 쿠키의 값을 그대로 보내기 때문에 사용자의 정보 유출 및 조작 가능성이 있다.)
• 한 쿠키는 최대 4KB의 정보를 담을 수 있기 때문에 많은 정보를 담을 수 없다.
• 브라우저마다 쿠키에 대한 지원 형태가 달라서, 브라우저간 공유가 불가능하다.
• 쿠키의 사이즈가 커질수록(쿠키 개수가 많아질수록) 네트워크 부하가 심해진다.

---

세션(Session)이란? 

(이전 포스팅의 정보가 너무 부족해서 다시 정리하고자 한다.)

위의 쿠키가 보안에 취약하다는 단점을 가지고 있었는데, 이를 해결하기 위해 세션은 비밀번호, 카드번호등의 중요한 정보는 서버측에서 관리하는 방식이다.

 

즉, 세션은 쿠키를 기반으로하고 있지만, 사용자 정보파일을 클라이언트 로컬(브라우저)가 아닌 서버측에서 관리한다.

 

클라이언트가 사이트에 접속하게 되면, 서버에서 쿠키를 만들어주는데 개인정보와 관련된 내용은 서버측에 저장되어 있기 때문에 쿠키에 있는 개인정보로 인증하는게 아닌, 세션ID를 통해 인증을 하게 된다.

 

* 헷갈리지 말 것 *

세션과 쿠키는 다른 방식이 아닌, 쿠키 통해서 세션ID를 서버에 전달하는 것이다.

서버는 클라이언트가 보낸 쿠키에 담긴 세션ID와 세션 스토리지에 담긴 세션ID를 대조해 인증상태를 판단한다.

 

세션ID 발급/인증 과정

세션 발급/인증 과정

각 클라이언트에게 고유 ID를 부여하고 세션ID로 클라이언트를 구분해서 클라이언트의 요구에 맞는 서비스를 제공한다.

세션의 단점

• 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.
• 세션ID 자체에는 유의미한 개인정보를 담고있지 않지만, 세션ID자체를 탈취해서 클라이언트인척 할 수 있다.
• 로그인한 해당서버에서만 사용할 수 있기 때문에 서버를 추가하거나 하는 등의 확장성 이슈가 있다.

안전한 세션쓰면 되는데, 왜 쿠키를 사용할까?

세션의 경우 서버의 자원(메모리)을 사용하기 때문에 사용자가 많을 경우 소모되는 자원이 상당하다.

때문에 서버자원 관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행하여, 서버자원의 낭비를 방지하고 웹사이트의 속도를 높일 수 있다.

 

 

---

참고자료

https://jhbljs92.tistory.com/entry/1-JWT-%ED%86%A0%ED%81%B0-%EC%9D%B8%EC%A6%9D%EA%B3%BC-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0

 

https://interconnection.tistory.com/74

 

https://velog.io/@whitebear/%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0JWT-%ED%99%95%EC%8B%A4%ED%9E%88-%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0

 

https://theheydaze.tistory.com/550

 

https://unabated.tistory.com/entry/7-XSSCSS