프론트엔드 관점에서 바라본 납치 광고

납치광고

2025년 6월 20일, 방송통신위원회는 사용자가 클릭하지 않았음에도 특정 사이트로 강제 이동시키는 광고(이른바 ‘납치광고’)에 대한 사실조사 착수를 발표했다. 이러한 납치 광고는 웹 사용자에게 상당한 불편과 불쾌감을 준다.

이 글에서는 프론트엔드 개발자의 시각에서 납치 광고가 어떤 목적으로, 어떤 기술적 원리를 통해 사용자를 '납치'하는지 분석하고, 이를 방어할 수 있는 방법에 대해 다루고자 한다.

왜 납치하는가?

납치 광고의 목적은 크게 두 가지로 나눌 수 있다.

단순 사이트 홍보 : 특정 웹사이트를 사용자에게 강제로 노출시켜 인지도를 높이고 트래픽을 늘리려는 목적.
제휴 마케팅 악용 : 제휴 마케팅을 악용하여 수수료 수익을 얻는 목적.

제휴 마케팅이란?

많은 온라인 플랫폼 및 기업들은 마케팅의 일환으로 제휴 프로그램을 운영한다. 블로거나 웹사이트 운영자 같은 파트너가 자신의 채널에 고유한 링크를 공유하고, 그 링크를 통해 매출이나 회원가입이 발생하면 약속된 수수료를 제공하는 방식이다.

예를 들어, 대표적인 제휴 마케팅 프로그램인 쿠팡의 쿠팡 파트너스의 경우, 파트너가 생성한 추천 링크를 통해 사용자가 쿠팡에 방문하면, 24시간 내에 발생하는 모든 매출의 일부(예: 3%)를 파트너에게 수수료로 지급한다

하지만 일부 공격자들은 사용자의 의도와 전혀 상관없이 강제로 제휴 링크를 방문하게 만들어 수수료를 챙긴다. 사용자의 의도와 무관하게 진입을 유도하는 광고는 명백한 약관위반이다.

제휴 마케팅의 원리 : 어떻게 추천인을 파악할까?

플랫폼은 어떻게 수많은 사용자 중 누가 특정 파트너를 통해 유입되었는지 식별할까?

쿠팡파트너스의 예시

쿠팡 파트너스의 예를 통해 구체적인 동작 방식을 살펴보자.

파트너는 쿠팡 파트너스에서 https://link.coupang.com/a/example와 같은 고유 URL을 발급받는다.
사용자가 해당 URL에 접속하면, 서버는 Set-Cookie 헤더를 통해 브라우저에 추천인 정보를 담은 쿠키를 저장하도록 한다. 이후 실제 상품페이지로 리다이렉트한다. 모바일 디바이스 경우의 모바일 웹에서 보기와 앱에서 열기 선택지가 주어진다.
리다이렉트된 최종 상품 페이지 URL에는 ?lptag=EXAMPLEID88와 같이 추천인 코드가 쿼리 파라미터로 포함된다. (발급된 고유 URL을 거치지 않고 최종 상품페이지에 접속하면 쿠키는 발급되지 않는다.)

발급된 쿠키는 다음과 같다.

이름 : trac_lptag
값 : EXAMPLEID88
Domain : .coupang.com
expires: (발급 시점으로부터 24시간 뒤)
httpOnly : false
secure : false
samesite : None

발급된 쿠키는 24시간 동안 유효하며, 사용자가 이 기간 내에 쿠팡에서 무언가를 구매하면 브라우저는 결제 요청 시 이 쿠키를 함께 전송한다. 쿠팡 서버는 쿠키의 trac_lptag 값을 확인하고, 해당 파트너에게 수수료를 지급하는 것으로 추정된다. 만약 사용자가 다른 파트너의 링크를 클릭하면, 기존 쿠키는 새로운 파트너의 정보로 덮어쓰인다.

앱에서 열기를 클릭 할 경우

만약 리다이렉트 과정에서, “앱에서 열기” 버튼을 눌러 앱으로 이동하는 경우는 어떨까? 브라우저에 저장된 쿠키는 웹 환경에 종속적이므로, 네이티브 앱으로 그대로 전달되지 않는다.

