웹 위협 모델

1. 우리는 무엇을 만들고 있는가?

웹 플랫폼은 웹을 가능하게 하는 개방형 로열티 프리 기술들의 모음이다. 사용자는 웹 브라우저나 사용자를 대신해 동작하는 다른 에이전트 같은 사용자 에이전트를 통해 웹사이트와 상호작용한다.

웹사이트는 일련의 파일 형식을 포함한다. 글꼴, 이미지, 멀티미디어 같은 수동 콘텐츠와 HTML, JavaScript, WebAssembly 같은 능동 콘텐츠가 서버에서 사용자의 기기로 전송되고 웹 브라우저에 의해 해석된다. 수동 콘텐츠는 디코딩되고 렌더링되며, 능동 콘텐츠는 그 출처의 권한으로 실행되고 웹의 주요 공격 표면을 구성한다. 이 구분은 유용하지만 절대적이지는 않다. 예를 들어 삽입된 CSS도 선택자 매칭과 리소스 로드를 사용해 페이지 상태를 추론하거나 유출할 때 공격 표면이 될 수 있다 [xsleaks-css-injection].

따라서 웹사이트는 능동 실행 환경이다. 웹 서버의 응답은 실행 가능한 스크립트, 사용자 인터페이스 정의, 서드파티 리소스에 대한 참조, 그리고 사용자 에이전트가 사용자 입력을 읽고, 인터페이스를 갱신하고, Web API를 호출하고, 로컬 상태를 저장하거나 가져오고, 기반 플랫폼과 상호작용하고, 원격 서비스와 통신하도록 하는 명령을 포함할 수 있다. 그래서 웹 브라우저는 이 맥락에서 중요한 행위자이다. 웹 브라우저는 신뢰할 수 없고 네트워크를 통해 접근한 웹사이트의 코드를 사용자의 기기에서 실행한다.

이러한 복잡성 때문에 이 문서는 웹에 대한 하나의 완전한 위협 모델을 정의하려고 시도하지 않는다. 웹은 계층화되고 진화하는 생태계이므로, 단일 모델은 개발과 검토 작업을 안내하기에는 너무 추상적이거나, 읽기 쉽고 유용한 상태를 유지하기에는 너무 상세할 것이다. 이는 Shostack의 위협 모델링 작업에서의 실용적 틀을 따른다. 모델은 무엇을 만들고 있는지와 무엇이 잘못될 수 있는지를 추론하기 위해 사용되는 추상화이며, 서로 다른 충실도 수준에서 다른 모델들이 유용할 수 있다 [shostack-threat-modeling]. 따라서 이 문서는 관련 위협 모델들의 모음으로 동작한다.

1.1. 고수준 웹 위협 모델

고수준 웹 위협 모델은 이 문서에서 가장 추상적인 모델이다. 이 모델은 사용자 에이전트를 단일 프로세스로 취급하고, 매우 높은 수준에서 추론하기 위한 주요 요소, 흐름, 경계만 설명한다.

1.1.1. 요소 사전

1.1.2. 신뢰 경계

1.1.3. 웹 브라우저 위협 모델과의 관계

고수준 위협 모델은 의도적으로 대부분의 브라우저 내부 구조를 시야 밖에 둔다. 이는 검토 대상이 웹 플랫폼 전체일 때 유용하다. 즉 출처의 역할, 주요 행위자, 그리고 사용자, 웹 콘텐츠, 네트워크, 브라우저 관리 상태 및 기반 플랫폼 사이의 신뢰 경계를 이해하는 데 유용하다.

설계나 검토가 결정이 어디에서 강제되는지, 어떤 브라우저 구성요소가 상태를 유지하는지, 권한이 어떻게 중개되는지, 신뢰할 수 없는 콘텐츠가 어떻게 격리되는지, 또는 Web API가 운영 체제가 노출한 기능에 어떻게 도달하는지에 의존할 때는 그 수준만으로 충분하지 않다. 그런 경우 브라우저를 열어 보아야 한다. 아래의 웹 브라우저 위협 모델은 그 목적을 위해 P0을 확장한다.

1.2. 웹 브라우저 위협 모델

웹 브라우저 위협 모델은 현대 웹 브라우저에서 반복적으로 나타나는 아키텍처 역할을 개략적으로 설명한다.

