TIL) Cookie 정의, Session 정의, 쿠키와 세션의 차이

인증에 필요한 기본 지식 Cookie

Cookie 배경

쇼핑몰에서 살 아이텀을 장바구니에 넣고 여기저기 돌아다녀도 장바구니 안의 아이템은 유지가 된다. 

HTTP는 stateless (무상태성)인데 어떻게 정보가 유지 될까? 

바로 쿠키 Cookie 덕분이다! 🍪

---

Cookie 란?

어떤 웹 사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터

서버에서 클라이언트에 영속성있는 데이터를 저장하는 방법이다. 그러므로 서버가 원한다면 서버는 클라이언트의 쿠키를 이용하여 데이터를 가져올 수 있다.

해당 도메인에 대해 쿠키가 존재하면, 웹 브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달한다. 

 

그러므로 쿠키를 이용하는 것은 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 쿠키를 다시 전송하는 것도 포함된다.

 

---

Cookie 이용법

삭제하지 않으면  사라지지 않는다는 특성을 이용해보자!

장바구니 기능, 로그인 상태 유지, 사용자 선호, 테마 등 장시간 보존해야하는 정보 저장에 적합하다. 

 

쿠키는 브라우저 설정 창에 가면 금방 노출이 되기 때문에 보안에 취약하고 변조하기도 쉽다. 그래서 쿠키는 알아보기 어렵게 암호화된 내용으로 채워져 있다. 특히 인증정보와 같이 민감한 정보에는 hashing 처리가 되어있다. 하지만 이마저도 위험하다. 왜냐면 자바스크립트로 쿠키에 접근할 수 있기 때문이다. 

 

---

Cookie 전달 방법

쿠키가 클라이언트에 저장되고 자동으로 요청되는 화면에서,

 

서버가 응답헤더에 set-cookie 라는 프로퍼티에 쿠키의 이름, 값, 경로 등의 옵션을 저장한다. 

쿠키가 담긴 응답을 받은 클라이언트는 응답헤더에 존재하는 set-cookie를 확인하고, 다음에 존재하는 쿠키를 매 요청시마다 쿠키의 이름과 값을 서버에 전달한다.

 

서버가 쿠키를 저장하면, 이후로는 해당 웹사이트를 이용할 때 매 요청에 자동으로 쿠키가 함께 전송된다. 

그렇기 때문에 쿠키 내용을 바탕으로 서버는 클라이언트에 저장된 쿠키 내용을 통해 로그인을 유지한다던지 테마를 보여줄 수 있는 것이다. 

 

---

Cookie에서 설정 할 수 있는 다양한 options

 

'Set-Cookie':[
            'cookie=yummy', 
            'Secure=Secure; Secure',
            'HttpOnly=HttpOnly; HttpOnly',
            'Path=Path; Path=/cookie',
            'Doamin=Domain; Domain=codestates.com'
        ]

 

• Domain = 서버와 요청의 도메인이 일치하는 경우 쿠키 전송 // naver.com에서 받은 쿠키를 google.com에 전송하는 일을 막을 수 있다.

쿠키 옵션에서 도메인은 포트 및 서브 도메인 정보, 세부 경로를 포함하지 않는다. 여기서 서브 도메인이란 www 같은 도메인 앞에 추가로 작성되는 부분이다. 

ex) 요청해야항 URL이와 같다면, https://www.google.com/

Domain 은 google.com 이 된다. 

 

• Path = 서버와 요청의 세부경로(서버가 라우팅할 때 사용하는 경로)가 일치하는 경우 쿠키 전송

ex) 요청해야항 URL이와 같다면, https://www.google.com/search?q=%EC%9C%

Path 는 /search?q=%EC%9C% 가 된다. 

 

Path 옵션의 특징은 설정된 경로를 포함하는 하위 경로로 요청을 하더라도 쿠키를 서버에 전송할 수 있다는 점이다.

즉 Path가 /users로 설정되어 있고, 요청하는 세부 경로가 /users/utube 인 경우라면 쿠키 전송이 가능하다.

하지만 /posts/utube로 전송되는 요청은 Path 옵션(/users)을 만족하지 못하기 때문에 서버로 쿠키를 전송할 수 없다.

• MaxAge or Expires = 쿠키의 유효기간 설정 -> 일정 시간 후 자동 소멸된다. 

MaxAge는 쿠키가 유효한 시간을 초 단위로 설정하는 옵션

Expires은 MaxAge와 비슷하지만 언제까지 쿠키가 유효한지 심판의 날을 지정 (클라이언트의 시간을 기준)

 

세션 쿠키: MaxAge 또는 Expires 옵션이 없는 쿠키로, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키이다. 브라우저를 종료하면 해당 쿠키는 삭제된다.

영속성 쿠키: 브라우저의 종료 여부와 상관없이 MaxAge 또는 Expires에 지정된 유효시간만큼 사용가능한 쿠키이다.

 

• HttpOnly = 스크립트의 쿠키 접근 가능 여부 결정 -> 쿠키는 경우에 따라 script태그로 접근이 가능할 수 있는데, 이는 XSS 공격에 취약하다. HttpOnly 옵션을 주면 script태그로 접근이 불가능하게 보안을 강화할 수 있다. 

해당 옵션이 true로 설정된 경우, 자바스크립트로 쿠키에 접근이 불가.