이때 사용되는 기술이 딥링크(Deep Link)다. 딥링크는 웹 페이지의 링크를 통해 앱의 특정 페이지를 직접 열어주는 기술이다. iOS에서는 '유니버셜 링크(Universal Link)', Android에서는 '앱 링크(App Link)'라는 이름으로 구현된다.

앱에서 열기 딥링크 URL상품아이디를 포함시켜 해당 상품페이지를 바로 열리게 할 수 있다. 또한 딥링크 URL에 ?lptag=EXAMPLEID88와 같은 추천인 코드를 쿼리 파라미터로 포함시켜 앱에 전달하면, 앱은 이 파라미터를 파싱하여 추천인 코드를 내부 저장소에 보관하고, 추천인 식별에 활용할 수 있다.

누가 납치하는가?

만약 내가 뉴스사이트 에서 뉴스를 보다가 납치 광고에 의해 납치당했다면, 뉴스사이트 관리자가 삽입한 코드에 의해 납치당한 것일까? 꼭 그렇지 않다. 우리가 페이지에 접속하면 해당 페이지에 게시된 컨텐츠만 볼 수 있는 것이 아니다. <iframe> 태그는 현재 페이지 안에 다른 외부 페이지를 넣을 수 있게 한다. 이러한 <iframe> 태그의 특성 때문에 <iframe> 태그는 광고를 게시하는데 주로 사용되곤 한다. 만약 사이트 관리자가 자신의 웹사이트에 광고 수익을 얻기 위해 광고 플랫폼을 통해 광고를 게시한다면, 다음과 같은 참여자가 내가 보는 페이지에 관여하게 된다.

컨텐츠 제공자 : 사용자가 방문한 news.com 같은 사이트. 광고를 게시할 공간을 제공한다.
광고 플랫폼 : 매체사의 공간과 광고주의 광고를 연결하는 기술 중개자.
광고주 : 자신의 광고를 사용자에게 보여주고 싶어 하는 주체. (광고주를 찾지 못한 경우 등 광고플랫폼이 자신의 광고를 게시할 수 있음.)

사용자 브라우저가 보는 화면의 구조

┌──────────────────────────────────────────┐
│ 컨텐츠 제공자(news.com)                   │
│                                          │
│  ┌────────────────────────────────────┐  │
│  │ 광고 플랫폼의 iframe (ad-platform.com)│  │
│  │                                    │  │
│  │   ┌──────────────────────────────┐ │  │
│  │   │ 광고주의 iframe (ad.com)       │ │  │
│  │   │      (악성 스크립트 존재 가능)     │ │  │
│  │   └──────────────────────────────┘ │  │
│  │                                    │  │
│  └────────────────────────────────────┘  │
│                                          │

따라서, 컨텐츠 제공자와 광고 플랫폼의 검수과정이 미비한 경우 광고주에 의해 납치가 이루어질 수 있는 것이다.

그냥 납치하면 안될까? : 납치의 조건

납치광고가 이루어지는 페이지들을 살펴보면, 여러가지 교묘한 방식으로 클릭을 유도한다. 그렇다면 공격자들은 왜 교묘하게 클릭을 유도할까? 그냥 웹사이트에 방문하면 특정 시간이 지난 뒤 자동으로 광고 페이지를 열면 더 쉬울 텐데 말이다.

그 이유는 최신 브라우저의 강력한 팝업 차단 정책 때문이다.

"최신 브라우저는 엄격한 팝업 차단 정책을 가지고 있습니다. 팝업 창은 사용자 입력에 직접적으로 응답하여 열려야 하며, 각 window.open() 호출은 별도의 사용자 제스처 이벤트가 필요합니다."
-- MDN web docs

사용자가 직접 유도하지 않은 동작
- 페이지가 로드될 때
- 마우스를 움직일 때
- 스크롤할 때
- 일정 시간이 지났을 때
사용자가 직접 유도한 동작
- 사용자가 마우스로 버튼이나 링크를 클릭하는 행위
- 키보드를 누르는 행위

브라우저 차단조건 우회하기 : 사용자 제스쳐 유도하기