최소주의 웹 위협 모델에서처럼 브라우저를 단일 구성요소로 취급하는 대신, 이 추상화는 현대 브라우저가 서로 다른 권한, 상태에 대한 서로 다른 접근 권한, 신뢰할 수 없는 입력에 대한 서로 다른 노출을 가진 여러 프로세스에 책임을 분산하는 방식을 포착한다. 또한 출처 및 사이트 기반 격리 전략을 포함해 브라우저가 웹 보안 모델을 강제하는 방식과, 외부 웹 서버의 입력을 처리할 때 자신을 보호하는 방식을 포착한다 [threat-modeling-guide].

이 두 관심사는 관련되어 있지만 동일하지는 않다. 콘텐츠 프로세스는 웹 콘텐츠가 신뢰할 수 없기 때문만이 아니라, 브라우저가 동일 출처 격리와 브라우저와 OS/플랫폼 사이의 분리를 보존해야 하기 때문에도 격리된다. 실제로 구현이 두 목적을 모두 지원하기 위해 같은 프로세스 아키텍처를 사용하더라도, 이들은 구별되는 신뢰 경계이다.

각 웹 브라우저마다 구현 세부사항은 다르다. 그럼에도 공통 구조가 나타난다.

1.2.1. 권한 있는 브라우저 프로세스

현대 브라우저에는 브라우저 UI, 탐색 제어, 프로세스 관리, 정책 강제, 권한 중개 및 민감한 로컬 리소스에 대한 접근 중개를 담당하는 높은 권한의 제어 구성요소가 포함된다. Chromium은 이를 Browser process라고 부른다. WebKit은 UI process라고 부른다. Firefox는 Parent process라고 부른다 [chromium-multiprocess-architecture] [webkit2-architecture-overview] [firefox-process-model].

이 구성요소는 로컬 브라우저 아키텍처에서 주요 신뢰 앵커로 취급해야 한다. 브라우저 관리 정책이 흔히 강제되고 사용자에게 보이는 중개가 일반적으로 발생하는 곳이다. 위협 모델링 목적에서 이는 중요하다. 결정의 보안 영향은 부분적으로 그 결정이 어디에서 이루어지는지에 달려 있기 때문이다. 권한 있는 브라우저 구성요소에서 수행되는 검사는 샌드박스화된 콘텐츠 프로세스에서 수행되는 검사와 동등하지 않다.

웹 브라우저 위협 모델 다이어그램에서 이 다이어그램은 이 프로세스를 "Browser / UI / Parent Process"라고 지칭한다.

1.2.2. 샌드박스화된 웹 콘텐츠 실행 및 렌더링

웹 콘텐츠는 Chromium의 Renderer processes, WebKit의 WebContent processes, Firefox의 Content processes 같은 프로세스 안에서 실행되며, 각각은 신뢰할 수 없는 입력을 관리하는 데 구별되는 역할을 가진다 [chromium-multiprocess-architecture] [webkit2-architecture-overview] [firefox-process-model].

이러한 유형의 프로세스는 신뢰할 수 없는 웹 콘텐츠에 노출된다. 그 이유로 이들은 신뢰할 수 없는 입력을 파싱하고, 해석하고, 계산할 것으로 예상되는 실행 환경으로 모델링된다. 이들의 가치는 침해가 불가능하다고 가정하는 데 있는 것이 아니라, 침해가 발생했을 때 뒤따르는 결과를 제한하는 데 있다. 따라서 권한 있는 웹 브라우저 중개와 웹 콘텐츠 실행 사이의 분리는 웹 브라우저 모델의 중심 신뢰 경계 중 하나이다. 구현은 서로 관련 없는 웹 콘텐츠가 정상 사용 중이나 침해 이후에 서로 간섭할 수 없도록 출처 또는 사이트 기반 격리 전략을 사용할 수도 있지만, 정확한 격리 단위는 브라우저별로 다르다 [chromium-process-model-site-isolation] [webkit-site-isolation-notes] [firefox-process-model].

웹 브라우저 위협 모델 다이어그램에서 이 다이어그램은 이 프로세스를 "Content / Renderer / WebContent Process"라고 지칭한다.

1.2.3. 네트워크와 저장소