명시되지 않는 경우 기본으로 false로 지정되어 있다. (기본값 false)

옵션이 false인 경우 document.cookie를 이용해 자바스크립트에서 쿠키접근이 가능하므로 XSS 공격에 취약해진다. 

 

• Secure = HTTPS 프로토콜에서만 쿠키 전송 여부 결정

Secure 옵션이 true로 설정된 경우 HTTPS를 이용하는 경우에만 쿠키를 전송할 수 있다.

Secure 옵션이 없다면 프로토콜에 상관없이 http://www.google.com 또는 https://www.google.com에 모두 쿠키를 전송할 수 있다.

 

• SameSite = CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정 // Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션(e.g. GET, POST, PUT, PATCH …)의 조합을 기준으로 서버의 쿠키 전송 여부를 결정한다.

은행 사이트에 로그인 되어있는 상태에서 CSRF 공격을 받은 경우

1. A라는 사람이 은행 사이트에 로그인 한다. 

2. 은행은 A에게 유효한 토큰을 할당한다. 

3. 해커가 은행의 요청으로 가장한 위조된 요청을 보낸다. 

4. 해커의 링크를 클릭한 A는 자기도 모르는 새 은행에 위조된 요청이 보내진다. 

5. 위조된 요청은 이전에 할당된 A의 유효한 토큰을 통해 은행에서 실행된다. 

 

- Lax = Cross-Origin에서 GET 메서드 요청만 쿠키 전송 가능

- Strict = 쿠키 전송 불가 // Cross-Origin이 아닌 same-site 인 경우에만 쿠키를 전송 할 수 있다.

- None = Cross-Origin에서 모든 메서드 요청에 대해 쿠키 전송 가능 // Secure 쿠키 옵션이 필요하다!

 

서버에서 쿠키가 전송되지 않으면서 네트워크 탭에서 셋쿠키(Set-Cookie) 옆에 경고 아이콘이 보인다면  SameSite='none' 으로 설정해서 문제를 해결 할 수 있다. 

 

 

- 이때 same-site는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우이다. 이 중 하나라도 다르다면 Cross-Origin으로 구분된다. 

- 서버에서 이러한 옵션들을 지정한 다음 서버에서 클라이언트로 쿠키를 처음 전송하게 된다면 헤더에 Set-Cookie라는 프로퍼티로 쿠키를 담아 전송한다. 

- 이후 클라이언트에서 서버에게 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie라는 프로퍼티에 쿠키를 담아 서버에 쿠키를 전송한다. 

 

쿠키에는 노출되어서는 안되는 민감한 정보나 개인 정보를 담지 않는 것이 좋다!!

 

---

Session이란

 

- 서버와 클라이언트 간 연결이 활성화된 상태를 말한다. (사용자가 인증에 성공한 상태)

- 쿠키는 클라이언트에 정보를 저장하는 방식이었다면 세션은 데이터를 서버에 저장한다. 쿠키에는 그 데이터에 대한 ID만 암호화된 상태로 부여한다. 

- 중요 데이터는 서버에서 관리

 

세션도 결국은 쿠키에 유저의 정보를 담아준다. 

 

세션의 단점

세션은 서버의 저장공간에 세션 정보를 저장한다. 

만약 서버에 이용자가 매우 많은 경우라면 메모리같은 저장공간의 일정 부분을 항상 차지하고 있게 되므로 가용 메모리의 양이 줄어들어서 서버의 성능이 안좋아지는 결과를 초래할 수 있다. 

 

또한 쿠키를 완전히 대체하는 방법이 아니기 때문에 쿠키를 쓰고 있는데, XSS 공격으로인해 세션 쿠키가 탈취 당할 위험성이 있다. 

 

 

---

쿠키와 세션의 차이

	설명	접속 상태 저장 경로	장점	단점
Cookie	쿠키는 그저 http의 stateless 한 것을 보완해주는 도구	클라이언트	서버에 부담을 덜어줌	쿠키 그 자체는 인증이 아님
Session	접속 상태를 서버가 가짐 (stateful) 접속 상태와 권한 부여를 위해 세션 아이디를 쿠키로 전송	서버	신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능	하나의 서버에서만 접속 상태를 가지므로 분산에 불리

 

쿠키는 클라이언트에 쿠키를 전송해서 여러가지 정보를 저장했었지만, 쿠키는 유저가 삭제하지 않고 유효기간도 정해지지 않는다면 영원히 존재할 수 있다는 점에서 인증정보를 담아 보관하기에는 좋지 못한 방법이다. (쿠키는 그저 http의 stateless 한 것을 보완해주는 도구)

 

하지만 세션은 클라이언트에게 인증정보를 저장하지 않고 클라이언트마다 신분증과 같은 단 하나밖에 존재하지 않는 ID를 쿠키에 담아서 클라이언트에 전송을 해준다. 클라이언트의 중요한 데이터는 서버에서 관리를 한다. 이제 클라이언트는 전달받은 쿠키를 매 요청마다 자동으로 서버에 제공을 하게 되어서 해당 요청이 세션이 연결된 클라이언트라는 것을 서버에 알려주게 되고, 서버는 쿠키로 전달받은 세션 ID를 비교해서 적절하게 응답을 되돌려준다. 

 

 

😃 잘못된 개념 전달이 있다면 댓글 부탁드립니다. 저의 성장에 큰 도움이 됩니다🤓