납치에는 크게 두가지 방법이 있다. 리다이렉트와 새 창 띄우기. 이중 리다이렉트는 부모페이지에 의해서만 가능하다. 따라서, <iframe> 태그 내부에서는 새 창 띄우기를 선택해야 납치할 수 있다. 새 창을 띄울 수 있는 방법으로는 <a href={url} target='_blank'>를 이용하거나 window.open(url)을 사용할 수 있다. 따라서, <iframe> 태그에 의해 삽입되는 광고는 사용자 제스쳐를 유도한 뒤 다음과 같은 코드로 새 창을 띄운다.

function coverOut(cp_land_url) {
    function adurl(cp_land_url) {
        let a = document.createElement('a');
        a.target = '_blank';
        a.href = cp_land_url;
        a.click();

    }

    $(".slide-motion").delay(1000).animate({left: "-150%"}, 1000);

    setTimeout(() => adurl(cp_land_url), 1000);
}


function newsxclick(cp_land_url) {
    window.open(cp_land_url);
}

광고예시

기사 이미지와 겹친 위치에 투명도를 조절하여 클릭을 유도한다

왼쪽으로 당기면 링크가 클릭되도록하여 스크롤시 클릭을 유도한다

납치 심화과정 : XSHM

더 악랄한 형태의 납치는 브라우저의 History API를 악용하여 사용자를 특정 페이지에 '감금'하는 것이다. 이 공격은 'XSHM (Cross-Site History Manipulation)'의 일종으로 볼 수 있다. 다만 이러한 공격은 <iframe> 태그 내부에서 실행될 경우 브라우저의 '동일 출처 정책(Same-Origin Policy)'에 의해 차단 당하므로, 사이트 관리자(부모 페이지)에 의해서만 가능하다.

공격의 흐름은 다음과 같다.

사용자가 기존 페이지(A)에서 악성 링크를 클릭한다.
브라우저는 광고 페이지(C)로 바로 이동하는 대신, 리다이렉트 전용 페이지(B)를 아주 잠깐 거친다. 이 페이지는 즉시 광고 페이지(C)로 사용자를 보낸다.
브라우저의 방문 기록(History)은 A -> B -> C 순으로 쌓인다.
사용자가 광고 페이지(C)에서 '뒤로 가기' 버튼을 누른다.
브라우저는 이전 페이지인 리다이렉트 페이지(B)로 이동한다.
하지만 페이지 B의 스크립트는 페이지가 로드되자마자 다시 광고 페이지(C)로 보내버린다.

광고 페이지에서 뒤로가기를 눌러도 리다이렉트 되기 때문에. 광고 페이지에서 빠져나오기 까다롭다. 이는 명백히 건강하고 안전한 웹을 해치는 행위이며 정보통신망법 등에 의해 처벌받을 수 있다.

납치 광고 해결 방법

그렇다면 프론트엔드 관점에서 이러한 납치 광고를 어떻게 대처할 수 있을까?

두가지 방안이 있다.

광고 차단 확장 프로그램 사용: AdGuard와 같은 광고 차단기는 알려진 광고 서버와 악성 스크립트를 원천적으로 차단하여 가장 효과적인 방어 수단이 된다.
보안 기능이 강화된 브라우저 사용: Brave 브라우저처럼 광고 및 트래커 차단 기능이 내장된 브라우저를 사용하는 것도 좋은 방법이다.

이러한 소프트웨어들은 브라우저가 웹 페이지를 렌더링하기 위해 필요한 리소스(HTML, CSS, JS, 이미지 등)를 서버에 요청할 때, 광고 차단기는 이 요청을 중간에서 가로채어, 광고 리스트에 등록된 주소라면 차단시킨다.

맺음말

웹의 발전은 광고의 발전과 함께 이루어졌다.광고는 콘텐츠 제공자에게 정당한 보상을 제공하고 콘텐츠 제작을 계속할 수 있게하는 중요한 수단이다. 하지만 일부 좋지 못한 사례로 건강한 생태계가 망가지 않았으면 한다. 이 글은 프론트엔드 기술의 관점에서 납치 광고의 원리를 분석했으며, 어떤 행위가 옳고 그른지는 최소한으로 서술하고자 하였다.

쿠팡 파트너스는 2025년 5월 30일 부정광고 제보 포상금 제도 실시한다고 안내하였다.

광고의 원리를 파악하면서, 맞춤형 광고가 어떤식으로 이루어지는지도 궁금해졌다.