현대 웹 브라우저는 네트워킹과 영구 상태 관리도 분리하거나 적어도 중개한다. Chromium에서 이 역할은 Network Service, 프로필별 NetworkContext 객체 및 StoragePartition과 관련된다. WebKit에서는 Networking process가 네트워크 접근, 디스크 캐시, 그리고 Web Storage와 IndexedDB 같은 브라우저 관리 구조화 사이트 데이터를 처리한다. Firefox에서는 네트워킹과 영구 상태가 다르게 분산되어 있지만, 여전히 둘 사이에는 구분이 있다 [chromium-process-model-site-isolation] [webkit-storage-documentation] [firefox-process-model].

이 계층은 쿠키, 캐시, 파티션된 상태, 사이트 데이터 경계가 강제되는 곳인 경우가 많기 때문에 중요하다. 명세가 가져오기, 자격 증명, 저장소 접근 또는 응답 처리에 영향을 미친다면 이 계층과 상호작용할 가능성이 높다.

웹 브라우저 위협 모델 다이어그램에서 이 다이어그램은 이들을 각각 "Network / Socket / Networking Process" 및 "Data Store"라고 지칭한다.

1.2.4. 그래픽, 미디어 및 헬퍼

현대 웹 브라우저는 GPU, 코덱 및 기타 헬퍼 기능도 별도 프로세스로 분리한다. 이는 미디어 라이브러리가 흔한 공격 표면이기 때문이기도 하다. Chromium은 GPU process와 추가 헬퍼 프로세스 계열을 분리한다. Firefox는 GPU Process, RDD Process, GMP Process, Utility Process, Network (Socket) Process를 분리한다. WebKit도 관련 기능을 위한 프로세스를 분리한다 [inside-browser-part-1] [firefox-gecko-processes] [webkit2-architecture-overview].

위협 모델링 관점에서 이러한 헬퍼 프로세스는 신뢰할 수 없는 콘텐츠와 복잡한 구현 표면 사이의 경계에 위치하기 때문에 중요하다. 이는 일반적인 구현 패턴이기도 하다. 신뢰할 수 없는 실행이나 충돌이 발생하기 쉬운 기능을 권한 있는 제어 경로로부터 분리하여 결함이 발생했을 때 영향을 줄이는 것이다.

웹 브라우저 위협 모델 다이어그램에서 이 다이어그램은 이 프로세스를 "GPU / Compositor / Media helper Process"라고 지칭한다.

1.2.5. 요소 사전

1.2.5.1. 외부 엔터티

1.2.5.2. 위협 경계

1.2.5.3. 프로세스

1.2.5.4. 데이터 저장소

1.2.5.5. 흐름

이 표기법은 W3C Threat Modeling Guide를 따른다. E는 외부 엔터티, P는 프로세스, F는 흐름, S는 데이터 저장소, C는 위협 컨테이너, B는 위협 경계를 나타낸다 [threat-modeling-guide].

1.3. 가정과 외부 의존성

시스템 모델은 브라우저의 직접 제어 밖에 있지만 브라우저의 보안 태세에 영향을 미치는 여러 외부 시스템, 서비스 및 책임에 의존한다.

• 운영 체제(OS): 브라우저는 OS가 부여한 권한, 즉 사용자 권한과 동등한 권한으로 실행된다. 브라우저 보안 목표는 탭, 웹사이트, OS 사이에서 올바르게 드러나야 한다. OS는 브라우저보다 직접 네트워크 연결에 대해 더 높은 수준의 보안을 제공한다.

• 네트워크/인터넷: 브라우저의 주요 기능은 인터넷의 임의 위치에서 명령과 콘텐츠를 요청하는 것이다. 이는 브라우저가 아마도 신뢰하는 TCP/IP 같은 기반 네트워크 프로토콜에 의존한다. 인터넷의 탈중앙화된 특성은 암호화되지 않은 데이터가 누군가에게 읽히고 있을 가능성이 높다는 것을 의미한다.

• 웹 서버와 그 백엔드: 이들은 브라우저를 위한 콘텐츠, 명령(스크립트, HTML), 리소스의 주요 출처이다. 브라우저는 제어를 넘겨주고 서버가 제공한 명령을 실행해야 한다. 웹 서버는 브라우저의 보안을 낮출 수도 있다. 웹사이트는 데이터베이스, 오프사이트 저장소, 기업 데이터 센터와 상호작용한다. 데이터는 브라우저 컨텍스트와 이러한 백엔드 시스템 사이에서 흐른다.

