Web11: HTTP 쿠키 및 일부 보안 문제

1. 소개

쿠키 또는 HTTP 쿠키, 웹 쿠키, 브라우저 쿠키는 웹사이트에서 전송된 작은 데이터 조각으로, 사용자가 이 웹사이트를 탐색할 때 사용자의 브라우저에 저장됩니다. 사용자가 웹사이트를 로드할 때마다 브라우저는 자동으로 웹 서버에 쿠키를 보내 사용자의 이전 작업을 웹사이트에 알립니다.

쿠키는 웹사이트가 상태 정보(장바구니에 있는 항목 등)를 기억하거나 사용자 활동(클릭 수 포함)을 저장하는 데 도움이 되는 신뢰할 수 있는 메커니즘으로 설계되었습니다. 링크, 로그인, 주, 월 또는 연도 동안 방문한 페이지... ).

쿠키는 바이러스를 운반할 수 없고 컴퓨터에 악성 코드를 설치할 수도 없지만 추적 쿠키, 특히 제3자 쿠키의 사용은 사용자의 검색 기록에서 개인 정보를 식별하는 방법으로 간주됩니다. 쿠키는 신용카드 번호나 개인 주소와 같이 사용자가 HTML 양식에 입력하는 비밀번호나 콘텐츠를 저장할 수 있습니다.

이용자가 웹사이트를 처음 방문할 때, 웹서버에서 브라우저로 쿠키가 전송되어 이용자의 컴퓨터에 저장됩니다. 그 후, 그가 웹사이트로 돌아오면 웹사이트는 쿠키에 저장된 정보를 통해 그를 인식하게 됩니다.

인증 쿠키는 사용자가 웹사이트에 로그인했는지 여부를 확인하는 데 사용되는 일반적인 방법입니다. 이러한 메커니즘이 없으면 웹사이트가 언제 사용자에게 개인정보를 전송해야 하는지 알기 어렵고 사용자가 여러 번 로그인하도록 강제할 수 없습니다. 인증 쿠키는 매우 편리하기는 하지만 해커가 쿠키에 포함된 민감한 데이터를 읽을 수 있는 기회를 만들어 사용자에게 해를 끼치는 작업을 수행합니다.

2. HTTP 쿠키 개요

2.1. 역사

쿠키라는 용어는 컴퓨터 프로그램이 주고받는 변하지 않는 데이터 조각인 매직 쿠키라는 용어에서 파생되었습니다. Lou Montuli라는 프로그래머는 1994년에 웹 커뮤니케이션에 매직 쿠키를 사용하는 아이디어를 내놓았습니다. 당시 그는 Netscape Communications에서 MCI용 전자 상거래 애플리케이션 개발 프로젝트를 진행하고 있었습니다. 쿠키는 가상 장바구니 구축의 솔루션으로 사용되어 MCI 서버가 거래 상태를 저장할 필요 없이 대신 사용자 컴퓨터에 저장되도록 돕습니다.

John Giannandrea와 함께 Montuli는 Netscape 쿠키에 대한 첫 번째 사양을 작성했습니다. 1994년 10월 13일에 출시된 모자이크 넷스케이프 버전 0.0베타는 쿠키를 지원했습니다. 쿠키의 최초 사용(실험실 외부)에서는 넷스케이프 웹사이트를 방문한 고객이 이전에 방문한 적이 있는지 확인했습니다. Montuli는 1995년에 쿠키 특허를 받았습니다. 그리고 Internet Explorer 버전 2(1995년 10월 출시)에는 쿠키 사용이 통합되었습니다.

이 기간 동안 쿠키의 도입은 널리 보급되지 않았습니다. 특히, 쿠키는 기본적으로 허용되며 사용자에게 쿠키 존재 여부를 알리지 않습니다. 대중은 쿠키에 관한 기사가 1996년 2월 12일 Financial Times에 게재된 후에야 쿠키에 대해 알게 되었습니다. 그 이후로 쿠키, 특히 쿠키에 포함된 개인 정보가 많은 관심을 받았습니다. 쿠키는 1996년과 1997년 두 번의 미국 연방거래위원회 청문회에서 논의되었습니다.

