Defaults.Exposed › 수정 › 클릭재킹 방지 (X-Frame-Options)

클릭재킹 방지 (X-Frame-Options) 수정 방법

다른 웹사이트가 귀사 사이트를 자신의 사이트 안에 몰래 로드하지 못하게 하는 한 줄의 지시입니다. 이 설정이 없으면 사기꾼이 귀사의 실제 로그인 또는 결제 페이지를 가짜 페이지 뒤에 숨겨 로그인한 고객을 속여 의도하지 않은 행동을 — 결제 승인, 비밀번호 변경, 접근 권한 부여 — 하게 만들 수 있습니다.

비즈니스에 미치는 핵심 영향: 사기꾼이 가짜 사이트 안에 귀사 실제 사이트를 투명하게 삽입하고 로그인한 고객의 돈이나 계정 접근을 탈취할 수 있습니다. 고객에게는 귀사 사이트가 한 것처럼 보입니다. 수정은 무료이며 개발자에게 약 15분이 걸립니다. 켜지 않으면 범죄자와 신중한 구매자 모두 즉시 발견할 수 있는 알려진 격차입니다.

발생 가능한 비용

• 사기꾼이 귀사 실제 로그인이나 결제 화면을 무해해 보이는 페이지 뒤에 숨기고 고객을 속여 의도하지 않게 이체를 '확인'하거나 설정을 변경하게 만듭니다.
• 귀사 로그인 계정 영역이 '당첨 — 클릭해서 수령' 페이지 위에 보이지 않게 로드됩니다. 올바른 위치를 클릭하면 고객의 실제 계정에서 실제 변경이 승인됩니다.
• 잠재 고객의 IT 팀이 서명 전 빠른 보안 스캔을 실행하여 귀사 사이트가 누구나 임베드할 수 있다는 것을 발견하고 위험으로 표시합니다.
• 귀사 브랜드가 사기 캠페인의 미끼가 됩니다. 피해를 입은 고객은 '귀사 사이트가 그것을 가능하게 한 회사'로 기억합니다.
• 감사자 또는 사이버 보험 스캔이 없는 클릭재킹 방지를 기본 위생 실패로 나열합니다.

중요한 이유. 이것은 몇 분 만에 추가할 수 있는 무료 한 줄 설정이며, 로그인한 고객을 대상으로 하는 전체 속임수 분류를 차단합니다. 방어 헤더를 범죄자가 자동화하고 구매자가 찾기 때문에 잃어버린 알려지고 쉽게 확인 가능한 구멍을 남기는 빠른 수정으로, 높은 심각도로 평가되는 가치 있는 점수 웹 보안 검사입니다.

쉬운 설명

누군가 웹사이트를 방문하면 브라우저가 귀사 사이트를 다른 웹사이트 안에 로드하도록 지시받을 수 있습니다. 이것이 클릭재킹이라는 공격의 메커니즘입니다.

트릭: 사기꾼이 자체 페이지를 만들고 귀사 실제 웹사이트를 그 안에 조용히 로드합니다 — 완전히 투명하게 만들어. 그런 다음 자체 콘텐츠를 위에 얹습니다: 화려한 버튼, “동영상 재생”, “경품 수령”. 고객은 공격자의 페이지를 보고 무해한 버튼처럼 보이는 것을 클릭합니다. 하지만 귀사 실제 사이트가 커서 아래에 투명하게 앉아 있으므로 클릭이 귀사 페이지에 실제로 착지합니다 — 결제 확인, 비밀번호 변경, 접근 승인.

클릭재킹 방지는 귀사 웹사이트가 모든 방문자의 브라우저에 보내는 짧고 보이지 않는 지시입니다:

“다른 웹사이트가 나를 그 안에 로드하게 하지 마세요. 누군가 시도하면 거부하세요.”

비즈니스 피해 사례

1. 보이지 않는 “확인”. 고객이 한 탭에서 귀사 계정 포털에 로그인되어 있습니다. 그들이 “계속” 버튼이 있는 페이지에 도달합니다. 그 버튼 아래에 귀사 실제 “이체 확인” 또는 “이메일 변경” 컨트롤이 숨겨져 있습니다. 그들이 “계속”을 클릭하면 귀사와의 실제 계정에서 변경을 의도치 않게 승인합니다.