• 서드파티/다른 출처: 현대 웹 애플리케이션은 다른 출처의 리소스와 스크립트를 포함하는 경우가 많으며, 이들 역시 실행되어야 한다. 웹사이트는 광고, 분석 또는 인증 데이터베이스를 위해 서드파티에 의존할 수 있다.

• 네이티브 애플리케이션: 사용자 시스템에 설치된 다른 애플리케이션은 브라우저 자산에 직접 접근할 가능성이 있다(예: 파일 시스템 또는 메모리 검사).

• 암호학: 암호 프로토콜의 사용과 그와의 상호작용은, 구체적인 입력은 아니지만 특히 양자 내성 암호로의 전환과 관련된 현재 역사적 시점에서 고려해야 할 위협의 한 범주이다.

• 외부 구성요소/시스템: 구성요소나 시스템에 대한 모든 외부 의존성은 브라우저의 보안에 영향을 줄 수 있다.

1.4. 진입점과 공격 표면

진입점은 시스템 모델의 흐름과 경계를 기준으로 읽힌다. 진입점은 공격자가 시스템과 상호작용하거나 시스템에 데이터를 제공할 수 있는 인터페이스 또는 메커니즘이다. 웹 브라우저의 경우 여기에는 다음이 포함된다.

• 브라우저 UI: 사용자 입력이 제공되는 사용자 인터페이스 자체. Trusted UI도 포함한다.

• 네트워크 인터페이스: 브라우저가 네트워크를 통해 통신하는 데 사용하는 포트와 프로토콜(예: 소켓, RPC, HTTP/HTTPS 포트).

• 웹 콘텐츠(HTML, CSS, 글꼴, 스크립트, 미디어): 웹 서버에서 전달되는 악성 코드, 스크립트 또는 콘텐츠. 브라우저는 스크립트가 제시될 때 신뢰할 수 없는 출처의 코드를 실행한다. 공격자는 브라우저가 악성 콘텐츠를 렌더링하도록 설득할 수 있다. 구체적인 위협은 특정 파일 형식과 연결된다.

• 사용자 입력 필드: 사용자가 데이터를 입력할 수 있는 모든 영역. 악의적으로 조작될 수 있다(예: 폼, URL).

• 브라우저 확장: 브라우저는 확장이 브라우저 및 웹 콘텐츠와 상호작용하기 위한 인터페이스를 노출한다.

• Web API: 표준 Web API와 브라우저가 노출하는 잠재적으로 새롭고 흥미로운 API 모두.

• 기반 플랫폼: 출처가 기반 플랫폼에 데이터를 보낼 수 있게 하는 기능.

1.5. 보안 속성, 자산 및 불변 조건

웹 브라우저 위협 모델을 고려할 때 보호해야 하는 보안 관련 상태, 리소스 및 속성은 다양하며 사용자 보안과 개인정보 보호에 매우 중요하다.

• 사용자 데이터: 일반 사용자 데이터, 민감한 데이터, 개인 식별 정보.

• 사용자 데이터 개인정보 보호: 사용자가 자신의 사적 정보와 활동을 감시, 상관관계 분석, 식별로부터 제어하고 보호할 수 있는 능력. 여기에는 투명성이나 통제 없이 브라우징 세션 내와 세션 간에 사용자를 식별하거나 상관관계를 만드는 것을 피하는 것이 포함된다.

• 사용자 자격 증명: 로그인 정보, 사용자 이름, 비밀번호.

• 사용자 쿠키와 세션 정보: 쿠키, 세션 ID, 세션 상태에 저장된 데이터. 이는 방문 간 사용자를 인식하는 데 사용될 수 있다.

• 사용자 기기/컴퓨터: 사용자의 파일 시스템의 기밀성과 무결성을 포함한 사용자의 기계와 그 리소스.

• 로컬 저장소: 쿠키, localStorage, indexedDB, 캐시, 기록, 비밀번호를 포함해 브라우저가 로컬에 저장한 데이터.

• 사용자 브라우징 기록: 방문한 사이트에 관한 정보.

