WASM 이식성 및 보안 작동 방식

웹어셈블리(WASM)의 이식성과 보안 모델의 작동 방식을 이 초급자 가이드에서 알아보세요.

이 주제들은 웹어셈블리(WASM)의 고급 영역에 해당하므로, 처음 두 편의 초급자용 웹어셈블리 시리즈를 먼저 읽어보시는 것을 권장합니다.

이제 시작해 보겠습니다.

웹어셈블리의 이식성

웹어셈블리의 뛰어난 이식성은 웹 환경에서 즉시 사용 가능하게 만들어줍니다. 사실상 WASM은 휴대 가능한 샌드박스 플랫폼으로 정의할 수 있습니다.

바이너리 형식을 사용하기 때문에 다양한 명령어 세트 아키텍처 및 운영 체제에서 실행될 수 있습니다. 즉, 웹뿐만 아니라 웹 외부 환경에서도 WASM을 활용할 수 있다는 의미입니다.

WASM의 이식성을 보다 깊이 이해하기 위해 다음 주제들을 살펴보겠습니다.

지역적, 제한적, 비결정적 환경
특정 실행 환경의 특징
웹 및 비웹 환경에서의 WASM 이식성

지역적, 제한적, 비결정적 특징

WASM은 효율적인 실행을 위해 적절한 지역적, 제한적, 비결정적 환경이 필요합니다. 여기서 비결정성이란, 동일한 입력값에 대해서도 알고리즘, 컴파일러, 환경이 서로 다른 동작이나 결과를 생성할 수 있도록 지정하는 컴퓨팅 방식을 말합니다. 이는 결정론적 알고리즘과는 반대되는 개념입니다.

제한성과 지역성, 이 두 가지 측면은 비결정적 실행과 밀접한 관련이 있습니다. 비결정적 실행이 제대로 작동하려면 명확하게 정의된 "제한된" 사용 사례가 필요합니다.

또한 이러한 실행은 환경 외부에는 영향을 미치지 않는 "지역적" 성격을 가집니다. 자세한 내용은 WebAssembly 공식 문서에서 비결정론 관련 부분을 참조하시기 바랍니다.

특정 실행 환경의 특징

웹어셈블리를 이식 가능하게 만들기 위해, 실행 환경은 다음과 같은 특징을 제공한다고 가정합니다.

바이트 단위 메모리 세분성 주소 지정 가능성 및 8비트 바이트
32비트 2의 보수 부호 있는 정수 (선택적으로 64비트)
정렬되지 않은 메모리 접근 또는 안전한 트래핑을 통한 소프트웨어 에뮬레이션
IEEE 754-2008에 정의된 32비트 및 64비트 부동 소수점 지원
모든 스레드를 순차적으로 실행할 수 있다는 보장
64비트 접근의 경우 wasm64는 잠금 없는 원자 메모리 연산자 제공
잠금 없는 원자 메모리 연산자에는 8, 16 및 32비트 접근 포함
wasm64는 64비트 인덱스 또는 포인터로 4GiB 이상의 선형 메모리 지원
리틀 엔디안 바이트 순서

Chrome, Edge, Firefox, WebKit 등 주요 브라우저는 이러한 모든 환경 요구 사항을 충족합니다.

또한, 웹어셈블리는 빠른 속도로 발전하고 있습니다. WASM 커뮤니티 그룹과 W3C 웹어셈블리 작업 그룹은 표준화를 위해 노력하고 있으며, 이는 향후 이러한 요구 사항이 변경될 수 있음을 의미합니다.

웹 및 비웹 환경에서의 WASM 이식성

웹어셈블리의 주요 목표는 웹과 비웹 환경 모두에서 이식성과 네이티브 수준의 성능을 제공하는 것입니다. 이 섹션에서는 WASM이 어떻게 이러한 목표를 달성하는지 살펴보겠습니다.

#1. 웹 환경에서의 임베딩

WASM은 웹의 보안 모델, 이식성, 웹 API 등 웹 생태계와 원활하게 통합됩니다. 또한, 미래의 창의적인 개발을 위한 충분한 여지를 남겨두어야 합니다. (목표를 이해하려면 "초급자를 위한 웹어셈블리 - 2부"를 참고하세요.)