공식적인 쿠키 사양에 대한 첫 번째 논의는 1995년 4월에 시작되었습니다. 이 작업을 수행할 목적으로 IETF(Internet Engineering Task Force) 내에 특별 그룹이 구성되었습니다. 마지막으로 1997년 2월에 그룹에서 사양을 발표했습니다. 사양에서는 제3자 쿠키를 모든 사람이 허용하지 않거나 적어도 기본적으로 활성화되지 않은 것으로 정의했습니다. 2011년 4월, 실제 사용되는 쿠키에 대한 표준 사양이 문서 RFC 6265
에 게시되었습니다 .

2.2. 술어

세션 쿠키

인메모리 쿠키 또는 임시 쿠키라고도 하는 세션 쿠키는 사용자가 웹사이트를 탐색하는 동안 임시 메모리에만 존재합니다. 쿠키 생성 시 만료 날짜나 유효 간격이 설정되지 않은 경우 세션 쿠키가 설정됩니다. 일반적으로 웹 브라우저는 사용자가 브라우저를 닫을 때 세션 쿠키를 자동으로 삭제합니다.

영구 쿠키

영구 쿠키는 사용자의 세션을 연장합니다. 영구 쿠키의 최대 수명이 1년으로 설정된 경우 해당 기간 동안 사용자가 웹사이트를 방문할 때마다 쿠키에 설정된 초기 값이 서버로 전송됩니다. 이는 사용자가 웹사이트를 처음 방문한 방법과 같은 중요한 정보를 기록하는 데 사용될 수 있습니다. 이러한 이유로 영구 쿠키를 추적 쿠키라고도 합니다.

안전한 쿠키

보안 쿠키는 HTTPS를 사용할 때 활성화되는 보안 속성으로, 클라이언트에서 서버로 전송될 때 쿠키가 항상 암호화되도록 보장하여 정보 도청 및 노출을 방지합니다. 또한 모든 쿠키는 브라우저의 동일 출처 정책을 준수해야 합니다.

HttpOnly 쿠키

쿠키의 HttpOnly 속성은 대부분의 브라우저에서 지원됩니다. HttpOnly 세션 쿠키는 하나의 HTTP(또는 HTTPS) 요청에만 사용되므로 Javascript와 같은 HTTP가 아닌 API에 의한 액세스가 제한됩니다. 이 제한은 XSS(교차 사이트 스크립팅) 취약점을 통한 쿠키 도난을 완화하지만 제거하지는 않습니다.

제3자 쿠키

자사 쿠키는 브라우저의 주소 표시줄에 표시되는 동일한 도메인(또는 동일한 도메인 내의 하위 도메인)에 속하는 쿠키입니다. 제3자 쿠키는 브라우저의 주소 표시줄에 표시되는 다양한 도메인에 속하는 쿠키입니다. 웹사이트에는 사용자의 검색 기록을 추적할 수 있는 제3자 도메인의 콘텐츠(예: 배너 광고)가 있을 수 있습니다. 대부분의 브라우저의 개인 정보 보호 설정은 제3자 추적 쿠키를 차단합니다.

예를 들어, 사용자가 example1.com 웹사이트를 방문한다고 가정해 보겠습니다 . 이 웹사이트에는 ad.foxytracking.com의 광고가 포함되어 있습니다. 로드되면 ad.foxytracking.com의 쿠키가 저장됩니다. 그런 다음 그는 ad.foxytracking.com의 광고가 포함된 다른 웹사이트(example2.com)를 방문하고 ad.foxytracking.com에 속하는 쿠키도 설정합니다. 마지막으로, 이 두 쿠키는 광고를 로드하거나 웹사이트에 액세스할 때 광고주에게 전송됩니다. 광고주는 이러한 쿠키를 사용하여 광고가 포함된 모든 웹사이트에서 사용자의 검색 기록을 구축할 수 있습니다.

