1. 소개
이 절은 규범적인 내용이 아닙니다.
사용자가 보안 채널(예: HTTPS)을 통해 example.com에서 웹페이지를 성공적으로 로드할 때, 사용자 에이전트와 example.com
사이의 데이터가 중간에 있는 어떤 엔티티도 엿보거나 변조하지 않았다는 보장이 제공됩니다. 그러나 웹페이지가 스크립트나 이미지를 보안되지 않은 연결로 로드하면 이 보장은 약화됩니다. 예를
들어, 보안되지 않게 로드된 스크립트는 공격자가 사용자를 대신하여 데이터를 읽거나 수정할 수 있게 합니다. 보안되지 않게 로드된 이미지는 공격자가 사용자에게 잘못된 정보를 전달(예:
조작된 주식 차트), 클라이언트 사이드 상태 변경(예: 쿠키 설정), 또는 사용자가 의도하지 않은 행동을 하도록 유도(예: 버튼의 레이블 변경)할 수 있습니다. 이러한 요청을 혼합
콘텐츠라고 합니다.
이 명세서는 사용자 에이전트가 특정 유형의 혼합 콘텐츠를 차단하고, 일부 맥락에서 더 엄격하게 동작함으로써 이러한 위험을 완화하는 방법을 자세히 설명합니다.
그러나 이 명세서의 이전 버전들은 사용자의 데이터의 기밀성과 무결성을 완전히 보호하지 못했습니다. 이미지, 오디오, 비디오 등과 같이 보안되지 않은 콘텐츠는 현재도 보안 컨텍스트에서 기본적으로 로드될 수 있습니다. 심지어 보안 페이지가 사용자 에이전트의 샌드박스를 완전히 벗어나는 보안되지 않은 다운로드를 시작할 수도 있습니다.
또한 사용자는 혼합 콘텐츠가 로드될 때 명확한 보안 표시를 받지 못합니다. 웹페이지가 혼합 콘텐츠를 로드할 때 브라우저는 "중간" 수준의 보안 표시(예: 자물쇠 아이콘 제거 등)를 보여 주는데, 이는 사용자가 해당 페이지를 신뢰해야 하는지 명확하게 알려주지 않습니다. 이 UX는 개발자가 혼합 콘텐츠를 피하도록 충분한 동기가 되지 못했으며, 여전히 많은 웹페이지가 혼합 콘텐츠를 로드하고 있습니다. 모든 혼합 콘텐츠를 차단하는 것이 사용자에게 더 간단한 사고 모델(즉, 웹페이지가 보안 전송으로 로드되었는지 여부만 확인하면 됨)을 제공하고, 개발자가 필수 혼합 콘텐츠를 안전하게 로드하도록 유도할 수 있습니다.
그래서 이 명세서는 사용자에게 더 나은 보안 및 개인정보 보호 보장, 더 나은 보안 UX를 제공하면서도 파손을 최소화하도록 업데이트되었습니다. 브라우저가 모든 혼합 콘텐츠를 엄격하게 차단하도록 단순히 권고하는 대신, 이 명세서는 혼합 콘텐츠 자동 업그레이드를 권고합니다:
-
사용자 에이전트가 이미 차단하고 있지 않은 혼합 콘텐츠는 보안 전송으로 자동 업그레이드되어야 합니다.
-
요청을 자동 업그레이드할 수 없는 경우 해당 요청은 차단됩니다.
자동 업그레이드는 보안 웹페이지에서 보안되지 않은 리소스 로드를 방지하면서, 개발자가 파손을 방지하기 위해 추가로 해야 할 작업을 최소화합니다.
이 명세서는 현재 기본적으로 차단되지 않은 혼합 콘텐츠 하위 리소스 유형만 자동 업그레이드를 권장하며, 이미 차단되고 있는 콘텐츠 유형은 자동 업그레이드를 권장하지 않습니다. 이는 웹에서 가시적인 변화를 최소화하기 위한 것으로, 기본적으로 모든 혼합 콘텐츠를 차단하는 목표를 진전시킬 수 있을 때만 업그레이드하도록 합니다.
이 명세서는 또한 혼합 다운로드라는 개념을 명확히 도입합니다. 혼합 다운로드란, 보안 컨텍스트에서 시작되었지만 보안되지 않은 연결로 다운로드되는 리소스를 사용자 에이전트가 다운로드로 처리하는 경우를 뜻합니다. 사용자 에이전트는 혼합 다운로드를 차단해야 하며, 이는 실행 파일의 경우 사용자 에이전트의 샌드박스를 벗어나거나, 민감한 정보(예: 은행 명세서)를 포함할 수 있기 때문입니다. 특히 사용자 에이전트가 보안 페이지에 있다는 표시를 하면서 혼합 다운로드를 시작 및 완료하는 것이 매우 오해를 불러일으킬 수 있습니다.
2. 핵심 개념 및 용어
- 혼합 콘텐츠
-
request의 URL이 잠재적으로 신뢰할 수 있는 URL이 아니고,
해당 리소스를 로드하는 컨텍스트가 혼합 보안 컨텍스트를 금지하면 혼합 콘텐츠입니다(후자의 규범적 정의는 § 4.3 settings가 혼합 보안 컨텍스트를 금지하는가? 참조).
response가 인증되지 않은 응답이고, 해당 리소스를 로드하는 컨텍스트가 혼합 보안 컨텍스트를 금지하면 혼합 콘텐츠입니다.
참고: "혼합 콘텐츠"는 원래 섹션 5.3에서 [WSC-UI]에 정의되었습니다. 이 문서는 해당 초기 정의를 업데이트합니다.
참고: [XML]에도 관련 없는 "혼합 콘텐츠" 개념이 정의되어 있습니다. 용어가 보안 맥락에서 사용자 에이전트에 10년 넘게 널리 쓰이고 있기 때문에 혼동 위험은 실질적으로 낮습니다.
- 인증되지 않은 응답
- a posteriori 관점에서, response(response)의 URL이 잠재적으로 신뢰할 수 있는 URL이 아니라면 인증되지 않은 응답입니다.
- 임베딩 문서
-
DocumentA가 주어졌을 때, A의 브라우징 컨텍스트의 컨테이너 문서가 임베딩 문서입니다 [HTML]. - 혼합 다운로드
- 혼합 다운로드란, 보안 컨텍스트에서 시작되었지만 보안되지 않은 연결로 다운로드되는 리소스를 사용자 에이전트가 다운로드로 처리하는 경우를 의미합니다.
a priori 인증된 URL은 잠재적으로 신뢰할 수 있는 URL과 동일합니다 [SECURE-CONTEXTS].
3. 콘텐츠 범주
이상적인 세상에서는 모든 사용자 에이전트가 예외 없이 모든 혼합 콘텐츠를 차단해야 합니다. 그러나 오늘날 인터넷에서는 현실적으로 어렵기 때문에, 사용자 에이전트는 많은 웹사이트에서 경험 저하를 피하기 위해 더 세밀한 제한이 필요합니다.
이 점을 염두에 두고, 혼합 콘텐츠를 § 3.1 업그레이드 가능한 콘텐츠와 § 3.2 차단 가능한 콘텐츠로 나눕니다.
3.1. 업그레이드 가능한 콘텐츠
업그레이드 가능한 콘텐츠는 이전 명세서 버전에서는 옵션 차단 가능으로 불리기도 했습니다.
혼합 콘텐츠는 해당 리소스 유형의 혼합 사용 빈도가 충분히 높고, 리소스 자체가 위험도가 낮을 경우 업그레이드 가능으로 분류됩니다. 이 범주에 속한다고 해서 안전하다는 의미는 아니며, 단지 다른 리소스 유형보다 치명적으로 위험하지 않다는 뜻입니다. 예를 들어 이미지와 아이콘은 애플리케이션 UI의 핵심 요소인 경우가 많으므로, 공격자가 "이메일 삭제"와 "답장" 아이콘을 뒤바꾼다면 사용자에게 실질적인 피해가 발생할 수 있습니다.
이 범주에는 다음이 포함됩니다:
-
initiator가 빈 문자열이고, destination이 "
image"인 요청.참고: 이는 대부분의
img이미지(스크립트 실행 또는 하위 리소스 가져오기가 차단된 SVG 이미지 포함) 및 CSS(background-image, border-image 등)에 해당합니다.img요소 중 srcset 또는 picture를 사용하는 경우는 포함되지 않습니다. -
destination이 "
video"인 요청. -
destination이 "
audio"인 요청.
이 범주는 § 4.4 요청을 혼합 콘텐츠로 차단해야 하는가?에서
CORS가 활성화된 모든 요청을 강제로 실패시키는 방식으로 더 제한됩니다. 예를 들어 <img crossorigin ...>로 로드된 혼합 콘텐츠
이미지는 차단됩니다. 이처럼 이 범주는 오직 너무 널리 사용되어 전체 차단이 어려운 콘텐츠 유형에만 해당하며, 워킹 그룹은 시간이 지나며 더 많은 차단 가능한 하위
집합을 만들고자 합니다.
3.2. 차단 가능한 콘텐츠
위에서 정의한 업그레이드 가능에 해당하지 않는 모든 혼합 콘텐츠는 차단 가능으로 간주됩니다. 대표적인 예로
스크립트, 플러그인 데이터, XMLHttpRequest로
요청된 데이터 등이 있습니다.
참고: 네비게이션 요청은 최상위 브라우징 컨텍스트를 대상으로 할 수 있으며, 이는 혼합 콘텐츠로 간주되지 않습니다. 자세한 내용은 § 4.4 요청을 혼합 콘텐츠로 차단해야 하는가?를 참조하세요.
참고: 플러그인을 대신해 이루어진 요청도 차단 가능입니다. 단, 사용자 에이전트가 항상 이러한 요청을 중재할 수 있는 것은 아닙니다. 예를 들어 NPAPI 플러그인은 직접 네트워크 접근이 가능하며, 일반적으로 사용자 에이전트를 완전히 우회할 수 있습니다. 사용자 에이전트는 가능한 경우 이러한 요청을 차단하는 것이 좋으며, 플러그인 벤더도 본 문서에서 설명한 위험을 줄이기 위해 혼합 콘텐츠 체크를 구현하는 것이 좋습니다.
4. 알고리즘
4.1. 혼합 콘텐츠 request를 적절할 경우 신뢰할 수 있는 URL로 업그레이드하기
참고: Fetch 명세는 이 알고리즘에 연결되어 업그레이드 가능한 혼합 콘텐츠를 HTTPS로 업그레이드합니다.
Request request가 주어졌을 때, 업그레이드 가능한 혼합 콘텐츠로 간주되면 다음 알고리즘에 따라 URL을 재작성합니다:
-
다음 조건 중 하나라도 충족하면 request를 수정하지 않고 반환합니다:
- request의 URL이 신뢰할 수 있는 URL이다.
- request의 URL의 host가 IP 주소이다.
- § 4.3 settings가 혼합 보안 컨텍스트를 금지하는가?를
request의 client에 적용했을 때
"
혼합 보안 컨텍스트를 금지하지 않음"을 반환한다. - request의 destination이 "
image", "audio", "video"가 아니다. -
request의 destination이 "
image"이고 request의 initiator가 "imageset"이다.참고: 역사적 이유로 "
imageset"은 업그레이드되지 않습니다. 과거에는 혼합 콘텐츠를 차단 가능/옵션 차단 가능으로 나누었으며, "imageset"은 차단 가능에 포함되어 업그레이드 정책에서도 제외되었습니다.
-
request의 URL의 scheme이
http라면, request의 URL의 scheme을https로 설정하고 반환합니다.참고: [url]에 따라 포트는 수정하지 않습니다. scheme이
http일 때 포트는 null로 설정되고, scheme이https로 변경되면 443으로 해석됩니다.
4.2. 이전 알고리즘 수정
참고: 이 절은 이전 명세의 알고리즘을 수정하는 내용을 포함합니다. 옵션 차단 가능/차단 가능 혼합 콘텐츠의 구분을 무시하며, 모든 옵션 차단 가능 혼합 콘텐츠가 이제 자동 업그레이드됩니다.
4.3. settings가 혼합 보안 컨텍스트를 금지하는가?
문서와 워커 모두 환경 설정 객체를 가지며, 혼합 콘텐츠 제한 여부를 다음 알고리즘에 따라 판단할 수
있습니다. 이 알고리즘은 상황에 따라 "혼합 보안 컨텍스트를 금지함" 또는 "혼합 보안 컨텍스트를 금지하지 않음"을
반환합니다.
환경 설정 객체 (settings)가 주어졌을 때:
-
settings의 origin이 신뢰할 수 있는 origin이라면, "
혼합 보안 컨텍스트를 금지함"을 반환합니다. -
settings의 global object가
window라면:-
document를 settings의 global object의 연관된 Document로 설정합니다.
-
각 navigable navigable에 대해 document의 상위 navigables를 순회합니다:
-
navigable의 active document의 origin이 신뢰할 수 있는 origin이라면, "
혼합 보안 컨텍스트를 금지함"을 반환합니다.
-
-
-
"
혼합 보안 컨텍스트를 금지하지 않음"을 반환합니다.
4.4. request의 fetch는 혼합 콘텐츠로 차단해야 하는가?
참고: Fetch 명세는 이 알고리즘에 연결되어 요청이 완전히 차단되어야 하는지(예: 차단 가능 콘텐츠 요청으로, 보안 연결로 로드되지 않을 것이라 가정되는 경우) 판단합니다.
Request request가 주어졌을 때, 사용자 에이전트는 다음 알고리즘에 따라 Request request가 진행되어야 하는지 결정합니다:
-
다음 조건 중 하나라도 충족하면 허용을 반환합니다:
- § 4.3 settings가 혼합 보안 컨텍스트를 금지하는가?를
request의 client에 적용했을 때
"
혼합 보안 컨텍스트를 금지하지 않음"을 반환한다. - request의 URL이 신뢰할 수 있는 URL이다.
- 사용자 에이전트가 혼합 콘텐츠 허용하도록 지시받은 경우(§ 7.2 사용자 제어 참조).
-
request의 destination이
"
document"이고, request의 target browsing context에 상위 브라우징 컨텍스트가 없다.참고: 최상위 네비게이션은 혼합 콘텐츠 검사에서 제외되지만, 사용자 에이전트는 비보안 폼 제출에 대해 혼합 콘텐츠 검사를 강제할 수 있습니다(§ 7.1 폼 제출 참조).
- § 4.3 settings가 혼합 보안 컨텍스트를 금지하는가?를
request의 client에 적용했을 때
"
- 차단을 반환합니다.
4.5. request에 대한 response는 혼합 콘텐츠로 차단해야 하는가?
참고: 요청이 진행된 경우에도, 응답을 생성한 연결 상태(예: 차단 가능인데 인증되지 않은 응답인 경우 등)에 따라 응답을 차단할 수 있습니다. 또한 Service Worker가 차단 가능 요청에 대해 인증되지 않은 응답을 반환하지 않도록 해야 합니다. 이 알고리즘은 그 판단에 사용됩니다.
request request와 response response가 주어졌을 때, 사용자 에이전트는 다음 알고리즘에 따라 어떤 응답을 반환할지 결정합니다:
-
다음 조건 중 하나라도 충족하면 허용을 반환합니다:
- § 4.3 settings가 혼합 보안 컨텍스트를 금지하는가?를
request의 client에 적용했을 때
혼합 보안 콘텐츠를 금지하지 않음을 반환한다. - response의 url이 신뢰할 수 있는 URL이다.
- 사용자 에이전트가 혼합 콘텐츠 허용하도록 지시받은 경우(§ 7.2 사용자 제어 참조).
-
request의 destination이
"
document"이고, request의 target browsing context에 상위 브라우징 컨텍스트가 없다.참고: 최상위 네비게이션은 혼합 콘텐츠 검사에서 제외되지만, 사용자 에이전트는 비보안 폼 제출에 대해 혼합 콘텐츠 검사를 강제할 수 있습니다(§ 7.1 폼 제출 참조).
- § 4.3 settings가 혼합 보안 컨텍스트를 금지하는가?를
request의 client에 적용했을 때
- 차단을 반환합니다.
5. 통합
5.1. Fetch 수정
Fetch § 4.1 Main fetch는 request에 대해 3단계와 4단계 사이에 § 4.1 혼합 콘텐츠 요청을 적절할 경우 신뢰할 수 있는 URL로 업그레이드하기를 호출하도록 수정해야 합니다. 즉, 업그레이드 가능한 혼합 콘텐츠는 혼합 콘텐츠 차단을 적용하기 전에 HTTPS로 자동 업그레이드되어야 합니다.
5.2. HTML 수정
navigate 응답 처리는 아래와 같이 수정되어야 합니다. 3단계에서 source의 active document의 URL이 신뢰할 수 있는 URL이고, response의 URL 목록 내에 신뢰할 수 있는 URL이 아닌 URL이 하나라도 있으면 다운로드를 중단하고 반환해야 합니다.
유사한 변경이 하이퍼링크 다운로드에도 적용되어야 합니다. 이 알고리즘에서 6.2단계는 subject의 node document의 URL이 신뢰할 수 있는 URL이고, response의 URL 목록 내에 신뢰할 수 있는 URL이 아닌 URL이 하나라도 있으면 반환(다운로드 중단)하도록 수정되어야 합니다(response는 request를 fetch한 결과임).
참고: 다운로드는 다른 혼합 콘텐츠 유형처럼 자동 업그레이드되지 않는데, 사용자 에이전트가 리소스를 요청하기 전에 그것이 다운로드될 것임을 항상 알 수 없기 때문입니다.
참고: 리소스는 사용자 에이전트가 비보안 연결을 근거로 다운로드를 중단할지 결정하기 전에 다운로드됩니다. 이로 인해 민감한 정보가 네트워크를 통해 전송될 수 있습니다. 이런 경우는 일반적으로 피할 수 없으며, 사용자 에이전트가 리소스가 다운로드된다는 사실을 최종 응답을 받을 때까지 알지 못할 수 있기 때문입니다. 하지만 리소스를 차단함으로써 사용자 에이전트는 웹사이트 운영자가 다운로드를 보안 연결로 제공하도록 유도할 수 있습니다.
6. 폐지 사항
6.1. 엄격한 혼합 콘텐츠 검사
이 명세서의 이전 버전에서는 block-all-mixed-content CSP 지시자를 정의했으나, 이제는 사용되지 않습니다. 왜냐하면 자동 업그레이드가 불가능한
모든 혼합 콘텐츠가 차단되기 때문입니다.
참고: upgrade-insecure-requests ([upgrade-insecure-requests]) 지시자는 개발자가 차단 가능한 콘텐츠를 업그레이드할 수
있도록 하므로 폐지되지 않았습니다. 이 명세서는 기본적으로 업그레이드 가능한 콘텐츠만 업그레이드합니다.
7. 보안 및 개인정보 보호 고려사항
전반적으로 업그레이드 가능한 혼합 콘텐츠 자동 업그레이드는 더 많은 사용자 트래픽을 네트워크 도청 및 변조로부터 보호하여 보안 및 개인정보 측면에서 긍정적인 효과를 기대할 수 있습니다.
개발자가 의도하지 않은 리소스를 로드함으로써 웹페이지에 보안이나 개인정보 문제가 새로 생길 위험이 있습니다. 예를 들어, 웹사이트가
http://www.example.com/image.jpg에서 평범한 이미지를 포함하는데,
https://www.example.com/image.jpg가 추적 사이트로 리디렉션되는 경우입니다. 브라우저는 개발자와 사용자의 명시적 동의 없이 개인정보 문제를
유발할 수 있습니다. 하지만 이런 사례는 매우 드물 것으로 예상되며, 업그레이드 가능한 콘텐츠만 자동 업그레이드하고 차단 가능한 콘텐츠는 업그레이드하지 않음으로써 위험을 완화합니다. 차단
가능한 콘텐츠(예: 구식이거나 취약한 JavaScript 라이브러리)는 더 큰 위험을 초래할 수 있습니다.
7.1. 폼 제출
§ 4.3 settings가 혼합 보안 컨텍스트를 금지하는가?를 Document의
relevant settings object에 적용했을 때
혼합 콘텐츠를 제한함을 반환하면, 사용자 에이전트는 하나 이상의
form
요소에 action 속성 값이 신뢰할 수 있는 URL이 아닌 경우 사용자에게 경고할 수 있습니다.
사용자 에이전트는
form
요소의 action 속성 값이 신뢰할 수 있는 URL이 아닌 경우 제출 시 경고하고 제출을 중단할 수 있도록 사용자에게
허용할 수 있습니다. 만약 사용자 에이전트가
form
요소가 신뢰할 수 없는 URL로 제출될 때 경고한다면, 제출 시
form
요소의 action이 리디렉션되어 신뢰할 수 없는 URL로 노출될 때에도 경고하고 제출을 중단할 수 있도록 해야 합니다.
또한 사용자 에이전트는 이런 Document에서의
폼 제출을 차단 가능한 요청으로 처리할 수 있으며, 제출이 최상위 브라우징 컨텍스트에서 발생하더라도 마찬가지입니다.
7.2. 사용자 제어
사용자 에이전트는 개별 페이지에서 차단 가능한 혼합 콘텐츠 차단 결정을 사용자가 재정의할 수 있도록 허용할 수 있습니다.참고: 실질적으로 사용자 에이전트는 이런 백도어를 제공하지 않을 수는 없습니다. 하지만 혼합 스크립트 허용은 특히 매우 위험한 선택이므로, 각 사용자 에이전트는 이런 선택을 제공할 때 반드시 위험성을 충분히 고려하고 안내해야 합니다(REALLY SHOULD NOT [RFC6919]).
사용자 에이전트는 개별 페이지에서 업그레이드 가능한 혼합 콘텐츠의 자동 업그레이드 결정을 사용자가 재정의할 수 있도록 허용할 수 있습니다.
사용자 에이전트가 제공하는 모든 제어는 보조 기술 사용자들을 위한 접근성 API를 통해서도 제공되어야 합니다.
8. 감사의 글
WebAppSec WG에서 받은 훌륭한 피드백 외에도 Chrome 보안팀은 이 명세서를 준비하는 데 큰 도움을 주었습니다. 특히 Chris Palmer, Chris Evans, Ryan Sleevi, Michal Zalewski, Ken Buchanan, Tom Sepez가 많은 초기 피드백을 주었습니다. Anne van Kesteren은 Fetch를 설명하고, 이 명세서 인터페이스를 정의하는 데 도움을 주었으며, Level 2 업데이트에 귀중한 피드백을 제공했습니다. Brian Smith는 명세서가 핵심에 집중하고 간결하며 일관성 있게 유지되도록 도왔습니다.