Как веб-сборка облегчает выполнение кода, который можно взломать или сделать более ненадежным в браузере?

Question

т. Е. Для одного предварительно скомпилированный код труднее читать, что затрудняет значимое изменение кода браузера.

Чем он более «изолированен», чем JS, и делает ли это его менее взломанным?

"WebAssembly задана для запуска в безопасной изолированной среде выполнения."- https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts

Существуют ли свойства формата памяти WASM VM, которые делают его более устойчивым к взлому на стороне клиента?

Что-нибудь еще?

Answer 1

WebAssembly никогда не была разработана, чтобы быть менее взломанной, чем JavaScript. Модули WebAssembly работают в браузере и могут быть проверены и отлажены, как и любое другое приложение JavaScript. Единственная дополнительная защита, которую они предлагают, это защита от запутывания. Это язык более низкого уровня, который затрудняет расшифровку кода - хотя это не является надежной защитой!

Модули WebAssembly находятся в «песочнице», так как один модуль не может получить доступ к памяти или взаимодействовать с другим работающим модулем. У них есть своя изолированная среда исполнения. JavaScript также помещен в «песочницу» для предотвращения взаимодействия кода одной вкладки или страницы с другой - и, что еще более важно, от доступа к базовой операционной системе хоста!

Webassembly использует линейную память, которая представляет собой непрерывный блок памяти, который обычно используется для создания кучи. Его можно экспортировать в среду хоста, что означает, что код JavaScript хостинга может напрямую считывать и записывать его в виде байтового массива.

Таким образом, WebAssembly не менее взломан и имеет другую песочницу. Если это поезда, на которые вы обращаетесь с этой технологией, возможно, пришло время переосмыслить?

Answer 2

В Интернете WebAssembly работает в той же песочнице, что и JavaScript, поэтому WebAssembly не может повлиять на свой хост-компьютер никоим образом, что также невозможно сделать с помощью чистого JavaScript. Но WebAssembly идет дальше, и делает более безопасным запуск ненадежного кода из-за того, как работает его импорт.

Когда создается экземпляр модуля WebAssembly, он поставляется с набором импортированных функций. Эти операции импорта являются единственными основными функциями, к которым у модуля есть доступ, и их нельзя изменить после создания экземпляра модуля. Без импорта модуль WebAssembly может выражать только чистые вычисления и может влиять только на состояние своей собственной памяти. Это означает, что если вы не предоставите импорт, который может выполнять сетевые запросы, вы можете быть уверены, что модуль WebAssembly не может выполнять сетевые запросы. Сравните это с JavaScript, где выяснить, использует ли программа определенный API, вообще невозможно.

Это не означает, что код в модуле WebAssembly не может содержать ошибок или уязвимостей безопасности. Например, атаки переполнения буфера на глючные программы C все еще возможны, когда эти программы C компилируются в WebAssembly, но разница в том, что худшее, что они могут сделать, определяется импортом, который легко проверить. Поэтому, если вы импортируете eval в свой модуль C WebAssembly с ошибками, у вас могут быть серьезные проблемы, но если вы импортируете только console.log, злоумышленник может сделать только спам на вашей консоли.

Я не считаю WebAssembly низкоуровневой как относящуюся к безопасности. Модули WebAssembly не сложнее для чтения, чем свернутый или запутанный JavaScript, и разница почти исчезает, если учесть JavaScript в стиле asm.js. Конечно, читать модуль WebAssembly труднее, чем красиво напечатанную программу JavaScript, но в действительности это никуда не денется с точки зрения безопасности.