혼합 콘텐츠 수정

Jo-el van Bergen
Jo-el van Bergen
X
Rachel Andrew

웹사이트에 대한 HTTPS 지원은 사이트와 사용자를 공격으로부터 보호하는 중요한 단계이지만 혼합 콘텐츠가 해당 보호를 쓸모없게 만들 수 있습니다. 혼합 콘텐츠란?에 설명된 대로 점점 더 안전하지 않은 혼합 콘텐츠가 브라우저에 의해 차단됩니다.

이 가이드에서는 기존 혼합 콘텐츠 문제를 해결하고 새로운 문제가 발생하지 않도록 하는 기술과 도구를 설명합니다.

사이트를 방문하여 혼합 콘텐츠 찾기

Google Chrome에서 HTTPS 페이지를 방문하면 브라우저가 JavaScript 콘솔의 오류 및 경고로서 혼합 콘텐츠가 있음을 경고합니다.

혼합 콘텐츠란 무엇인가요?에서 여러 예시를 확인하고 Chrome DevTools에서 문제가 어떻게 보고되는지 확인할 수 있습니다.

수동적 혼합 콘텐츠의 예시에는 다음과 같은 경고가 표시됩니다. 브라우저가 https URL에서 콘텐츠를 찾을 수 있으면 자동으로 업그레이드한 후 메시지를 표시합니다.

혼합 콘텐츠가 감지되고 업그레이드될 때 표시되는 경고를 보여주는 Chrome DevTools

활성 혼합 콘텐츠가 차단되고 경고가 표시됩니다.

활성 혼합 콘텐츠가 차단될 때 표시되는 경고를 보여주는 Chrome DevTools

사이트에서 http:// URL에 이러한 경고가 표시되면 사이트 소스에서 수정해야 합니다. 이런 오류와 경고를 찾은 페이지와 함께, 이들을 수정할 때 사용할 URL 목록을 만들면 도움이 됩니다.

사이트에서 혼합 콘텐츠 찾기

소스 코드에서 혼합 콘텐츠를 직접 검색할 수 있습니다. 소스에서 http://를 검색하고 HTTP URL 속성을 포함하는 태그를 찾습니다. 앵커 태그(<a>)의 href 속성에 http://가 있으면 혼합 콘텐츠 문제가 아닌 경우가 많습니다(몇몇 현저한 예외는 나중에 설명함).

사이트가 콘텐츠 관리 시스템을 사용하여 게시되는 경우 페이지가 게시될 때 안전하지 않은 URL로 연결되는 링크가 삽입될 수 있습니다. 예를 들어 이미지가 상대 경로가 아닌 전체 URL로 포함될 수 있습니다. CMS 콘텐츠 내에서 이러한 문제를 찾아 수정해야 합니다.

혼합 콘텐츠 수정

사이트 소스에서 혼합 콘텐츠를 발견한 후 다음 단계에 따라 문제를 해결할 수 있습니다.

리소스 요청이 HTTP에서 HTTPS로 자동 업그레이드되었다는 콘솔 메시지가 표시되면 코드에서 리소스의 http:// URL을 https://로 안전하게 변경할 수 있습니다. 브라우저 URL 표시줄에서 http://를 https://로 변경하고 브라우저 탭에서 URL을 열어 리소스를 안전하게 사용할 수 있는지 확인할 수도 있습니다.

https://를 통해 리소스를 사용할 수 없는 경우 다음 옵션 중 하나를 고려해야 합니다.

  • 가능한 경우 다른 호스트의 리소스를 포함합니다.
  • 권한이 있는 경우 사이트의 콘텐츠를 직접 다운로드하고 호스팅합니다.
  • 사이트에서 리소스를 완전히 제외합니다.

문제가 해결되면 오류를 처음에 발견한 페이지를 보고 오류가 더 이상 표시되지 않는지 확인합니다.

비표준 태그 사용 주의

사이트에서 비표준 태그 사용에 주의합니다. 예를 들어 앵커 (<a>) 태그 URL은 브라우저가 새 페이지로 이동하게 하므로 혼합 콘텐츠 오류가 발생하지 않습니다. 즉, 앵커 태그 URL은 수정할 필요가 없습니다. 그러나 일부 이미지 갤러리 스크립트는 <a> 태그의 기능을 재정의하고 href 속성이 지정한 HTTP 리소스를 페이지의 라이트박스 표시에 로드하여 혼합 콘텐츠 문제를 발생시킵니다.

혼합 콘텐츠를 대규모로 처리

위의 수동 단계는 작은 웹사이트에 잘 작동하지만 큰 웹사이트 또는 개별 개발팀이 많은 사이트의 경우 로드 중인 모든 콘텐츠를 추적하는 것이 어려울 수 있습니다. 이 작업을 지원하기 위해 콘텐츠 보안 정책을 사용하여 혼합 콘텐츠에 대해 알리도록 브라우저에 지시하고 페이지가 예기치 않게 보안되지 않은 리소스를 로드하지 않도록 할 수 있습니다.