그렇다면 WASM은 어떻게 웹 호환성을 달성할까요? JavaScript API를 활용하여 개발자가 JavaScript를 사용하여 웹어셈블리 모듈을 쉽게 컴파일할 수 있도록 합니다. JavaScript API는 컴파일러 모듈 저장 및 검색, 컴파일러 모듈에서 가져오기 관리, 메모리 관리 등을 처리합니다.

WASM이 높은 수준의 웹 호환성을 달성하는 방법에 대해 자세히 알아보려면 "웹 임베딩 – 웹어셈블리" 문서를 참조하세요.

#2. 비웹 환경에서의 임베딩

앞서 언급했듯이 WASM은 웹이 아닌 환경에서도 작동합니다. 개발자 또는 기업은 고성능 애플리케이션을 만들거나 성능 조정이 필요한 앱 섹션을 작성할 수 있습니다. 예를 들어 IoT 장치, 데이터 센터 서버, 데스크톱/모바일 앱 등 다양한 곳에서 사용할 수 있습니다.

웹이 아닌 애플리케이션은 웹 API를 사용할 수 없으므로 WASM의 동적 연결에 의존합니다. 또한 사용자 경험에 가장 적합한 기능을 확인하기 위해 기능의 다양한 변형을 테스트하는 소프트웨어 개발 프로세스인 기능 테스트를 사용해야 합니다. 개발자는 JavaScript VM을 사용하여 비웹 포함을 단순화하거나 JavaScript VM 없이 앱을 개발할 수 있습니다.

자세한 내용은 "비웹 임베딩 – 웹어셈블리" 문서를 참고하세요.

웹어셈블리 보안

웹어셈블리는 네이티브 수준의 성능을 제공하는 바이너리 형식 솔루션입니다. 웹에서 훌륭하게 작동하지만, 웹이 아닌 환경에서도 사용 가능하도록 조정할 수 있습니다. 따라서 WASM은 서비스, 솔루션, 프로세스 전반에서 폭넓게 활용될 수 있습니다. 하지만, 이는 더 많은 보안 문제를 야기할 수 있다는 의미이기도 합니다.

WASM 보안 과제 및 위험

웹어셈블리는 안전하고 효율적인 것으로 간주되지만, 다음과 같은 여러 보안 위험 요소가 존재합니다.

웹어셈블리 샌드박스
메모리 관리
코드 난독화
무결성 검사

#1. 웹어셈블리 샌드박스

WASM은 JavaScript와 마찬가지로 웹 브라우저 내에서 실행됩니다. JavaScript와 동일한 가상 머신(VM)을 사용하며, 샌드박스는 안전한 실행 환경을 제공하여 내부에서 실행되는 프로세스를 격리합니다.

따라서 JavaScript/웹어셈블리 코드에 악성 코드가 포함되어 있더라도, 블랙박스처럼 작동하기 때문에 탐지하기가 어렵습니다. 또한, WASM 코드는 바로 실행 가능한 바이너리 형식이므로 더 빠르게 실행되어 바이러스 백신 솔루션이 악성 코드를 찾기가 더 어렵습니다. 예를 들어, 코드에는 원치 않는 광고를 표시하거나 사용자를 악성 사이트로 리디렉션하는 기능이 포함될 수 있습니다.

웹에서 실행하기 위해 WASM이 JavaScript에 과도하게 의존한다는 것은, JavaScript의 취약점을 그대로 이어받았다는 의미이기도 합니다. 따라서 개발자는 WASM 코드를 작성할 때 JavaScript의 안전 예방 조치 및 방법을 따라야 합니다.

#2. 메모리 관리

WASM의 메모리 관리는 다소 까다롭습니다. 첫째, VM 내에서 실행되므로 물리적 메모리에 직접 액세스하지 않고 호스트 시스템의 메모리를 사용합니다.

둘째, WASM에서 메모리를 정리하려면 명시적인 프로세스가 필요하지만, JavaScript는 스스로 메모리를 정리합니다.