2014년에는 100개 이상의 제3자 도메인에서 읽을 수 있는 쿠키를 설정한 웹사이트가 몇 군데 있었습니다. 평균적으로 웹사이트에는 약 10개의 쿠키 세트가 있으며 최대 쿠키 수는 800개가 넘습니다.

슈퍼쿠키

슈퍼쿠키는 .com과 같은 최상위 도메인이나 .co.uk와 같은 공개 접미사에서 발생하는 쿠키입니다. 일부 보안 문제로 인해 브라우저에서 슈퍼쿠키를 차단하는 것이 중요합니다. 차단이 해제되면 악의적인 웹사이트를 제어하는 ​​공격자는 사용자 요청을 가장하여 동일한 최상위 도메인이나 공개 접미사를 공유하는 다른 웹사이트에 요청을 보내는 슈퍼쿠키를 설정할 수 있습니다. 예를 들어, .com 도메인에서 생성된 슈퍼쿠키는 쿠키가 example.com에서 생성되지 않았더라도 example.com에 대한 요청에 해를 끼칠 수 있습니다. 이는 로그인을 위조하거나 사용자 정보를 변경하는 데 악용될 수 있습니다.

좀비 쿠키

좀비 쿠키는 사용자가 삭제한 후 자동으로 다시 생성되는 쿠키입니다. 이는 플래시 콘텐츠 저장소, HTML5 저장소 또는 기타 클라이언트 측 메커니즘과 같은 다른 위치에 쿠키 콘텐츠를 저장하는 스크립트에 의해 수행됩니다.

2.3. 쿠키 구조

4KB 크기의 쿠키에는 7가지 주요 구성 요소가 포함됩니다.

1. 이름
2. 값
3. 만료(만료일)
4. 경로(쿠키가 유효한 경로, "/"는 쿠키가 모든 경로에서 유효함을 의미)
5. 도메인
6. 안전한
7. HttpOnly

처음 두 구성 요소(이름 및 값)는 필수입니다.

2.4. 사용

세션 관리

쿠키는 여러 웹사이트 방문에 걸쳐 사용자 관련 데이터를 유지하는 데 사용될 수 있습니다. 쿠키는 사용자가 제품을 탐색하는 동안 선택한 항목을 저장하는 데 도움이 되는 가상 장바구니인 장바구니를 생성하기 위한 솔루션입니다.

현재 장바구니 애플리케이션은 장바구니에 있는 항목 목록을 클라이언트측 쿠키에 저장하는 대신 서버측 데이터베이스에 저장하는 경우가 많습니다. 웹 서버는 일반적으로 세션 식별자(고유한 세션 ID)가 포함된 쿠키를 보냅니다. 웹 브라우저는 각 사용자의 쇼핑 요청과 함께 이 세션 ID를 반환합니다.

사용자가 웹사이트에 로그인하도록 허용하는 것도 쿠키의 또 다른 적용입니다. 일반적으로 처음 로그인하는 동안 웹 서버는 클라이언트에게 세션 ID가 포함된 쿠키를 보냅니다. 사용자는 자신의 정보를 제출하고 웹 애플리케이션은 세션을 인증한 다음 사용자가 해당 서비스를 사용할 수 있도록 허용합니다.

쿠키는 빠르고 편리한 클라이언트/서버 상호 작용 메커니즘을 제공합니다. 쿠키의 장점 중 하나는 사용자 정보를 사용자 컴퓨터에 있는 파일에 저장한다는 것입니다. 이는 서버의 저장 공간과 처리 시간을 크게 줄여줍니다.

맞춤형

쿠키는 사용자가 웹사이트를 방문할 때 사용자의 개인 정보를 기억하고, 사용자가 웹사이트를 다시 방문할 때마다 해당 사용자에게 더 관련성 높은 콘텐츠를 표시하는 데 사용될 수 있습니다.