• 사용자 환경 정보: 운영 체제 구성, 브라우저 구성, 하드웨어 기능.

• 사용자 활동과 관심사: 구매 선호, 개인적 특성, 이전 활동.

• 보호된 리소스: 사용자가 접근할 수 있지만 공격자가 접근해서는 안 되는 모든 리소스.

• 사설 네트워크 리소스: 브라우저가 사용자의 명시적 요청 없이 접근할 수 있는 서로 다른 네트워크 리소스.

• 자격 증명과 암호화 키: 브라우저는 암호화와 서명을 위한 공개 키와 비밀 키를 관리한다.

• 웹사이트의 기밀 정보: 웹사이트에 표시되거나 접근 가능한 데이터.

다음 속성과 불변 조건은 위협 분석을 위한 프롬프트로 사용된다.

• 상호 신뢰하지 않는 출처들은 플랫폼이 명시적이고 제어된 통신 경로를 정의하지 않는 한 격리된 상태를 유지한다.

• 웹 콘텐츠는 브라우저가 중개하는 기능을 통하지 않고는 운영 체제 권한을 직접 행사할 수 없다.

• 브라우저가 중개하는 권한은 브라우저가 제어하는 사용자 중개, 정책 또는 구성을 통해 부여된다.

• 브라우저 관리 상태는 관련 출처, 사이트, 프로필, 파티션 또는 권한 경계에 따라 범위가 지정된다.

• 브라우저 중개가 필요한 경우 보안에 민감한 사용자 의도는 웹이 제어하는 UI만으로 추론되지 않는다.

• 네트워크, 저장소, 렌더링 및 운영 체제 접근 경로는 시스템 모델에 표시된 경계를 보존한다.

2. 무엇이 잘못될 수 있는가?

2.1. 위협 분석 방법

이 위협 모델은 시스템 모델의 계층, 요소, 흐름, 저장소, 경계를 반복적으로 살펴보면서 웹 플랫폼을 분석한다. 모델의 각 관련 부분에 대해, 분석은 어떤 속성이 유지될 것으로 기대되는지, 무엇이 그 속성을 위반할 수 있는지, 누가 영향을 받을 수 있는지, 어떤 피해가 발생할 수 있는지를 묻는다. 위협 원천과 고수준 위협 계열은 프롬프트로 사용되지만, 분석은 위의 모델에 기반한다.

2.2. 위협 원천

• 브라우저 확장: 브라우저 확장은 유용성에도 불구하고 수많은 보안 취약점을 도입한다. 악의적 행위자는 피싱, 키로깅, 감시, 데이터 절도, 세션 하이재킹 같은 정교한 공격에 이를 악용한다. 이들은 특정 출처에 접근할 권한을 갖도록 설치되고 구성되어야 하며, 이는 공격의 복잡성을 높인다.

• 애플리케이션/웹사이트: 웹사이트는 침해되거나 악의적일 수 있다. 다양한 공격은 동일 웹사이트에서 사용자의 세션을 침해하거나(예: 쿠키 절도, 또는 임의 요청 생성 - Cross Site Request Forgery - CSRF, UI Redressing/Clickjacking), 동일 출처를 우회해 다른 웹사이트의 정보를 얻거나(즉 Cross-Site Leaks - XS Leaks), 브라우저 자체를 침해하는 데(예: 브라우저 프로세스 안에서 임의 코드를 실행해 브라우저 내부 데이터에 대한 제어를 얻거나 사용자 기기를 침해) 향할 수 있다. 공격자는 기존 브라우저 기능을 악용한다.

2.3. 고수준 위협 색인

이는 웹 플랫폼 위협 모델을 위한 주요 위협 계열의 색인이며, 완전한 목록은 아니다.

• 추적/개인정보 손실: 핑거프린팅은 사용자의 인지나 동의 없이 사용자를 식별하는 방법이다. 핑거프린팅은 개인정보와 보안 문제 모두에 닿아 있으며 이중적 의미를 가진다. 한편으로는 공격자가 사용자를 고유하게 식별하는 데 사용할 수 있다. 이는 보통 개인정보와 관련된 시나리오로, 여러 사이트에 걸쳐 사용자 프로필이나 기록을 만들 수 있게 하며, 종종 사용자의 인지나 동의 없이 이루어진다. 다른 한편으로는 기기의 유형을 식별하는 데 사용할 수 있다. 이는 보통 보안과 관련된 시나리오로, 예를 들어 이후 기기 침해에 사용될 수 있다. 명세가 노출하는 데이터, 특히 기반 플랫폼이나 지속되는 상태에 관한 정보는 핑거프린팅에 기여할 수 있다. 일부 API는 핑거프린팅 표면을 추가할 수 있다.

