이 초보자 가이드에서 WebAssembly(WASM) 이식성 및 보안 모델이 어떻게 작동하는지 확인하십시오.
둘 다 고급 WebAssembly(WASM) 항목입니다. 초보자를 위한 WebAssembly 시리즈의 이전 두 주제를 읽어보는 것이 좋습니다.
시작하자.
목차
웹어셈블리 이식성
WebAssembly의 이식성 덕분에 웹에 사용할 준비가 되었습니다. 실제로 WASM을 휴대용 샌드박스 플랫폼으로 정의할 수 있습니다.
또한 바이너리 형식을 통해 다양한 명령어 세트 아키텍처 및 운영 체제에서 실행할 수 있습니다. 이는 웹뿐만 아니라 웹 밖에서도 WASM을 사용할 수 있음을 의미합니다.
WASM 이식성을 이해하기 위해 다음을 논의합니다.
- 로컬, 제한적 및 비결정적 환경.
- 특정 실행 환경 특성
- WASM 웹 및 비웹 이식성
로컬, 제한적 및 비결정적
WASM은 효율적인 실행과 지역적이고 제한적이며 비결정적인 적절한 환경이 필요합니다. 비결정론은 알고리즘/컴파일러/환경이 동일한 입력에 대해서도 다른 동작이나 결과를 출력하도록 지정하는 컴퓨팅입니다. 결정론적 알고리즘의 반대입니다.
제한적 및 로컬이라는 두 가지 다른 측면은 비결정적 실행과 관련이 있습니다. 비결정적 실행이 작동하려면 “제한된” 잘 정의된 사용 사례가 필요합니다.
또한 이러한 실행은 환경 외부에 영향을 주지 않는 “로컬”입니다. 자세한 내용은 WebAssembly 문서에서 공식적인 비결정론을 읽어보십시오.
특정 실행 환경 특성
WebAssembly를 이식 가능하게 만들기 위해 실행 환경이 다음과 같은 특성을 제공한다고 가정합니다.
- 바이트 메모리 세분성 주소 지정 가능성 및 8비트 바이트.
- 32비트 2의 보수 부호 있는 정수. 선택적으로 64비트.
- 정렬되지 않은 메모리 액세스 또는 안정적인 트래핑을 통해 소프트웨어 에뮬레이션이 가능합니다.
- IEEE 754-2008에 정의된 32비트 및 64비트 부동 소수점을 지원합니다.
- 앞으로 진행하면서 모든 스레드를 실행하도록 보장합니다.
- 64비트 액세스의 경우 wasm64는 잠금 없는 원자 메모리 연산자를 제공해야 합니다.
- 잠금 없는 원자 메모리 연산자에는 8, 16 및 32비트 액세스가 포함됩니다.
- wasm64는 64비트 인덱스 또는 포인터가 있는 4GiB 이상의 선형 메모리를 지원합니다.
- 리틀 엔디안 바이트 순서.
Chrome, Edge, Firefox 및 WebKit을 포함한 모든 주요 브라우저는 이러한 모든 환경 요구 사항을 지원합니다.
또한 WebAssembly는 빠른 속도로 진화하고 있습니다. WASM Community Group과 W3C WebAssembly Working Group은 표준화를 위해 노력하고 있습니다. 이는 이러한 요구 사항이 향후 변경될 수 있음을 의미합니다.
WASM 웹 및 비웹 이식성
WebAssembly의 주요 목적은 웹과 비웹에서 이식성과 기본 성능을 제공하는 것입니다. 이 섹션에서는 WASM이 이를 달성하는 방법을 살펴보겠습니다.
#1. 웹 임베딩
WASM은 웹의 보안 모델, 웹 이식성 및 웹 API를 포함한 웹 생태계와 잘 통합됩니다. 또한 향후 창의적 개발을 위한 충분한 공간이 있어야 합니다(목표를 이해하려면 WebAssembly for Beginners – Part 2 참조).
그렇다면 WASM은 어떻게 웹과의 호환성을 달성합니까? JavaScript API를 활용하여 개발자가 WebAssembly 모듈 컴파일에 JavaScript를 쉽게 사용할 수 있습니다. 또한 컴파일러 모듈 저장 및 검색, 컴파일러 모듈에서 가져오기 관리, 메모리 관리 등을 처리합니다.
WASM이 높은 수준의 웹 호환성을 달성하는 방법에 대해 자세히 알아보려면 웹 임베딩 – WebAssembly를 읽어보십시오.
#2. 비 웹 임베딩
앞에서 언급했듯이 WASM은 웹이 아닌 환경에서도 작동합니다. 개발자 또는 비즈니스는 고성능 애플리케이션을 만들거나 성능 조정이 필요한 앱 섹션을 작성할 수 있습니다. 예를 들어 IoT 장치, 데이터 센터 서버 및 데스크톱/모바일 앱에서 사용할 수 있습니다.
웹이 아닌 애플리케이션은 웹 API를 사용할 수 없으므로 WASM의 동적 연결에 의존합니다. 또한 사용자 경험에 가장 적합한 기능을 확인하기 위해 기능의 다양한 변형을 테스트하는 소프트웨어 개발 프로세스인 기능 테스트를 사용해야 합니다. 또한 개발자는 JavaScript VM을 사용하여 비웹 포함을 단순화하거나 JavaScript VM 없이 앱을 개발할 수 있습니다.
자세한 내용은 비웹 임베딩 – WebAssembly를 참조하십시오.
웹어셈블리 보안
WebAssembly는 네이티브와 같은 성능을 제공하는 바이너리 형식 솔루션입니다. 웹에서 훌륭하게 작동하지만 웹이 아닌 임베딩에서 작동하도록 미세 조정할 수도 있습니다. 따라서 WASM은 서비스, 솔루션 및 프로세스 전반에서 광범위하게 사용할 수 있습니다. 그러나 이것은 더 많은 보안 문제를 의미합니다.
WASM 보안 과제 및 위험
WebAssembly는 안전하고 효율적인 것으로 간주되지만 다음과 같은 여러 보안 위험이 따릅니다.
- 웹어셈블리 샌드박스
- 메모리 관리
- 코드 난독화
- 무결성 검사
#1. 웹어셈블리 샌드박스
WASM은 JavaScript와 마찬가지로 웹 브라우저 내에서 실행됩니다. JavaScript와 동일한 가상 머신(VM)을 사용합니다. 샌드박스는 안전한 실행 환경을 효과적으로 제공하고 내부에서 실행되는 것을 방해합니다.
따라서 JavaScript/WebAssembly 코드에 악성코드가 포함되어 있을 경우 블랙박스이기 때문에 탐지가 어렵습니다. 또한 WASM 코드는 바로 실행할 수 있는 바이너리 형식입니다. 더 빠르게 실행되므로 바이러스 백신 솔루션이 악성 코드를 찾기가 어렵습니다. 예를 들어 코드에는 원치 않는 광고 또는 원치 않는 맬웨어 사이트로 사용자를 리디렉션하는 기능이 포함될 수 있습니다.
또한 웹에서 실행하기 위해 WebAssembly가 JavaScript에 과도하게 의존한다는 것은 JavaScript 취약점을 물려받았다는 것을 의미합니다. 그렇기 때문에 개발자는 WASM을 코딩할 때 JavaScript의 안전 예방 조치 및 조치를 따라야 합니다.
#2. 메모리 관리
WASM의 메모리 관리는 까다롭습니다. 첫째, VM 내에서 실행되므로 물리적 메모리에 직접 액세스하지 않습니다. 이것이 호스트 시스템의 메모리를 사용하는 이유입니다.
둘째, WASM에서 메모리를 정리하려면 명시적인 프로세스가 필요하지만 이에 비해 JavaScript는 자체적으로 정리합니다.
또한 WASM 함수가 JavaScript로 출력을 반환할 때 할당된 WASM 메모리 공간 내의 위치에 대한 포인터를 반환합니다. 따라서 선언된 메모리가 가득 차면 WASM 프로그램이 충돌하여 사용자 경험을 망칠 수 있습니다. 이를 방지하기 위해 프로그래머는 새니타이저를 사용하여 코드를 디버깅하거나 emscripten과 같은 도구 체인을 사용해야 합니다.
#삼. 코드 난독화
WASM의 샌드박스 실행은 코드를 난독화합니다. 또한 WASM 바이너리 형식은 사람이 읽을 수 없기 때문에 악성 코드를 식별하는 데 필요한 리버스 엔지니어링이 어렵습니다.
이로 인해 WebAssembly 코드는 사람이 읽을 수 있는 형식이 없기 때문에 디버깅하기 어렵습니다. 이로 인해 중요한 정보를 훔치는 코드를 숨기거나 호스트 시스템을 장악하기 위해 코드를 주입하는 해커의 능력을 포함하여 많은 보안 허점이 열립니다.
#4. 무결성 검사
웹을 통해 전송되는 모든 데이터는 데이터 조작에 취약합니다. 예를 들어 해커는 중간자 공격을 수행하여 데이터 값을 변경할 수 있습니다. 무결성 검사를 수행할 적절한 방법이 없다는 점을 고려하면 WASM의 문제입니다.
그러나 JavaScript와 함께 작동하여 무결성 검사를 수행할 수 있습니다. 잠재적인 WASM 코드 취약성을 식별하는 또 다른 방법은 Jit와 같은 통합 도구를 사용하는 것입니다. 코드에 악의적인 행위자가 없고 앱이나 주변 클라우드 인프라에 영향을 미치지 않도록 합니다.
WASM 보안 모델 이해
WebAssembly는 보안을 중요하게 생각합니다. 이것이 바로 공식 WASM 문서에서 보안 모델이 두 가지 중요한 목표를 처리한다고 언급한 이유입니다.
WASM 보안 모델은 WebAssembly 앱이 샌드박스 환경에서 벗어날 수 없는 동안 독립적으로 실행된다는 것을 알고 있습니다. 그러나 API는 호스트 환경을 공격하는 방법을 열 수 있습니다.
또 다른 내결함성 기술에는 제한된 기대로 앱을 결정론적으로 실행하는 것이 포함됩니다. 두 조건을 모두 보장하면 대부분의 앱 실행이 안전한 것으로 간주됩니다.
보안을 개선하기 위해 개발자는 정보 흐름에 대해 동일 출처 정책을 시행해야 합니다. 비웹용으로 개발하는 경우 POSIX 보안 모델을 사용해야 합니다. 보안 모델에 대해 자세히 알아보려면 Security – WebAssembly를 확인하십시오.
웹어셈블리 시스템 인터페이스(WASI)
WASI(The WebAssembly System Interface)는 또한 보안을 향상시키므로 WASM 비웹 임베딩에서 중요한 역할을 합니다. 흥미로운 보안 특성과 이식성을 제공하는 모듈식 시스템 인터페이스입니다.
사실 이것은 이제 WebAssembly System Interface Subgroup Charter의 일부이므로 표준화되었습니다. WASI로 인해 WASM은 다양한 에지/서버 컴퓨팅 영역에서 널리 채택됩니다. 또한 WASI는 웹 임베딩 환경에서 비웹 임베딩으로 이동할 때 보안을 단순화합니다.
마지막 말
WebAssembly의 이식성과 보안은 두 가지 큰 주제입니다. 초보자를 위한 WebAssembly의 3부에서는 특히 초보자를 위해 WebAssembly를 단순화하고 분해하려고 했습니다.
다음으로 개발자와 학습자를 위한 JavaScript 치트 시트를 확인할 수 있습니다.