대표적인 예가 amazon.com의 도서 추천 기능입니다. 사용자가 책을 클릭하면 Amazon은 사용자가 확인해야 할 다음 책에 대한 제안을 제공합니다. 이러한 제안은 사용자가 이전에 탐색한 책과 구매하기로 선택한 책을 기반으로 합니다.

또 다른 예는 Google 검색의 검색 제안 기능입니다. 개인 계정으로 로그인하여 검색을 수행하면 Google은 "당신만을 위한" 제안을 제공하며, 원하는 결과는 항상 목록 상단에 나타납니다.

감시 장치

추적 쿠키는 사용자의 검색 기록을 추적하는 데 사용될 수 있습니다. 웹사이트에 요청을 보내는 컴퓨터의 IP 주소를 사용하거나 HTTP 요청 헤더의 추천자 필드를 사용하여 이 작업을 수행할 수도 있지만 쿠키는 더 정확한 정보를 제공합니다. 이는 다음과 같이 수행됩니다.

1. 사용자가 웹사이트를 방문했지만 이 요청에 쿠키가 포함되어 있지 않은 경우 서버는 사용자가 이 웹사이트를 처음 방문한 것으로 가정합니다. 서버는 임의의 문자열을 생성하여 요청된 웹페이지와 함께 이를 쿠키로 브라우저에 다시 보냅니다.
2. 이 시점부터 쿠키는 이 웹사이트의 새 웹페이지가 요청될 때마다 브라우저에 의해 자동으로 서버로 전송되며, 서버는 요청된 웹페이지를 정상적으로 반환하지만 해당 웹페이지의 URL과 시간 액세스는 로그 파일에 저장됩니다. 이 로그 파일에 저장된 정보를 분석하면 해당 사람의 검색 기록, 자주 방문한 웹사이트, 검색 습관이 드러납니다.

2.5. 전개

쿠키는 서버에서 브라우저로 전송되는 데이터입니다. 그러면 브라우저는 사용자가 웹사이트에 요청을 보낼 때마다 내부 콘텐츠를 변경하지 않고 이를 서버로 다시 보냅니다. 쿠키는 Javascript와 같은 스크립팅 언어로 설정할 수도 있습니다.

각 웹 브라우저는 4KB 파일에 최소 300개의 쿠키를 저장할 수 있으며, 서버 또는 도메인당 최소 20개의 쿠키를 저장할 수 있습니다.

쿠키 설정

웹 서버와 브라우저는 HTTP(HyperText Transfer Protocol)를 통해 서로 통신합니다. 예를 들어 http://www.example.org/index.html 페이지에 액세스하기 위해 브라우저는 다음과 같은 HTTP 요청을 보내 서버에 연결합니다.

서버는 브라우저에 HTTP 응답이라는 간단한 텍스트 패킷을 보내 응답합니다. 이 패킷에는 쿠키 내용이 포함된 줄이 포함될 수 있습니다.

Set-Cookie는 쿠키를 저장하고 나중에 서버에 요청이 있을 때마다(쿠키가 아직 만료된 경우) 서버에 보내도록 브라우저에 지시하는 필드입니다. 예를 들어, 브라우저는 다음과 같은 HTTP 요청을 보내 http://www.example.org/spec.html에 요청을 보냅니다.

동일한 서버에 속한 다른 페이지에 대한 요청입니다. 이 경우 서버는 이 요청이 이전 요청과 관련되어 있음을 이해하고 요청된 웹 페이지를 브라우저에 전송하여 응답하며 다른 쿠키 값을 추가할 수도 있습니다.

쿠키 값은 HTTP 응답의 Set-Cookie: name=value 필드를 브라우저에 전송하여 서버에서 수정할 수 있습니다. 그러면 브라우저는 이전 쿠키 값을 이 새 값으로 바꿉니다.

