"의도하고 누른 버튼이 사실은 그 아래 숨겨진 페이지의 버튼이었다" — 그것이 클릭재킹입니다. 작동 원리와 확실히 막는 방법을 살펴봅니다(공격 절차는 다루지 않습니다).
무엇이 표적이 되는가
"한 번 누르면 끝나고, 가치 있는" 모든 것입니다.
| 가능성 높은 표적 | 이유 |
|---|---|
| 송금/구매 확인 | 한 번의 클릭으로 돈이 움직임 |
| 설정 변경(공개 범위, 연동 앱) | 이후의 장악이나 데이터 접근을 위한 발판 |
| OAuth / 권한 "허용" | 계정 연동을 조용히 승인 |
| 소셜 팔로우 / 좋아요 / 게시 | 확산과 좋아요 농사에 악용 |
왜 통하는가
브라우저는 다른 사이트를 iframe으로 불러와 위에 쌓을 수 있습니다. 공격자는 그 iframe을 투명하게(opacity 0) 만들어, 사용자는 그 아래 배치된 미끼 UI만 보게 됩니다. 사용자가 "가짜 버튼"을 누르면, 바로 위에 겹쳐진 진짜 버튼이 그 클릭을 받습니다.
CSRF와 비슷해 보이지만, CSRF는 뒤에서 요청을 보내는 반면 클릭재킹은 사용자가 진짜 화면을 직접 조작하게 합니다 — 그래서 CSRF 토큰만으로는 막히지 않습니다.
방어: 진짜 해결책은 "프레임에 끼일 수 없게"
CSP frame-ancestors 설정(가장 중요)
Content-Security-Policy: frame-ancestors 'self'를 추가하세요(내 오리진만 프레임 가능). 아무도 임베드할 필요가 없다면 'none'이 가장 안전합니다. 명시적으로 허용하는 파트너에 한해서만 도메인을 나열하세요.
X-Frame-Options도 추가(하위 호환)
구형 클라이언트를 위해 X-Frame-Options: DENY(또는 SAMEORIGIN)도 함께 보내세요. 구·신 브라우저 모두를 덮는 이중 안전장치입니다.
중요한 행동에는 한 단계 더 요구
송금과 권한 부여는 재인증, 확인 대화상자, 또는 의도 확인으로 막으세요 — 조용한 오버레이로 끝까지 몰아붙이기 어려워집니다.
세션 쿠키를 SameSite로
SameSite=Lax/Strict는 크로스 사이트 자동 전송을 줄입니다. 그 자체로 클릭재킹의 완전한 해결책은 아니지만, "다른 사이트에서 시작된 행동"이라는 더 넓은 범주를 약화시킵니다.
본 사이트의 견해: 한 줄의 헤더가 가장 큰 일을 한다 — 먼저 내 사이트부터 점검하라
클릭재킹 방어는 화려한 코드가 아니라 오버레이가 필요로 하는 토대를 없애는 한두 줄의 응답 헤더입니다. 프레임워크나 리버스 프록시(Caddy/nginx) 단에서 사이트 전체에 적용해 빠지는 곳이 없게 하세요. frame-ancestors가 실제로 살아 있는지는 본 사이트의 도구에 있는 보안 헤더 검사기로 확인할 수 있습니다. "설정했다고 생각했는데" — 빠진 헤더 — 가 가장 흔한 실패입니다.
다음으로 읽기
FAQ
Q클릭재킹으로 무엇이 가능한가요?
사용자가 '의도하고' 누른 클릭이 그 아래에 겹쳐진 진짜 페이지의 버튼에 떨어집니다. 한 번의 클릭으로 끝나는 중요한 행동들이 악용됩니다: 송금, 설정 변경, 권한 부여, 소셜 팔로우/좋아요, 동의 버튼. 비밀번호를 훔치는 것이 아니라 — 이미 로그인된 사용자가 그 행동을 직접 하게 만듭니다.
Q최우선 방어책은 무엇인가요?
다른 사이트의 프레임에 끼이는 것을 거부하는 것입니다. 응답 헤더에서 CSP frame-ancestors 지시어를 'self'(또는 허용한 도메인만)로 설정하고, 하위 호환을 위해 X-Frame-Options: DENY를 추가하세요. 그러면 오버레이가 필요로 하는 표면 자체가 사라집니다.
QJavaScript 프레임 버스팅으로 충분한가요?
아니요. '내가 iframe 안이면 빠져나간다'는 옛날 스크립트는 우회 방법이 많고 JS가 비활성화되면 무용지물입니다. 진짜 해결책은 브라우저에 임베드를 거부하도록 지시하는 서버 헤더(frame-ancestors / X-Frame-Options)입니다.