콘텐츠 보안 정책

콘텐츠 보안 정책 (CSP)은 혼합 콘텐츠를 대규모로 관리하는 데 사용할 수 있는 다용도 브라우저 기능입니다. CSP 보고 메커니즘을 사용하여 사이트에서 혼합 콘텐츠를 추적하고 혼합 콘텐츠를 업그레이드하거나 차단하여 사용자를 보호하는 시정 조치 정책을 제공할 수 있습니다.

페이지에 대한 이러한 기능은 서버에서 전송한 응답에 Content-Security-Policy 또는 Content-Security-Policy-Report-Only 헤더를 포함하여 활성화할 수 있습니다. 또한 페이지의 <head> 섹션에서 <meta> 태그를 사용하여 Content-Security-Policy(Content-Security-Policy-Report-Only는 아님)를 설정할 수 있습니다.

콘텐츠 보안 정책을 사용하여 혼합 콘텐츠 찾기

콘텐츠 보안 정책을 사용하여 사이트에서 혼합 콘텐츠 보고서를 수집할 수 있습니다. 이 기능을 사용 설정하려면 Content-Security-Policy-Report-Only 지시문을 사이트에 대한 응답 헤더로 추가하여 설정합니다.

응답 헤더:

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/reportingEndpoint

사용자가 사이트의 페이지를 방문할 때마다 브라우저가 콘텐츠 보안 정책을 위반하는 사항에 관한 JSON 형식의 보고서를 https://example.com/reportingEndpoint로 전송합니다. 이 경우 HTTP를 통해 하위 리소스가 로드될 때마다 보고서가 전송됩니다. 해당 보고서에는 정책 위반이 발생한 페이지 URL과 정책을 위반한 하위 리소스 URL이 포함됩니다. 보고 엔드포인트를 구성하여 이러한 보고서를 로깅하면 각 페이지를 직접 방문하지 않고도 사이트에서 혼합 콘텐츠를 추적할 수 있습니다.

이와 관련하여 다음 두 가지를 주의해야 합니다.

  • 사용자는 CSP 헤더를 이해하는 브라우저에서 페이지를 방문해야 합니다. 대부분의 최신 브라우저는 CSP 헤더를 이해합니다.
  • 사용자가 방문한 페이지에 대한 보고서만 가져옵니다. 따라서 트래픽이 많지 않은 페이지의 경우 전체 사이트에 대한 보고서를 가져오는 데 약간 시간이 걸릴 수 있습니다.

콘텐츠 보안 정책 가이드에서 자세한 내용과 엔드포인트 예시를 확인하세요.

CSP를 통한 보고의 대안

Blogger와 같은 플랫폼에서 자동으로 사이트를 호스팅하는 경우 헤더를 수정하고 CSP를 추가할 수 있는 액세스 권한이 없을 수도 있습니다. 대신 웹사이트 크롤러를 사용하여 사이트 전반의 문제를 찾는 것이 유력한 대안이 될 수 있습니다(예: HTTPSChecker 또는 혼합 콘텐츠 검사).

안전하지 않은 요청 업그레이드

브라우저 지원

  • Chrome: 44.
  • Edge: 17.
  • Firefox: 48.
  • Safari: 10.1

소스

브라우저에서 안전하지 않은 요청을 업그레이드하고 차단하기 시작했습니다. CSP 디렉티브를 사용하여 이러한 애셋의 자동 업그레이드 또는 차단을 강제할 수 있습니다.

upgrade-insecure-requests CSP 지시문은 네트워크 요청을 하기 전에 보안되지 않은 URL을 업그레이드하라고 브라우저에 지시합니다.

예를 들어 페이지에 <img src="http://example.com/image.jpg">과 같은 HTTP URL이 있는 이미지 태그가 포함된 경우

브라우저가 https://example.com/image.jpg에 대한 보안 요청을 대신 수행하므로 사용자를 혼합 콘텐츠로부터 보호합니다.

이 지시문과 함께 Content-Security-Policy 헤더를 전송하여 이 동작을 사용 설정할 수 있습니다.

Content-Security-Policy: upgrade-insecure-requests

또는 <meta> 요소를 사용하여 문서의 <head> 섹션에 동일한 지시문 인라인을 포함하여 동일한 효과를 낼 수 있습니다.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

브라우저 자동 업그레이드와 마찬가지로 HTTPS를 통해 리소스를 사용할 수 없는 경우 업그레이드된 요청이 실패하고 리소스가 로드되지 않습니다. 이렇게 하면 페이지의 보안이 유지됩니다. upgrade-insecure-requests 디렉티브는 자동 브라우저 업그레이드보다 더 나아가 브라우저에서 현재 업그레이드하지 않는 요청을 업그레이드하려고 시도합니다.

upgrade-insecure-requests 지시문은 <iframe> 문서에 계단식으로 배열되며 전체 페이지를 보호합니다.