쿠키 값에는 ",", ";"를 제외한 인쇄 가능한 모든 ASCII 문자가 포함될 수 있습니다. 그리고 공백. 쿠키 이름에는 이름과 값을 구분하는 '=' 문자도 포함될 수 없습니다.
부스러기 쿠키라는 용어는 때때로 쿠키의 이름-값 쌍을 가리키는 데 사용됩니다.

쿠키는 Javascript 또는 유사한 스크립트 언어로 설정할 수도 있습니다. Javascript에서는 document.cookie 개체를 사용하여 쿠키를 설정합니다. HttpOnly 속성은 잘못된 스크립트가 쿠키 콘텐츠를 읽지 못하도록 방지합니다.

쿠키 속성

이름-값 쌍 외에도 서버는 Domain, Path, Expirse, Max-Age, Secure 및 HttpOnly와 같은 여러 다른 쿠키 속성을 설정할 수도 있습니다. 브라우저는 이러한 속성을 서버에 보내지 않고 이름-값 쌍만 보냅니다. 이러한 속성은 브라우저에서 쿠키 삭제, 쿠키 차단 또는 서버에 쿠키 전송 시기를 결정하는 데 사용됩니다.

도메인 및 경로

도메인과 경로에 따라 쿠키의 범위가 결정됩니다. 이를 통해 브라우저는 쿠키를 서버에 보낼 시기를 결정할 수 있습니다. 지정하지 않으면 기본적으로 요청된 개체의 도메인과 경로가 사용됩니다. 그러나 도메인 속성이 없는 foo.com에 대한 쿠키 세트와 도메인 foo.com 속성이 있는 쿠키 세트 간에는 차이가 있습니다. 첫 번째 경우, foo.com에 요청이 있을 때만 쿠키가 전송됩니다. 후자의 경우 쿠키는 foo.com의 모든 하위 도메인으로 전송됩니다. 다음은 사용자가 로그인한 후 docs.foo.com에 대한 요청에서 웹사이트의 Set-Cookie 지시문의 예입니다.

첫 번째 쿠키 LSID에는 도메인 속성이 없으며 /accounts 경로가 있습니다. 브라우저는 요청한 페이지가 docs.foo.com/accounts에 포함된 경우에만 쿠키를 보냅니다. 나머지 두 개의 쿠키인 HSID와 SSID는 foo.com의 하위 도메인에 대한 요청이 있는 경우 서버로 다시 전송됩니다.
쿠키는 최상위 도메인과 하위 도메인에만 설정할 수도 있습니다. 보안상의 이유로 www.bar.com 에서 www.foo.com 에 쿠키를 설정하는 것은 허용되지 않습니다.

만료 및 최대 기간

Expires 속성은 브라우저에 쿠키 삭제 시기를 알려줍니다. Expires의 날짜는 "Wdy, DD Mon YYYY HH:MM:SS GMT"와 같습니다. Max-Age는 쿠키의 만료 날짜를 나타내는 데에도 사용됩니다. 다음 예를 고려해 보겠습니다.

첫 번째 쿠키는 2013년 1월 15일에 만료되도록 설정되어 있으며, 이 쿠키가 만료되면 브라우저에서 사용됩니다. 두 번째 쿠키 made_write_conn은 만료되지 않으며 세션 쿠키로 사용되며 브라우저가 꺼지면 삭제됩니다. 세 번째 쿠키 reg_fb_gate는 만료 날짜가 과거이므로 즉시 삭제됩니다.

안전하고 HttpOnly

Secure 및 HttpOnly 속성은 null입니다. 대신 해당 속성이 있으면 Secure 및 HttpOnly 기반이 적용되었음을 나타냅니다.

Secure 속성은 암호화된 연결 내에서 쿠키 전송을 유지합니다. 웹 서버가 비보안 연결에서 보안 속성을 사용하여 쿠키를 설정하는 경우에도 메시지 가로채기(man-in-the-middle) 공격으로 쿠키를 가로챌 수 있습니다.

