클릭재킹이란 무엇인가?
클릭재킹은 공격자가 웹페이지 요소를 위장하거나 기존 페이지 위에 보이지 않게 배치하여 사용자를 다른 곳으로 리디렉션하거나 다른 요소를 클릭하도록 유도하는 공격입니다. 사용자가 클릭하거나 속아서 다른 요소를 클릭하게 되면 악성 웹사이트를 방문하거나, 자격 증명을 넘기거나, 민감한 정보를 유출할 수 있습니다. 심지어 가짜 사기성 웹사이트에서 제품을 구매하게 될 수도 있습니다.
클릭재킹 공격은 일반적으로 사용자가 이미 보고 있는 기존 페이지 위에 보이지 않는 페이지나 HTML 요소(주로 iframe 내부)를 표시하는 방식으로 이루어집니다. 사용자는 실제로 보이는 페이지를 클릭한다고 생각하지만, 실제로는 추가 페이지에 연결된 보이지 않는 버튼이나 요소를 클릭하게 됩니다.
조금 혼란스러울 수 있지만, 이 가이드에서는 클릭재킹 공격이 무엇이며 어떻게 작동하는지 자세히 설명합니다. 클릭재킹을 예방하는 방법과 이러한 사례에 대응할 수 있는 방법을 알 수 있습니다.
.jpg)
2026년에 클릭재킹 예방이 중요한 이유는?
클릭재킹은 무해한 상호작용을 위험한 행위로 바꿔 심각한 결과를 초래할 수 있기 때문에 중요합니다. 페이지에 오버레이가 적용된 사실조차 인지하지 못합니다. 육안으로는 보이지 않으며, 페이지의 인터페이스를 재구성해 사용자의 행동을 오도할 수 있습니다. 이미 인증된 소셜 계정으로 악성 사이트에 접속하면 공격자가 민감한 자격 증명과 기타 정보를 탈취할 수 있습니다.
클릭재킹은 단 한 번의 숨겨진 클릭으로 계정 설정이 변경되거나, 동의 없이 다른 콘텐츠를 구독하거나 페이지를 팔로우하게 만들 수 있기 때문에 중요합니다. 해커가 클릭재킹을 통해 사용자의 자격 증명을 획득하면 계정을 탈취해 사용자가 모르는 사이에 악의적인 활동을 수행할 수 있습니다.
클릭재킹은 조직에 대한 고객의 신뢰를 저하시킬 뿐만 아니라 지원 비용을 증가시키고, 이러한 공격을 방지하는 것을 더욱 어렵게 만듭니다. 다양한 서비스에 걸쳐 공격이 확산되고 규모가 커질수록 그 영향은 커집니다. 가장 큰 문제는 사용자가 웹사이트의 오버레이와 이러한 기만적인 오버레이를 구분할 수 없다는 점입니다. 왜냐하면 이들은 숨겨져 있기 때문입니다.
클릭재킹 공격은 어떻게 작동하는가?
클릭재킹 공격의 일반적인 예는 사용자가 팝업을 닫는다고 생각하며 클릭하는 보이지 않는 “구매” 또는 “좋아요” 버튼입니다. 또 다른 전형적인 시나리오는 사용 중인 비디오 게임 인터페이스 하단에 숨겨진 “활성화” 또는 “사용” 버튼을 배치하는 것입니다.
클릭재킹은 피싱이 아닙니다. 피싱은 사용자를 설득하거나 행동을 유도하는 데 초점을 둡니다. 하지만 클릭재킹 공격에서는 클릭이 어디에 도달하는지 오도되어 속임을 당합니다. 클릭재킹은 자연스럽게 느껴지며, 공격이 명확하게 드러나지 않아 사용자가 의심하지 않고 행동하게 만듭니다.
위장된 클릭은 구매, OTP 확인, 이체 등을 사용자의 확인이나 인증 없이 진행할 수 있습니다. 클릭재킹 공격은 UI 요소를 이용해 허가를 부여하도록 만들 수 있으며, 이는 허위 전제로 클릭될 수 있습니다. 또한 카메라, 마이크, 위치 설정을 켜서 기만적인 오버레이를 통해 개인정보를 노출시킬 수 있습니다.
그렇다면 클릭재킹 공격이 브라우저 버그의 일종인가요? 그렇지 않지만, 사이트의 표준 기능(레이어링, iframe 등)을 악용할 수 있습니다.
싱글 사인온 인증이 이를 방지할 수 있나요? 아닙니다. 클릭재킹 공격은 UI를 조작할 수 있으며, SSO는 신원 관리만 담당하기 때문입니다.
모바일 앱과 하이브리드 앱 모두 외부 콘텐츠를 표시하는 경우 클릭재킹 공격의 영향을 받을 수 있습니다.
클릭재킹 취약점은 어떻게 탐지하는가?
클릭재킹 취약점을 탐지하는 가장 좋은 방법 중 하나는 다른 서버에서 웹페이지를 프레이밍해보는 것입니다.
- 로컬 환경을 열고 간단한 HTML 파일을 만듭니다. 이를 Proof of Concept(개념 증명, PoC) HTML 파일이라고 가정합니다. 이제 HTML 본문에 <iframe> 태그를 사용합니다. 테스트하려는 민감한 페이지의 URL을
<iframe>태그에 삽입합니다. - 테스트하려는 대상 URL로 교체합니다. 저장 후 브라우저에서 페이지를 확인합니다. iframe 태그에 입력한 대상 페이지의 콘텐츠가 정상적으로 로드된다면, 사이트는 취약할 가능성이 높습니다. 로드되지 않는다면 안전합니다.
- 이것이 수동 테스트라고 부르는 클릭재킹 취약점 탐지의 첫 번째 방법입니다.
또 다른 방법은 방어 우회 여부를 테스트하는 것입니다. 웹 브라우저에서 JavaScript가 비활성화된 경우 간단한 프레임 차단 스크립트를 사용할 수 있습니다. 클릭재킹 공격 예방 및 테스트를 위해 더블 프레이밍과 같은 고급 기법도 사용할 수 있습니다.
자동화된 취약점 스캐너는 잘못 구성된 안티-클릭재킹 HTTP 헤더를 검사할 수 있으며, 일부는 네트워크 탭에서 HTTP 응답 헤더를 확인할 수 있습니다. X-Frame-Options, Content-Security-Policy와 같은 헤더가 누락된 페이지는 취약할 수 있습니다.
타겟 페이지에서 클릭을 기록하고 공격 UI 오버레이와 함께 재생해 실제 공격 시나리오를 모방하는 도구도 있습니다. 이를 통해 다양한 클릭재킹 취약점을 찾을 수 있습니다.
클릭재킹 공격을 예방하는 방법은?
클릭재킹 공격을 예방할 수 있는 방법은 다음과 같습니다.
Permissions Policy로 브라우저 기능 제어
최신 브라우저는 임베디드 iframe이 접근할 수 있는 기능을 제한할 수 있습니다. Permissions-Policy 헤더를 설정해 전체화면, 위치정보, 카메라, 마이크, 결제 요청 API를 비활성화하세요. 이를 통해 공격자가 오버레이를 통해 민감한 브라우저 기능을 탈취하는 것을 차단할 수 있습니다. 설령 클릭을 유도하더라도 명시적 허용 없이는 위험한 권한을 실행할 수 없습니다. 공격자가 오버레이로 실제로 할 수 있는 행위를 제한하는 효과적인 방어 계층입니다.
임베디드 콘텐츠에 iframe Sandbox 제한 적용
외부 콘텐츠를 iframe에 임베드할 때, sandbox 속성으로 기본적으로 격리할 수 있습니다. 스크립트, 폼, 팝업은 꼭 필요하지 않다면 차단하세요. allow 값은 신중하게 사용하고, allow-scripts는 iframe이 실제로 JavaScript가 필요할 때만 부여하며, allow-same-origin은 꼭 필요할 때만 사용하세요. 이러한 격리 전략은 악성 임베디드 콘텐츠가 메인 페이지나 사용자 데이터에 접근하는 것을 방지합니다. 샌드박스 구성을 정기적으로 테스트해 의도대로 동작하는지 확인하세요.
이벤트 리스너로 사용자 클릭 행동 모니터링
JavaScript 이벤트 리스너를 추가해 클릭이 실제로 어디에서 발생하는지 추적하세요. 클릭이 합법적인 UI 요소에서 발생했는지, 보이는 버튼과 일치하지 않는 위치에서 발생했는지 확인합니다. event.target과 event.currentTarget을 비교해 불일치를 탐지할 수 있습니다. 이는 보이는 요소를 클릭한 것처럼 보이지만 실제로는 아래에 숨겨진 레이어를 클릭한 경우를 탐지하는 데 도움이 됩니다. 완전히 차단할 수는 없지만, 일반적인 오버레이 트릭을 탐지하고 보안팀을 위한 감사 기록을 생성할 수 있습니다.
머신러닝 및 AI 탐지 활용
고급 ML 모델은 페이지 레이아웃과 사용자 상호작용을 분석해 클릭재킹 패턴을 인식할 수 있습니다. 이러한 시스템은 의심스러운 iframe 오버레이, 비정상적인 요소 배치, 행동 이상 징후를 실시간으로 탐지합니다. 피싱 데이터셋으로 학습된 CNN 및 신경망 모델은 사용자가 피해를 입기 전에 위협을 식별할 수 있습니다. 기술이 발전함에 따라 기존 방어를 우회하는 정교한 공격도 탐지할 수 있습니다. HTTP 헤더와 함께 자동화된 위협 탐지를 배포해 더 깊은 보호를 구현하세요.
브라우저 핑거프린팅으로 의심스러운 활동 식별
방문자의 브라우저, 디바이스, 하드웨어 특성을 기반으로 고유한 디지털 핑거프린트를 생성하세요. 기존 사용자 데이터베이스와 비교해 새로운 디바이스나 위치에서 클릭이 발생하면 추가 인증을 요구하세요. 핑거프린팅은 공격자가 신원을 숨기기 위해 사용하는 에뮬레이터, VPN, 스푸핑 도구를 탐지할 수 있습니다. 행동 분석과 결합하면 실제 사용자와 클릭재킹 공격을 시도하는 봇, 사기꾼을 구분할 수 있습니다.
웹사이트 진위 표시를 사용자에게 제공
페이지가 진짜이며 변조되지 않았음을 증명하는 시각적 워터마크나 출처 배지를 표시하세요. 사용자가 이러한 표시가 사라지거나 변경되는 것을 보면 스푸핑 페이지나 오버레이 공격임을 인지할 수 있습니다. 방어용 UI 코드는 페이지가 프레임에 로드될 때 자동으로 경고를 표시할 수 있습니다. 사용자는 이러한 시각적 신호에 익숙해져 숨겨진 요소를 클릭하도록 속는 것을 방지할 수 있습니다.
클릭재킹 예방을 위한 모범 사례
클릭재킹 예방을 위해 따라야 할 모범 사례는 다음과 같습니다.
1. X-Frame-Options HTTP 헤더 설정
첫 번째 방어선은 서버에서 X-Frame-Options 헤더를 설정하는 것입니다. 이 헤더는 브라우저에 페이지가 iframe 또는 frame 내에서 로드될 수 있는지 여부를 알립니다. 주요 옵션은 다음과 같습니다.
- 'DENY'는 가장 안전한 선택으로, 모든 도메인에서 콘텐츠 프레이밍을 차단합니다.
- 'SAMEORIGIN'은 동일 도메인에서만 페이지 프레이밍을 허용하며, 내부 프레이밍이 필요한 경우에 적합합니다.
- 'ALLOW-FROM uri'는 특정 신뢰 도메인을 화이트리스트로 지정할 수 있지만, 브라우저 호환성 문제로 주의해서 사용해야 합니다.
2. frame-ancestors가 포함된 Content Security Policy 구현
CSP는 클릭재킹을 방지하는 현대적인 방법으로, X-Frame-Options보다 더 유연합니다. Content Security Policy 헤더에 frame-ancestors 지시어를 추가해 어떤 도메인이 콘텐츠를 프레이밍할 수 있는지 지정하세요. 프레이밍이 전혀 필요 없다면 'none'으로 설정하거나, CSP 문법을 사용해 신뢰 도메인만 지정하세요.
3. SameSite 속성으로 세션 쿠키 보호
모든 세션 쿠키에 SameSite 속성을 'Strict' 또는 'Lax'로 설정하세요. 이는 다른 도메인에서 iframe으로 페이지가 로드될 때 쿠키가 전송되는 것을 방지합니다.
다른 방어와 결합하면, 인증된 사용자 세션이 프레이밍 공격을 통해 탈취되는 것을 차단할 수 있습니다. 'Strict'로 설정하면 보호가 강력해지지만, 'Lax'는 합법적인 크로스사이트 이동에 대해 보안과 사용자 경험의 균형을 제공합니다.
4. 프레임 차단 JavaScript 코드 추가
HTML 문서의 <head> 섹션에 JavaScript 프레임 차단 코드를 포함하세요. 이 스크립트는 페이지가 프레임 내에서 로드되는지 확인하고, 감지되면 자동으로 프레임에서 벗어납니다. 대부분의 최신 브라우저에서 동작하는 간단한 백업 계층입니다. 프레임 차단 코드가 견고한지 반드시 확인하고, 공격자가 더블 프레이밍 등 고급 기법으로 쉽게 우회할 수 있는 구식 방법은 피하세요.
5. 중요한 작업에 window.confirm() 사용
iframe 내에서 민감한 거래나 계정 변경을 허용하기 전에 window.confirm() 메서드를 사용해 명시적 확인을 강제하세요. 이 대화상자는 사용자가 수행하려는 작업을 적극적으로 인지하도록 요구합니다. 다른 보호가 우회되더라도, 이 절차는 마찰을 추가해 공격자가 노리는 실수 클릭을 방지할 수 있습니다.
6. 취약점 정기 테스트
로컬에서 iframe 태그로 사이트 URL을 지정한 간단한 HTML 파일을 만드세요. 브라우저에서 로드해 페이지가 프레임 내에 표시되는지 확인합니다. 정상적으로 로드된다면 취약하므로 위의 헤더를 적용해야 합니다. 로드되지 않으면 보호가 잘 동작하는 것입니다. 자동화된 취약점 스캐너를 사용해 HTTP 응답 헤더에서 X-Frame-Options 및 CSP 헤더 누락 여부를 점검하세요. 수동 테스트와 자동화를 결합하면 포괄적인 커버리지를 확보할 수 있습니다.
7. 오구성 모니터링
브라우저의 네트워크 탭에서 HTTP 응답 헤더를 직접 검사할 수 있는 도구를 사용하세요. 모든 페이지에서 X-Frame-Options 및 Content-Security-Policy 헤더를 확인합니다. 이러한 헤더가 누락된 페이지는 잠재적 공격 대상입니다. 일부 자동화 스캐너는 방어 우회 테스트와 구현상의 취약점도 탐지할 수 있습니다.
8. 이중 확인 단계 도입
사용자가 명시적이고 매우 민감한 작업(예: 송금, 계정 삭제)을 수행하기 전에 반드시 이중 확인을 하도록 하세요. 클라이언트 측 스크립트에만 의존하지 마십시오.
9. 사용자 교육
직원에게 클릭재킹 공격과 그 작동 원리에 대해 교육하세요. 의심스러운 오버레이, 이상한 팝업, 갑작스러운 권한 요청에 대해 인지하도록 하세요. 클릭재킹 예방을 위한 모든 구현 조치는 OWASP 클릭재킹 치트시트와 비교해 사이트가 실제로 보호되고 있는지 확인하세요.
결론
클릭재킹은 최근 점점 더 흔해지고 있지만, 이제 브라우저 및 클라이언트 측에서 어떤 위협을 마주할 수 있는지 알게 되었습니다. 서버 기반 프로토콜은 브라우저의 iframe 사용을 제한하고 클릭재킹 공격을 방어할 수 있습니다.
클릭재킹 공격의 효과는 브라우저 측 동작에도 달려 있습니다. 웹 표준과 안전한 브라우징 사용 수칙을 준수한다면, 사용자와 조직 모두 안전할 가능성이 높습니다. 항상 경계하고, 브라우저 준수 여부를 점검하며, X-Frame-Options와 Content Security Policy를 적극적으로 활용해 충분한 보호를 확보하세요!
자주 묻는 질문
클릭재킹은 공격자가 사용자를 속여 의도하지 않은 클릭을 유도하는 공격입니다. 악성 웹사이트는 정상 콘텐츠 위에 보이지 않는 버튼이나 링크를 오버레이합니다. 사용자가 일반 버튼을 클릭한다고 생각할 때 실제로는 그 뒤에 숨겨진 무언가를 활성화하게 됩니다. 이후의 동작은 공격자가 제어합니다. 클릭으로 인해 계정 설정 변경, 콘텐츠 게시, 권한 승인 등 원치 않는 동작이 발생할 수 있습니다. 사용자는 이러한 일이 발생한 사실조차 인지하지 못할 수 있습니다.
X-Frame-Options 헤더가 누락되면 클릭재킹이 작동하는 주요 원인입니다. 웹사이트에서 이 헤더를 설정하지 않으면 공격자가 iframe에 삽입할 수 있습니다. Content Security Policy 헤더를 사용하지 않으면 취약해질 수 있습니다. 일부 사이트는 사용자 행동을 제대로 검증하지 않아 방문자를 속이기 쉽게 만듭니다. 프레이밍 방지 기술을 구현하지 않은 웹사이트는 공격 대상이 됩니다. 내장 보호 기능이 없는 구형 프레임워크는 특히 위험합니다. 민감한 작업을 처리하는 애플리케이션은 적절한 방어가 필요하며, 그렇지 않으면 클릭재킹 공격에 노출될 수 있습니다.
개발자는 X-Frame-Options 헤더를 DENY 또는 SAMEORIGIN으로 설정해야 합니다. 이는 브라우저가 사이트를 iframe 내에서 로드하는 것을 방지합니다. 또한 frame-ancestors 지시어가 포함된 Content Security Policy를 사용하여 프레이밍을 제어할 수 있습니다. 모든 중요한 사용자 동작, 특히 결제나 권한 변경과 같은 민감한 작업을 점검하십시오. 사용자가 실제 버튼과 상호작용하고 있음을 알 수 있도록 시각적 표시를 추가하십시오. 프레이밍 취약점을 찾기 위해 사이트를 정기적으로 테스트하십시오. 구형 브라우저가 포함된 경우 백업 보호로 JavaScript 프레임 차단 코드를 사용하십시오.
X-Frame-Options는 브라우저에 사이트가 프레임 내에 표시될 수 있는지 여부를 알려주는 HTTP 헤더입니다. DENY로 설정하면 사이트는 어떤 iframe에서도 절대 로드되지 않습니다. SAMEORIGIN은 동일 도메인에서만 프레이밍을 허용합니다. ALLOW-FROM은 신뢰할 수 있는 도메인을 지정하여 해당 도메인에서만 프레이밍을 허용할 수 있습니다. 브라우저는 이 헤더를 준수하며 다른 사이트의 프레이밍 시도를 차단합니다. 공격자는 사용자의 허가 없이 콘텐츠를 오버레이할 수 없습니다. 이 간단한 헤더는 공격자가 클릭재킹에 사용하는 주요 도구를 제거하여 공격을 불가능하게 만듭니다.
온라인 도구나 브라우저 개발자 도구를 사용하여 응답 헤더를 확인할 수 있습니다. 사이트의 HTTP 응답에서 X-Frame-Options 헤더를 찾아보십시오. 이 헤더가 없다면 취약할 수 있습니다. 사이트를 iframe으로 불러오는 테스트 HTML 파일을 만들어서 실제로 로드되는지 확인해 보십시오. iframe 내부에 사이트가 나타난다면 클릭재킹이 가능합니다. 수동 테스트도 도움이 되지만, 자동화된 보안 스캐너를 사용하면 더 빠르게 문제를 찾을 수 있습니다. 메인 도메인과 서브도메인 모두를 테스트하십시오. 변경 후에는 실제로 수정이 적용되었는지 반드시 테스트하여 확인해야 합니다.
먼저, 모든 응답에 X-Frame-Options 헤더를 추가하십시오. 프레이밍이 필요하지 않다면 DENY로 설정하십시오. 추가 보호를 위해 Content Security Policy 헤더를 사용하십시오. 사용자가 비정상적인 동작이나 예상치 못한 프롬프트를 인지할 수 있도록 교육하십시오. 방문자의 클릭이 항상 의도적인 것이라고 가정하지 마십시오. 중요한 작업에는 CSRF 토큰을 구현하십시오. 취약점이 패치되므로 프레임워크와 라이브러리를 최신 상태로 유지하십시오. 잘못된 구성 문제를 발견하기 위해 정기적으로 보안 감사를 수행하십시오. 방어 체계가 실제로 작동하는지 확인할 수 있도록 자주 테스트하십시오.