2. 설정 탈취. 공격자가 귀사 계정 설정 페이지를 프레임하고 무해한 게임이나 설문조사를 위에 얹습니다. 몇 번의 클릭으로 설정이 조용히 전환됩니다.

3. 지연된 거래. 더 큰 고객사가 서명 전 표준 보안 설문지를 보냅니다. 귀사 사이트가 안티 프레이밍 보호를 설정하는지 한 줄이 묻습니다. IT 담당자가 “아니오”라고 답해야 합니다.

4. 브랜드-미끼 캠페인. 귀사 실제 신뢰받는 페이지가 임베드될 수 있으므로 공격자가 광범위한 피싱 캠페인에서 귀사 로그인이나 결제 페이지를 사용합니다.

5. 감사 표시. 보험사 스캔 또는 귀사 보안 상태를 검토하는 감사자가 없는 클릭재킹 방지를 발견합니다.

실제 작동 방식

브라우저가 페이지를 요청하면 서버가 페이지와 함께 보이지 않는 “헤더”를 보냅니다. 클릭재킹 방지는 이 헤더를 통해 전달됩니다. 두 가지가 있으며 둘 중 하나가 있으면 검사를 통과합니다:

1. 구형 헤더 — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

두 가지 실용적 값:

• SAMEORIGIN — 귀사 자체 사이트가 자체 페이지를 임베드할 수 있지만 외부 사이트는 불가능.
• DENY — 귀사를 포함해 아무도 임베드 불가.

2. 현대 헤더 — CSP frame-ancestors:

Content-Security-Policy: frame-ancestors 'self';

더 유연한 제어:

• frame-ancestors 'self' — SAMEORIGIN에 해당.
• frame-ancestors 'none' — DENY에 해당.
• frame-ancestors 'self' https://partner.example.com — 귀사와 하나의 특정 신뢰할 수 있는 파트너.

좋은 상태는

가장 강력한 설정은 둘 다 사용합니다. 검사는 둘 중 하나로 충족되지만 둘 다 무료이며 같은 몇 분이 걸리므로 둘 다 설정하지 않을 이유가 없습니다.

수정 방법 (무료, 약 15분)

웹사이트를 담당하는 사람에게 이 섹션을 전달하세요 — 수정은 무료입니다.

1단계 — 얼마나 엄격하게 할지 결정

• 대부분의 비즈니스: SAMEORIGIN / frame-ancestors 'self'. 귀사 사이트가 계속 작동하며 외부는 차단.
• 사이트가 자체 페이지를 임베드하지 않는 경우: 최대 잠금을 위해 DENY / frame-ancestors 'none'.
• 파트너가 특정 페이지를 임베드해야 하는 경우: frame-ancestors 'self' https://partner.example.com;으로 명시.

2단계 — 헤더 추가(플랫폼 선택)

Nginx:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

Microsoft IIS:

<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Content-Security-Policy" value="frame-ancestors 'self';" />

Cloudflare: 규칙 → Transform 규칙 → 응답 헤더 수정 → X-Frame-Options를 SAMEORIGIN으로, Content-Security-Policy를 frame-ancestors 'self';로 설정.

3단계 — 재로드 및 확인

웹 서버를 재로드하거나 CDN 규칙을 배포한 후 라이브 사이트를 로드하고 응답 헤더를 확인합니다.

흔한 실수

• 보고만 CSP를 사용하고 보호된다고 가정. Content-Security-Policy-Report-Only는 위반만 보고합니다. 시행을 위해서는 시행 헤더가 필요합니다.
• 별도의 Content-Security-Policy 헤더 두 개 설정. 이미 CSP가 있다면 frame-ancestors를 추가하세요 — 두 번째 정책을 발행하지 마세요.
• 귀사 사이트가 자체 페이지를 임베드할 때 DENY 설정. 귀사 사이트의 일부가 iframe을 사용한다면 SAMEORIGIN을 사용하세요.
• 홈페이지만 보호. 클릭재킹에 가장 중요한 페이지는 로그인된 페이지들입니다. 헤더가 사이트 전체에 적용되는지 확인하세요.
• HTTPS나 자물쇠가 이미 커버한다고 가정. 암호화와 안티 프레이밍은 관련이 없습니다.

FAQ