폐기된 CDN 도메인이 재등록되면 왜 위험할까?

과거에 사용하던 CDN 서비스가 종료된 후 해당 도메인이 타인에게 재등록되면, 웹사이트에 하드코딩된 외부 자산 참조 경로를 통해 공격자가 악성 자바스크립트를 배포하는 웹 공급망 공격(Web Supply Chain Attack)의 경로가 될 수 있습니다. 운영자가 눈치채지 못한 상태에서 사용자 브라우저에 임의의 코드가 실행될 수 있는 셈이라 심각한 보안 취약점으로 이어집니다.

폐기된 CDN 도메인 재등록의 메커니즘과 위험성

웹 서비스를 운영하면서 외부 CDN(Content Delivery Network)에서 정적 자산을 불러오는 구성은 흔합니다. 그런데 서비스 제공업체의 사정으로 CDN 도메인이 폐기되고 이를 제삼자가 다시 등록하면 제어권이 완전히 타인의 손에 넘어갑니다.

실제 사례를 보면, 폐기되었던 특정 CDN 도메인이 2025년 7월에 누군가 재등록한 사실이 확인되었습니다. 문제는 도메인이 폐기된 뒤에도 수천 개의 웹사이트와 코드 저장소가 여전히 이 도메인을 호출하고 있었다는 점입니다.

재등록된 도메인의 새 소유자가 와일드카드 DNS를 설정해 두면 위험은 한층 커집니다. 와일드카드 DNS가 걸려 있으면 도메인 아래 어떤 호스트네임으로 요청이 들어와도 모두 새 소유자의 인프라로 연결됩니다. 현재 이 사례의 최상위 도메인에는 광고가 많은 미디어 다운로더 페이지가 올라와 있습니다.

웹 공급망 공격(Web Supply Chain Attack)으로 이어지는 경로

도메인 소유권이 바뀐 상태에서 웹사이트가 여전히 해당 도메인의 자산을 호출하고 있다면 전형적인 웹 공급망 공격의 기회가 됩니다. 공격자가 악의적인 의도를 가지고 있다면 기존에 웹사이트가 호출하던 정상적인 스크립트나 자원 대신 악성 자바스크립트를 배포할 수 있기 때문입니다.

이런 공격은 단 하나의 CDN 도메인 재등록만으로 해당 도메인을 참조하던 수천 개의 사이트가 동시에 공격 대상이 될 수 있다는 점에서 영향 범위가 넓습니다.

외부 자산 참조 점검 및 대응 전략

운영 중인 서비스가 폐기된 CDN 도메인을 참조하고 있는지 확인하고, 이를 안전하게 관리할 기술적 대응 방안이 필요합니다.

1. 실행 중인 코드 데이터 수집 (CSP-Report-Only)

현재 사이트에서 어떤 외부 자산이 호출되고 있는지 파악하려면 Content-Security-Policy-Report-Only 헤더를 쓰면 됩니다. 이 헤더는 실제 자원을 차단하거나 사이트 동작을 바꾸지 않으면서 정책에 위배되는 항목만 보고서로 수집해 줍니다.

효율적으로 점검하려면 다음 순서대로 진행합니다.

  • HTTP 응답 헤더에 Content-Security-Policy-Report-Only를 추가합니다.
  • 약 48시간 동안 수집되는 데이터를 분석해 현재 실행 중인 외부 코드 목록을 확인합니다.

2. 기술적 방어 기제 적용

점검만으로는 부족합니다. 외부 자산의 변조를 원천적으로 차단하는 방법은 다음 두 가지입니다.

  • 서브리소스 무결성(SRI, Subresource Integrity) 적용: 외부 자원을 불러올 때 SRI 속성을 설정하면 브라우저가 다운로드한 파일의 해시값을 계산해 원본 파일과 일치하는지 확인합니다. 도메인 재등록 등으로 파일이 변조되었다면 브라우저가 자동으로 차단합니다.
  • 자체 호스팅(Self-hosting) 원칙: 서드파티 정적 자산은 가급적 자체 서버에 호스팅해 외부 도메인 의존성을 없애는 것이 가장 안전한 기본 원칙입니다.

대응 방안 요약 비교

대응 방안 작동 방식 주요 효과 비고
CSP-Report-Only 정책 위반 항목 보고서 수집 실행 중인 외부 코드 목록 파악 서비스 영향 없음
SRI (Subresource Integrity) 파일 해시값 비교 및 검증 변조된 자원 실행 차단 속성 설정 필요
자체 호스팅 (Self-hosting) 내부 인프라에 자산 저장 외부 도메인 의존성 제거 최선의 보안 원칙

거버넌스 차원의 서드파티 의존성 관리 방안

폐기된 도메인으로 인한 보안 사고를 막으려면 조직 차원의 관리 체계가 필요합니다.

첫째, 외부 의존성 점검 주기를 정하는 일입니다. 앞서 언급한 Content-Security-Policy-Report-Only 헤더로 데이터를 정기적으로 수집해서 불필요하거나 출처가 불분명한 외부 호출이 생기는지 지켜봅니다.

둘째, 외부 자산 도입 시 SRI 적용을 표준 개발 가이드라인에 포함시켜 개발 단계부터 보안 무결성을 확보하는 프로세스를 정착시키는 일입니다.

댓글 남기기