#javascript #security #frontend #webassembly #micro-frontend
Вопрос:
Учитывая растущий размер кода интерфейса, концепция федерации микро-интерфейса и модулей, предоставляемая Webpack 5, является возможным решением. Однако, учитывая возможность того, что вы интегрируете код из других команд / третьих сторон, внешний код потенциально может попытаться получить доступ к информации, для которой он не предназначен, просто получив доступ к window объекту и выполнив итерацию через его дочерние элементы.
Это не обязательно должна быть критическая информация, такая как пароли и кредитные карты, которые часто изолируются с помощью an iframe . Менее конфиденциальная информация, такая как электронные письма пользователей или данные отслеживания, может быть собрана и использована не по назначению.
В этом случае существует ли какая-либо техническая настройка, которая не предполагает iframes ограничения области доступа к сценариям? Является ли это чем-то, что технически может быть реализовано в программе веб-сборки?
Правка: Да, консервативное правило состоит в том, чтобы просто не запускать ненадежный код. Однако возникает вопрос, возможно ли технически изолировать внешний код, не iframe ограничивая его доступ к информации.
Комментарии:
1. Есть одно простое правило: не загружайте и не выполняйте код, которому вы не доверяете.
2. Не размещайте конфиденциальную информацию на стороне клиента, не используйте библиотеки или другие приложения, которые по той или иной причине кажутся ненадежными (не поддерживаются известной организацией/группой или не имеют достаточно большого числа подписчиков и т. Д.).
3. @Bergi Обновил комментарий к окну — не звонит, а ссылается. Я бы, конечно, предпочел не запускать ненадежный код, но мне интересно, есть ли способ изолировать ненадежный код. Вопрос любопытства, и если это невозможно, конечно, я не буду этого делать.
Ответ №1:
Javascript по своей сути является «общедоступным», поэтому в какой-то момент материалы, которые вы вводите или выводите, в конечном итоге будут раскрыты либо через сетевую выборку/XHR, либо через выполнение функций.
В javascript существует «частный» шаблон, который предотвращает поиск внутри объекта, где вы явно определяете методы/свойства, которые доступны:
window.myThing = (function(){ var a = "a"; var private_b = "b"; function one(){ return "one" } function private_two(){ return private_b } return { public_a : a, public_one : one } }()); for(var prop in window.myThing){ console.log(prop, window.myThing[prop]) } // ---------------------------------- // only the following properties // are exposed from the window scope: // ---------------------------------- // public_a as - a // public_one as ƒ one() Теоретически, этот тип шаблона может допускать внутренние (незащищенные/непроходимые) методы и свойства… и используйте некоторую форму шифрования для «входов и выходов».
Комментарии:
1. Правильно, никогда не думал о переменной области действия функции таким образом. Просто чтобы подтвердить мое понимание, то, что вы можете сохранить «частным», — это локально объявленные переменные внутри функций? В общем случае скрипты, вызывающие функции, могут видеть только их возвращаемые значения?
2. Верно, функции имеют изолированную область действия. (Просмотрите var let const для определения области применения.) «var» изолирован от функции { скобки}, в которой он объявлен (и дочерние функции/скобки-родители не могут «видеть» его). К вашему сведению: «пусть» аналогично по своей природе, но изолировано от скобок if/for/while/etc. Нет эффективного способа прочитать var, объявленный в функции, если функция не возвращает его значение.