또한, WASM 함수가 JavaScript로 출력을 반환할 때 할당된 WASM 메모리 공간 내의 위치에 대한 포인터를 반환합니다. 따라서 선언된 메모리가 가득 차면 WASM 프로그램이 충돌하여 사용자 경험을 저해할 수 있습니다. 이를 방지하기 위해 프로그래머는 새니타이저를 사용하여 코드를 디버깅하거나 emscripten과 같은 도구 체인을 사용해야 합니다.

#3. 코드 난독화

WASM의 샌드박스 실행은 코드를 난독화합니다. 또한 WASM 바이너리 형식은 사람이 읽을 수 없으므로 악성 코드를 식별하는 데 필요한 리버스 엔지니어링이 어렵습니다.

이로 인해 웹어셈블리 코드는 사람이 읽을 수 있는 형식이 없어 디버깅이 어렵습니다. 또한 중요한 정보를 훔치는 코드를 숨기거나 호스트 시스템을 장악하기 위해 코드를 주입하는 해커의 능력을 포함하여 많은 보안 허점을 유발할 수 있습니다.

#4. 무결성 검사

웹을 통해 전송되는 모든 데이터는 데이터 조작에 취약합니다. 예를 들어, 해커는 중간자 공격을 수행하여 데이터 값을 변경할 수 있습니다. 무결성 검사를 수행할 적절한 방법이 없다는 점을 고려하면, WASM에 심각한 보안 문제가 발생할 수 있습니다.

그러나 JavaScript와 함께 작동하여 무결성 검사를 수행할 수 있습니다. 또한, Jit와 같은 통합 도구를 사용하면 잠재적인 WASM 코드 취약성을 식별할 수 있습니다. 이를 통해 코드에 악의적인 행위자가 없고 앱이나 주변 클라우드 인프라에 영향을 미치지 않도록 할 수 있습니다.

WASM 보안 모델 이해

웹어셈블리는 보안을 매우 중요하게 생각합니다. 공식 WASM 문서에서도 보안 모델이 다음 두 가지 중요한 목표를 처리한다고 명시하고 있습니다.

버그가 있거나 악성 모듈이 사용자에게 영향을 미치지 않도록 합니다.

개발자가 모든 보안 위험을 완화하고 안전한 애플리케이션을 만들 수 있도록 하면서 위에서 언급한 목표가 항상 유지되도록 합니다.

WASM 보안 모델은 웹어셈블리 앱이 샌드박스 환경에서 벗어날 수 없는 동안 독립적으로 실행된다는 점을 보장합니다. 그러나 API는 호스트 환경을 공격하는 경로를 제공할 수도 있습니다.

또 다른 내결함성 기술로는 제한된 조건하에서 앱을 결정론적으로 실행하는 방식이 있습니다. 이 두 가지 조건을 모두 충족시키면 대부분의 앱 실행을 안전하다고 간주할 수 있습니다.

보안을 강화하기 위해 개발자는 정보 흐름에 대해 동일 출처 정책을 시행해야 합니다. 비웹 환경용으로 개발하는 경우 POSIX 보안 모델을 사용해야 합니다. 보안 모델에 대해 자세히 알아보려면 "보안 – 웹어셈블리" 문서를 참조하세요.

웹어셈블리 시스템 인터페이스(WASI)

웹어셈블리 시스템 인터페이스(WASI) 또한 보안을 강화하므로 WASM 비웹 임베딩에서 중요한 역할을 합니다. WASI는 뛰어난 보안 기능과 이식성을 제공하는 모듈식 시스템 인터페이스입니다.

WASI는 현재 웹어셈블리 시스템 인터페이스 하위 그룹 헌장의 일부로 표준화되었습니다. WASI 덕분에 WASM은 다양한 엣지/서버 컴퓨팅 영역에서 널리 채택되고 있습니다. 또한 WASI는 웹 임베딩 환경에서 비웹 임베딩으로 이동할 때 보안을 간소화합니다.

마지막 말

웹어셈블리의 이식성과 보안은 방대한 주제입니다. 이 "초급자를 위한 웹어셈블리 3부"에서는 특히 초급 학습자를 위해 웹어셈블리의 개념을 쉽게 이해하고 분석하고자 노력했습니다.

다음으로는 개발자와 학습자를 위한 JavaScript 치트 시트를 참고할 수 있습니다.