3. 우리는 이에 대해 무엇을 할 것인가?

3.1. 보안 기능 및 제어

웹 브라우저는 앞서 식별한 속성과 불변 조건을 보존하는 데 도움이 되는 다양한 보안 기능과 보호 메커니즘을 사용한다.

• 샌드박싱: 샌드박싱은 렌더링 엔진 같은 구성요소를 제한하고, 운영 체제와 사용자 파일에 대한 접근을 제한하는 핵심 메커니즘이다. 이는 OS 권한과 하위 프로세스 권한 사이의 장벽으로 작동한다.

• Same Origin Policy (SOP): 한 출처에서 로드된 문서나 스크립트가 다른 출처의 리소스와 상호작용할 수 있는 방식을 제한하는 기본적인 보안 제어.

• Content Security Policy (CSP): 어떤 동적 리소스를 로드할 수 있는지 지정하여 XSS, 클릭재킹 및 기타 코드 삽입 공격을 방지하기 위한 보안 표준.

• HTTPS/SSL/TLS: 브라우저와 웹 서버 사이의 안전하고 암호화된 통신을 위한 프로토콜로, 전송 중 데이터 무결성과 기밀성을 보장한다. HTTP Strict Transport Security (HSTS)가 관련된다.

• 입력 검증 및 출력 인코딩: XSS 같은 삽입 공격을 방지하기 위해 사용자가 제공한 데이터를 처리하는 데 중요한 실무.

• 보안 헤더: 콘텐츠를 안전하게 처리하도록 브라우저에 지시하는 HTTP 헤더.

• 피싱 방지 및 악성코드 방지: Safe Browsing 같은 기능은 악성 웹사이트에 대해 사용자에게 경고한다.

• 혼합 콘텐츠 처리: 안전한(HTTPS) 페이지가 안전하지 않은(HTTP) 리소스를 로드할 때 브라우저가 이를 처리하는 방식.

• 렌더러 격리: 렌더링 엔진처럼 복잡하고 오류가 발생하기 쉬운 구성요소를 브라우저 커널과 별개의 샌드박스화된 프로세스나 보호 도메인에 배치하는 아키텍처. 브라우저 커널은 민감한 OS, 네트워크, 저장소 상호작용을 처리한다.

• 프로세스 간 통신(IPC): 격리된 브라우저 구성요소(예: 커널과 렌더러) 사이의 통신을 위한 안전한 채널.

• 다운로드 관리자: 파일 다운로드를 처리하는 구성요소로, 잠재적으로 보안 검사를 포함한다.

• 데이터 최소화 및 개인정보 설정: 잠재적으로 식별 가능한 정보의 노출을 줄이기 위한 설계 원칙과 구성.

• Trusted UI: 민감한 사용자 상호작용이 웹 콘텐츠가 쉽게 스푸핑하거나 조작할 수 없는 브라우저 인터페이스 안에서 발생하도록 보장하는 것.

• Permission API: 강력한 기능을 활성화하기 전에 명시적인 사용자 권한을 요청하는 것.

• Transient Activation: 이는 게이트이며, 사용자가 최근에 버튼을 누르거나, 마우스를 움직이거나, 메뉴를 사용하거나, 다른 사용자 상호작용을 수행했음을 나타내는 창 상태이다. 때로는 Web API가 사용자 상호작용에 의해 트리거된 경우에만 동작할 수 있도록 보장하는 메커니즘으로 사용된다. 예를 들어 스크립트는 임의로 팝업을 실행할 수 없으며, transient activation이 필요하다. 즉 UI 요소의 이벤트 핸들러에서 트리거되어야 한다.

4. 우리는 충분히 잘했는가?

5. 감사의 말

여러 개인이 이 문서에 기여했다. 편집자들은 특히 Anna Weine에게 감사한다.