HttpOnly 속성은 Javascript 등 HTTP(또는 HTTPS) 이외의 연결을 통해 쿠키를 노출하지 않도록 브라우저에 지시하므로 XSS(Cross-Site Scripting) 취약점을 악용하여 쿠키를 얻기 어렵게 만듭니다.

3. 쿠키 사용 시 일부 보안 문제

웹사이트가 세션 ID를 사용하여 사용자 세션을 식별하는 경우 공격자가 잠재적으로 쿠키를 훔쳐 사용자를 가장할 수 있습니다. 다음은 몇 가지 일반적인 쿠키 도난 시나리오입니다.

도청

네트워크의 트래픽은 제3자(수신자와 발신자 제외)가 가로채서 읽을 수 있습니다. 이 트래픽에는 쿠키가 포함되어 있습니다. 전송 내용이 암호화되지 않으면 공격자가 쿠키에 포함된 중요한 정보를 읽을 수 있습니다. 그리고 공격자는 이 정보를 이용하여 사용자를 사칭하여 은행 거래와 같은 위험한 작업을 수행합니다.

이 문제는 사용자 컴퓨터와 서버 사이의 보안 프로토콜인 HTTPS 프로토콜을 사용하여 해결할 수 있습니다. 서버는 쿠키를 설정할 때 Secure 플래그를 사용할 수 있습니다. 그러면 쿠키는 SSL 연결과 같은 암호화된 채널을 통해서만 전송됩니다.

크로스 사이트 스크립팅

Javascript와 같은 스크립트 언어는 쿠키 값을 읽고 이를 임의의 서버로 보내는 것이 허용됩니다.

웹사이트에 교차 사이트 스크립팅 오류가 있다고 가정하면 해커는 다음과 같은 악성 코드를 삽입할 수 있습니다.

피해자가 위 링크를 클릭하면 브라우저는 onclick 속성의 스크립트를 실행하여 피해자의 쿠키를 서버 Attacker.com으로 보냅니다.

크로스 사이트 스크립팅은 웹사이트의 일반적인 취약점 중 하나입니다(OWASP에 따르면 2013년 가장 일반적인 취약점 상위 10개 중 3위를 차지함).

쿠키에 HttpOnly 플래그를 설정하면 이 취약점의 위험을 제한할 수 있습니다. 그 당시에는 스크립트 언어로 쿠키에 액세스할 수 없습니다.

교차 사이트 요청 위조

CSRF(Cross-site request forgery) 또는 원클릭 공격은 피해자(웹사이트에서 승인한 사용자)가 승인되지 않은 명령을 실행하여 웹사이트의 취약점을 악용하는 방법입니다.

CSRF는 피해자의 브라우저를 속여 웹 애플리케이션에 http 요청을 보내도록 합니다. 피해자의 세션이 만료되지 않은 경우 위의 요청은 피해자의 인증권한으로 이루어집니다.

예를 들어, 피해자 Bob은 특정 은행 X의 웹사이트에서 거래를 하고 있습니다. Fred는 공격자입니다. 이 사람은 다음과 같이 계좌 A에서 계좌 B로 돈을 이체하려고 할 때 은행 X 웹사이트가 어떻게 작동하는지 알고 있습니다.

http://bank.example.com/withdraw?account=accountA&amount=100&for=accountB

그는 Bob에게 악의적인 메시지를 보낼 것입니다.

X은행이 사용자 인증 정보를 쿠키에 저장하고, Bob이 위 링크를 클릭하면 Bob의 돈이 Fred에게 이체됩니다.

이러한 위험을 제한하기 위해 쿠키에 대해 Expires 매개변수를 설정할 수 있습니다.

4. 결론

쿠키는 오늘날 대부분의 웹 애플리케이션에서 사용됩니다. 또한 사용자에게 심각한 영향을 미치는 잠재적인 위험도 포함되어 있습니다. 따라서 개발자 입장에서는 쿠키를 명확히 이해하고, 필요한 매개변수 설정 방법을 알아야 애플리케이션이 해커의 공격으로부터 더욱 안전할 수 있습니다.