1.0 기존의 공격
'기존'이라고 하는 것은 브라우저를 겨냥한 공격이 아니라는 뜻으로 저자가 부르는 것일 뿐, 일반적인 분류는 아니라고 한다. 기존형은 브라우저 외부인 OS에 접근하는 것이 특징이다. 컴퓨터에 위협을 주는 소프트웨어를 '맬웨어'라고 한다. 맬웨어는 증식 방법이나 목적에 따라 여러 가지로 분류된다.
증식 방법으로는 다른 실행 파일 등을 감염시켜 감염된 파일이 실행되면 다른 프로그램에도 자기 복제해서 증가하는 '컴퓨터 바이러스'와 적극적으로 네트워크 장비나 OS의 보안 취약점을 공격해 감염을 펼치는 '웜'이 있다. USB 메모리 같은 자동 실행 구조를 악용하거나 언뜻 분간하기 어려운 파일 이름이나 오피스 애플리케이션의 매크로 등을 이용하기도 한다. 어떤 프로그램이든 실행되지 않으면 의미가 없으므로, 이 맬웨어들은 사용자가 의도하지 않아도 실행되도록 계획한다. 바이러스처럼 다른 프로그램을 변조해, 그 프로그램을 시작할 때 실행되는 일도 있다. 웜의 경우 숙주가 없을 수도 있다. 이 경우 OS 부팅 스크립트나 레지스트리에 자신을 등록한다.
공격 방법도 몇 가지로 나눌 수 있다. 예전에는 단순히 OS를 부팅할 수 없게 만들거나 속도가 느려지게 하는 등 파괴가 목적인 것이 있었다. 그 외에는 OS 설정을 마음대로 바꿔 프록시 서버를 설정해서 통신 내용을 훔쳐보거나 키 입력을 기록해 암호를 훔치려는 것도 있다. 또 외부에서 원격 조작하기 위해 백도어를 설치하는 맬웨어도 있다. 이런 맬웨어는 특정 웹사이트의 서비스를 방해할 목적으로 일제히 대량의 요청을 보내버리는 DDos 공격의 발판이 될 수도 있다. 키 입력을 기록하는 것을 '키로거', 백도어를 만드는 것을 '트로이 목마'라고 부르는 등 행동에 따라 다양한 분류가 있다. 단 공격 수법이 서서히 인지되어 이름이 붙은 것도 있어, 이름이나 정의가 경우에 따라 다를 수 있다.
기존형으로 부르지만, 오래돼 더는 사용되지 않는다는 뜻은 아니다. 브라우저 플러그인의 보안 허점 등을 통해 언제든 컴퓨터에 대한 공격이 이루어질 수도 있다. 다음에 소개할 브라우저를 노린 공격의 전 단계로서 웹 서버에 침입해 전송할 데이터를 악의적인 스크립트로 변경하거나 데이터베이스에 액세스하여 사용자 정보를 훔칠 수 있다. 현재도 표적형 공격 메일로 대표되는 악성 프로그램을 전송해 이루어지는 공격은 중대한 위협 중 하나이며, 웹 서비스 개발자가 서비스를 보호하는 데 위협이라는 점은 변함이 없다.
2.0 브라우저를 노리는 공격의 특징
브라우저는 원래 '열람용 애플리케이션'이므로, OS 영역에서 뭔가를 하는 것은 아니다. 하지만 브라우저는 다른 서비스에 연결되는 창이다. 브라우저가 표적이 되고 브라우저에 저장된 다양한 웹사이트의 로그인 정보가 노출될 경우, 페이스북이나 라인 등 외부 서비스에 저장된 개인 정보 혹은 대화 내용 등을 도둑맞을 수 있다.
웹 서비스에서는 최근 두드러지게 발전한 프론트엔드 기술과 여러 사이트를 가로지르는 계정 연계, HTTPS/HTTP의 혼재 등 개발자가 알아야 할 사양의 복잡성이 증가하고 있다. 개별 보안 기능이 강력해도 웹 서비스 등 구현상의 실수나 착각 등으로 보안에 구멍이 생긴다. 정규 웹사이트에서 HTTP를 통해 전송된 문서 안에 함정이 설치되기도 한다.
브라우저 벤더는 보안에 민감하다. HTTP 사양에는 보안에 대한 배려가 많이 포함되어 있다. 리퍼러 설명에도 소개했지만, 기존 기능이라도 보안을 고려하여 기능이 수정되는 경우도 있다.
3.0 크로스 사이트 스크립팅
웹 서비스 개발자가 가장 먼저 주의해야하는 많은 공격의 기점이 되는 공격 방법이다. 게시판 등 사용자 입력 콘텐츠에서 사용자가 입력한 내용을 아무런 필터링 없이 공개하는 것이 가장 발생하기 쉬운 시나리오이다. 만약, '이름을 넣어주세요'라는 텍스트 상자가 있고, 거기에 데이터를 입력했다고 가정해보자. 이름은 다른 사용자도 볼 수 있다. 웹 서비스 쪽 프로그램에서 입력된 값을 전혀 확인하지 않고 HTML에 그대로 넣어 출력할 경우, 이름 대신 악의적인 스크립트가 삽입된 채로 게시되면 그 콘텐츠를 보는 사람의 브라우저에서 그대로 실행된다. 이를 '크로스 사이트 스크립팅'으로 줄여서 XSS라고 한다.
실제로 아래와 같은 내용이 삽입됐다고 하면, 이름을 볼 때마다 경고 대화 상자가 표시된다.
<script>alert("error");</script>
이것이 다른 모든 공격의 기점이 될 수 있다고 했다. 예를들어 투입된 스크립트가 쿠키에 액세스되면, 다른 서버로 전송되어 쿠키 정보가 유출된다. '로그인됨'이라는 세션 토큰을 도둑맞으면, 사용자 ID와 암호가 없어도 '로그인 상태'를 가로챌 수 있다. 또한 로그인 폼이 해킹되어 사용자가 입력한 정보를 다른 서버로 전송해버리거나 피싱 사이트로 전송되는 등 온갖 위험이 있다.
서버 측의 방어 방법으로는 여러 가지가 있다. 사용자가 입력한 내용을 그대로 HTML로 출력하는 일은 하지말자. 사용자 입력은 악의적인 입력이 들어올 것으로 보고 그대로 출력하지 않도록 해야한다. 이를 막기 위해 새니타이즈(입력 전)와 이스케이프(출력 전)하는 방법이 있는데, 현재는 이스케이프라는 출력 직전에 깨끗하게하는 방법이 일반적이라고 한다.
3.1 유출 방지 쿠키의 설정
XSS의 다음 방어선으로 httpOnly 속성을 부여하는 방법이 있다. 이 속성을 부여하면 자바스크립트에서 액세스할 수 없는 쿠키가 된다. XSS 공격자는 자바스크립트를 사용한다. 자바스크립트에서 액세스할 수 없는 정보에는 접할 수 없기 때문에 자바스크립트에 의한 세션 토큰 누설의 위험을 줄일 수 있다.
3.2 X-XXS-Protection 헤더
X-XXS-Protection 헤더를 사용하면 HTML의 인라인에서 스크립트 태그를 사용하는 경우 등 명확하게 수상한 패턴을 감지한다. X-가 붙은 비공식 헤더이지만, 인터넷 익스플로러, 크롬, 사파리 등의 브라우저가 지원한다. 단순한 패턴 매칭에 의한 판정이므로, 문제가 없는 코드 패턴을 '문제 있음'으로 판정하는 이른바 긍정 오류가 될 가능성이 있다.
3.3 Content-Security-Policy 헤더
웹사이트에서 사용할 수 있는 기능을 세밀하게 ON/OFF를 할 수 있는 강력한 기술로 W3C에 의해 정의됐다. 웹사이트에 필요한 기능을 서버에서 설정하여 XSS처럼 자바스크립트가 에상치 못한 동작하는 것을 억제한다.
또한 브라우저 환경에서는 헤더로 옵트인되지만, 크롬 OS 등에서 사용되는 크롬 앱은 Content-Security-Policy 지원이 필수로 되어있다.
Content-Security-Policy는 브라우저가 실시하는 검사이다. 오류는 클라이언트 쪽에 표시되지만, 서버 개발자가 그 오류 정보를 직접 볼 수는 없다. 오류 보고서를 보낼 곳을 지정해 클라이언트가 오류 정보를 통지함으로써 서버 개발자도 클라이언트에서 발생한 문제를 알 수 있다.
3.4 Content-Security-Policy와 자바스크립트 템플릿 엔진
자바스크립트가 널리 사용되고, 서버에서 하던 많은 일을 브라우저 환경에서 처리하게 되었다. 그 하나는 클라이언트 사이드에서의 HTML 템플릿이 있다.
Hogan.js는 트위터가 만든 자바스크립트용 템플릿 엔진이다. Mustache 템플릿 엔진과 같은 문법을 지원하지만, 고속으로 동작한다. 컴파일하면 템플릿을 해석해 내부 함수를 호출하는 소스 코드를 생성하고, 최종적으로 new Function을 사용해 함수를 동적으로 생성한다. 이로써 실행 시에 파싱 처리가 필요 없어지고, 옵션 전개와 문자열 결합에 특화되므로 문자열을 빠르게 생성할 수 있다.
이와 비슷한 사례로 자바스크립트 프레임워크인 Vue.js가 있다. 버전 2.0에서는 런타임 버전과 독립실행형 버전 두 가지로 출시됐다. 둘 사이의 차이는 아래와 같다.
- 독립실행형 버전은 template 옵션에 문자열로 HTML 템플릿을 작성할 수 있다. 이 템플릿은 실행 시에 자바스크립트 코드로 변환되고 new Function을 사용해 render() 메서드가 만들어진다.
- 런타임 버전은 template 옵션을 사용할 수 없다. 사전에 vue-loader(WebPack 용) 및 vueify(Browserify 용)에서 자바스크립트 소스 코드를 브라우저 환경용에 최적화하고 사전에 render() 메서드를 만들어둘 필요가 있다.
당연한 일이지만, new Function은 CSP(Content-Security-Policy)의 unsafe-eval 지시문에서 허용하는 문자열의 함수 동적 생성에 해당하므로 사용할 수 없다. 따라서 이런 템플릿 엔진은 Content-Security-Policy를 따를 때 장애가 된다.
3.5 Mixed Content
웹의 HTTPS화가 진행되고 있지만, 광고나 외부 서비스가 제공하는 콘텐츠 등으로 HTTP가 뒤섞이는 수가 있다. 요즘 브라우저는 이런 Mixed Content의 경우 오류 또는 경고를 내보내게 되어 있다.
근본적으로 모든 것을 HTTPS로 수정하는 이외의 대처 방법 중 하나로서, CSP 헤더의 upgrade-insecure-request 지시문을 사용하는 방법이 있다. 이 지시문을 사용하면 이미지 등의 링크가 http://로 시작되는 URL이라도 https://라고 적혀 있는 것처럼 가지러 간다. 하지만, 요즘은 naver, google 등이 프로토콜을 모두 h2 혹은 h3를 사용해서 사용될 일은 없을 것 같다..
4.0 중간자 공격
프록시 서버가 통신을 중계할 때 통신 내용을 빼내 정보가 누설되는 문제이다. HTTP 그대로 웹사이트의 로그인 폼을 이용해 로그인하면, 사용자 이름과 암호를 도둑맞게 된다. 로그인을 시도하지 않아도 세션 토큰을 훔쳐가면, 보호받아야 할 정보에 액세스를 허용하게 된다. 이런 중간자 공격을 방지하려면 HTTPS(TLS)를 이용하는 수밖에 없다. TLS는 '통신 경로를 신뢰할 수 없는' 상태에서도 보안을 유지하면서 통신할 수 있게 하는 메커니즘이다. 이로써 통신 내용 감청, 통신, 변조, 클라이언트와 서버의 의도하지 않은 요청 전송 등을 방지할 수 있다. 하지만, 서버에 대한 해킹이나 브라우저에 대한 XSS에는 주의할 필요가 있다.
세션 토큰이 쿠키로 저장되어 있어 조건(URL)이 맞으면 전손 요청 시 쿠키가 부여된다. XSS에서 소개한 바와 같이 서버가 쿠키를 부여할 때 secure를 지정해 TLS로 통신 경로가 보호될 때만 전송하므로 중간자 공격에 대한 내성이 높아진다.
4.1 HSTS
중간자 공격에 대항하는 HTTP의 기능 중 하나가 HTTP Strict Transport Security(HSTS)이다. HSTS는 서버 측에서 접속할 때 HTTPS로 접속해 달라고 전달하는 기능이다. 서버에서 HTTP를 통해 접속을 요청하고 싶을 때는 다음과 같은 헤더를 응답 헤더에 부여한다. includeSubDomains가 브라우저에 서브 도메인도 대상임을 전달한다. 물론 이 헤더를 반환할 때 동시에 리디렉션할 수도 있다.
Strict-Transport-Security: max-age=31536000;includeSubDomains
브라우저 내부에는 이 헤더를 보낸 URL의 데이터베이스가 있다. 브라우저가 지정된 사이트에 액세스할 때 자동으로 HTTPS 사이트에 접속하러 간다. 유효 기간 동안만 이 지시가 생존한다. 위 예시에서는 31,536,000초로 1년간 전송할 것을 브라우저에 의뢰한다.
HSTS에는 단점이 있다. 처음 연결할 때는 아직 HTTPS 로 접속하련느 서버의 지시가 도달하지 않은 상태이다. 그래서 첫 접속은 HTTP로 통신이 이루어진다. 이 상태에서 악의적인 프록시가 리디렉션 URL을 변조하면, 브라우저가 피싱 사이트로 유도될 가능성이 있다. TLS에는 서명이 있어서 변조되면 탐지할 수 있지만, 첫 번째 접속이 HTTP를 통해 이루어질 경우 브라우저에서 공격을 탐지할 수 없다.
이 문제를 해결하기 위해 새로운 방호벽이 추가됐다. 크롬은 처음부터 이 데이터베이스를 설정해두려고 정보를 수집한다. 웹사이트에 신청해두고 최신 브라우저를 다운로드하면, 처음부터 HTTPS로 접속하게 된다. RFC에는 없지만, 이곳에 신청한 경우에는 preload 지시문을 Strict-Transport-Security 헤더에 부여한다.
4.2 HTTP 공개 키 피닝
TLS 인증서에는 디지털 서명을 위한 공개 키가 붙어 있다. 이 공개 키를 사용해서 인증서를 검증한다. 피닝은 핀으로 고정한다는 의미이다. 공개 키 목록을 처음 액세스할 때 받아와서 로컬에 핀으로 꼽아 저장해둔다. 두 번째 이후로 액세스할 때는 서버가 보낸 인증서의 공개 키와 고정해둔 공개 키를 비교해 사이트 인증서가 무단으로 변경되지 않았는지 확인한다.
5.0 세션 하이재킹
이름 그대로 웹 서비스의 세션 토큰을 훔쳐 웹사이트에 로그인하는 공격이다. 일반 웹 서비스의 경우, 처음에 사용자 이름과 암호를 입력받은 후 로그인했음을 나타내는 세션 토큰을 쿠키로 브라우저에 보낸다. 브라우저가 이 쿠키를 저장하면 두 번째 이후 액세스부터는 사용자 이름과 암호가 필요 없어진다. 이 세션 토큰을 도난당하면 로그인된 상태로 웹 사이트에 액세스할 수 있으므로 사용자 이름 암호가 유출된 것과 같은 상태가 된다.
쿠키를 훔치는 행위의 발판이 되는 것이 크로스 사이트 스크립팅과 중간자 공격이다. 다음과 같은 방법으로 이러한 공격으로부터 자신을 보호하는 것이 세션 하이재킹을 피하는 효과적인 수단이다.
- HTTPS화
- Set-Cookie: httpOnly, secure
5.2 쿠키 인젝션
stateless한 HTTP에서 브라우저의 상태를 보존하는 쿠키는 편리한 반면, 항상 공격의 위험과 등을 맞대고 있다. 쿠키에 특화된 공격 방법도 발견됐다. 쿠키 인젝션을 그 중 하나이다.
쿠키 인젝션은 쿠키의 사양을 역으로 취한 방법으로 HTTPS 연결을 우회할 수 있다. 발표 당시의 공격 수법은 HTTPS로 은닉된 도메인의 쿠키에 대해 HTTP가 아닌 다른 하위 도메인으로부터 덮어쓰거나, 보다 URL의 상세한 쿠키를 설정함으로써 원래 HTTPS로 지정된 도메인의 쿠키를 무효화하고 세션 고정화 공격의 발판으로 하는 것이다.
2017/3 크롬 및 파이어폭스는 쿠키 인젝션에 대한 대책이 마련되어 있다. 서브 도메인에서 재구성할 수 없게 되어 있고, 동일한 도메인이라도 secure가 붙은 쿠키는 HTTP에서 덮어 쓸 수 없다.
6.0 사이트 간 요청 위조
피해자에게 의도하지 않는 조작을 하게 만드는 공격이 사이트 간 요청 위조(CSRF)이다. 본인이 의도하지 않은 서버에 요청을 관계없는 페이지나 사이트에서 보내게 할 수 있다. 실제로 요청을 보내는 것은 공격자가 아니라 피해 사용자이며, 웹 브라우저가 유도된 페이지에 대해서도 쿠키를 발행하므로 로그인 상태는 유지된다. 이로써 피해 사용자의 권한으로 임의의 조작을 실행할 수 있게 된다.
일본에서도 다른 사용자에게 살해 예고를 하도록 조작해서 무고한 사람을 범인으로 만드는 삭너이 일어난 적이 있었다. 이때도 CSRF가 이용됐다.
6.1 CSRF 대책 토큰
CSRF를 방지하는 방법으로는 HTTP 스테이트리스성을 제한하는 방법이 자주 사용된다. 폼을 설정할 때 숨겨진 필드에 무작위로 생성한 토큰을 집어넣고, POST 요청을 받은 서버 쪼겡서 올바른 토큰이 포함되지 않은 모든 요청을 거절하는 방법 등이 있다. 웹 애플리케이션 프레임워크에는 이 토큰을 생성하거나 토큰을 검증하는 미들웨어가 포함되어 있을 것이다.
브라우저 쪽에서는 CSRF 대책 토큰인지 아닌지 신경쓰지 않고, 저너송된 폼을 그대로 반환하기만 하므로 특별한 기능을 필요로 하지 않는다.
덧붙여 각 사용자의 고유한 값이라고 하면 세션 토큰이 떠오르지만, 세션 토큰을 CSRF 대책 토큰으로 사용해서는 안된다. 쿠키는 httpOnly로 보호할 수 있지만, CSRF 대책 토큰 구현 방법으로 자주 사용되는 것은 숨겨진 필드이므로 보호하지 못하고 자바스크립트에서 쉽게 접근할 수 있다.
6.2 SameSite 특성
크롬에서 쿠키에 해당 특성을 부여할 수 있다. 이 특성을 부여하면 요청을 보내기 전의 페이지가 같은 사이트에 없는 한 쿠키를 보내지 않게 된다. 이렇게 하면 무관한 사이트에서 요청할 수 없으므로 CSRF를 방지할 수 있다.
7.0 클릭재킹
클릭재킹 사례는 두 가지 모두 IFRAME을 이용한다. 하나는 트위터 등 자주 사용되는 웹사이트를 투명하게 하여 악의적인 페이지 위에 겹치는 방법이다. 사용자가 볼 때는 악의적인 페이지가 표시된다. 예를들어, 클릭 유도 버튼을 자주 사용하는 웹사이트에서 로그아웃, 소셜 네트워크 공유 등의 버튼에 맞춰 배치함으로써 사용자가 인지하지 못한 채 유도된 작업을 하게 된다. 사이트 간 요청 위조와 같은 공격이 실제 사이트에 대해 직접 실행된다.
7.1 X-Frame-Options 헤더
IFRAME 내부에 표시될 뿐이지 웹사이트 쪽에서 보면 사용자의 조작은 평소와 같으므로, 사이트 간 요청 위조 같은 조치는 취할 수 없다. 브라우저의 클릭재킹 방지 기능으로는 X-Frame-Options 헤더가 있다. 악용되는 것을 막고 싶은 정규 사이트 쪽에서 이 헤더를 전송하면 페이지가 IFRAME내에서 이용되는 것을 방지한다. 브라우저는 이 헤더를 보고 적절하게 표시를 거절함으로써 사용자를 보호한다.
8.0 리스트형 계정 해킹
보안에 취약한 웹 서버가 해킹당해 사용자 ID 및 일반 텍스트로 저장된 비밀번호가 유출되면, 같은 이메일 주소와 비밀번호를 돌려쓰는 사용자의 보안은 무효가 된다는 것이다.
2FA, 지오로케이션 등을 이용해서 방지할 수는 있다. 하지만, 와벽하게 막을 수 없기때문에 사용자가 신경써서 서비스마다 다른 암호를 설정하는 것이 가장 견고한 보안 대책이다.
9.0 웹 애플리케이션을 위한 보안 가이드라인
- X-Frame-Options 헤더
- Content-Security-Policy 헤더
- Strict-Transport-Security 헤더
- Public-Key-Pins 헤더
- Set-Cookie 헤더
- CSRF 대책 토큰
- 2단계 인증
- 지오IP
- X-Content-Type-Options 헤더
- X-XSS-Protection 헤더
10.0 웹 광고 및 보안
TV 광고는 프로그램을 시청하는 사람의 취향을 생각하지않고, 똑같은 광고를 일률적으로 내보내는 구조이다. 반면에 웹 광고는 한 걸음 더 나아가 같은 사이트에서도 사용자마다 광고를 다르게 내보낼 수 있다. 효율적으로 사용자의 관심을 끄는 광고를 내보내려면, 어떤 사용자가 무엇에 관심이 있는지 정보를 얻는 것이 이상을 실현하는 열쇠이다.
이를 실현하기 위해서 방문한 URL 목록을 가져와 사용자의 취향을 추정한다. 광고가 사용자에게 ID를 할당하고, 광고 업자가 추적하는 웹사이트를 사용자가 방문했다는 정보를 기록해 점을 연결함으로써 사용자의 열람 기록을 복원하는 기술이다.
기술에는 쿠키 기반 측정 방식과 핑거 프린트 방식이 있다. 하지만, 방문한 웹사이트의 기록 정보가 개인 정보에 해당한다. 웹 브라우저 업체는 개인의 사생활을 보호하는 방향으로 기능을 강화하고 있다. 웹 광고의 역사는 보안과 투쟁의 역사이다.
10.1 서드파티 쿠키
쿠키에는 퍼스트파티 쿠키, 서드파트 쿠키가 있다. 브라우저가 액세스한 서비스가 해당 서비스 내에서만 유효한 쿠키를 퍼스트파티 쿠키, 광고 등의 용도로 외부 서비스에서 읽을 수 있는 쿠키를 삽입해, 사이트를 넘어서 행동 추적을 가능하게 해주는 쿠키가 서드파티 쿠키라고 한다.
한 사이트에 쿠키가 저장되어 있기 때문에 사용자가 직접 사이트를 방문하는 경우라면 해당 사이트 서버로 쿠키가 직접 전송되며, 그 시점에서 사용자가 과거에 방문했던 정보를 모아서 가져올 수 있다.
10.2 쿠키 이외의 대체 수단
클라이언트를 고유하게 식별하는 수단으로 가장 많이 사용되는 방법이 쿠키에 세션 토큰을 기록하는 방법이다. 쿠키의 경우 보안 강도에 따라 무시하거나 재설정하거나 화긴하는 수단도 있지만, 다른 방법으로 재설정하기 어려운 쿠키 흉내를 낼 수 있다. 이를 좀비 쿠키라고 한다. 자바스크립트를 사용해 이러한 쿠키를 조작하는 라이브러리로 에버쿠키도 있다.
- HTML5의 각종 스토리지 (세션, 로컬, 글로벌)
- 서버에 액세스해 ID를 취득하고 브라우저의 쿠키 영역이 아니라 브라우저가 따로 준비한 스토리지에 저장함으로써 쿠키와 같은 기능을 실현
- ETag
- 절대로 변하지 않는 이미지 파일 등의 ETag에 사용자 ID를 넣어 클라이언트에 전송함으로써 실현
- 임의로 생성한 이미지
- 픽셀 단위로 색 정보를 추출할 수 있으므로 ID 값을 여러 픽셀의 색 정보로서 삽입
- 기타 플래시나 실버라이트, 자바 애플릿 등의 저장 영역
이러한 수단을 사용하면 어느 샌가 ID가 삽입되어 행동이 감시당할 우려가 있다.
10.3 구글 애널리틱스
광고 이외에도 사용자 식별에 의미가 있는 경우가 있다. 사용자의 방문 기록을 가져오는 구글 애널리틱스가 해당된다. 구글 애널리틱스의 경우 웹사이트에 자바스크립트를 설치한다. 자바스크립트 코드를 사용해 웹사이트는 자신의 도메인 안에서 움직인다는 전제로 퍼스트파티 쿠키로서 ID 정보를 쿠키에 저장한다.
10.4 사용자를 특정하지 않고 추정
익스페리언의 AdTruth에서 사용하는 방법은 쿠키 등으로 ID를 브라우저에 심어서 이용하는 방법과 다르다. IP 주소나 브라우저가 보낼 유저 에이전트 정보 등 외부에서 관츨할 수 있는 정보를 바탕으로 단말기의 동일성을 추측하는 방법으로 핑거 프린트 방식이다. 클라이언트 쪽에는 어떠한 정보도 가지지 않고, 서버 쪽에서 추정 한 ID를 바탕으로 광고를 게재한다. 익스페리언의 웹사이트에 따르면 아래 정보를 바탕으로 하고 있다고 한다.
- CPU, 시스템 설정 언어, 유저 에이전트, 사용자 설정 언어, 기본 언어 설정
- 브라우저 애플리케이션 코드명, 브라우저 이름, 버전, 언어
- 브라우저 플러그인
- 시스템 시각, 스크린 설정, 폰트 높이
- 도메인, 로컬 시간, 시간대
지오IP에 가까운 정보같다. 그러나 이 기법은 미국에서는 잘 동작하는 것 같지만, 타 지역에서는 정확도에 문제가 있다고 한다.
Reference
