Ну вот на западе люди понимают проблему eval, функу которую стоит вообще убрать чтобы повысить безопасность клиентского кода. Со временем так и будет.
Why restrict eval() for all Application content if there are legitimate use cases for using it?
eval() and its equivalents are being restricted in the Application sandbox because the common patterns where eval() is used are also the same patterns that represent the highest risk (i.e. cross-domain JSON, eval() for dynamic generation of code containing inline data from 3rd parties). There is no reliable way to determine when some data is safe to eval(), and when it is not.
Да нет никакого итерпретатора. Вы хоть их писали? Я писал с нуля на С++ для С++ like script. А здесь предлагается решение из врапперов оберточных функций), где нативные методы оборачиваются функциями в которых фильтруется входная информация).
В теории это все решается (в вашем случае фильтруется function и нативный параметр construct).
Но вот это все равно не виртуальная машина. Где в этом подходе вы видите семантический анализ и последующее исполнение P-кода на виртуальной машине (допустим стековой архитектуры) это ничего не было заявлено предлагались только фильтры.
Очень просто. Было сказано что переопределаются объекты и функции, а темболее такие как eval и оператор new. В нашем случае после прохода фильтром мы имеем:
(New(y(a + b + c + d)))(), где New занимается созданием любых новых объектов в платформе, так эта часть y(a + b + c + d) у нас сформириуется во время выполнения, платформа перехватит аргумент поступивший в функцию New, далее этот же аргумент в виде текста проходит фильтр и создается уже объект, в нашем же случае можно сразу пометить такой код как вредоносный и не продолжать работу, так как для разработчиков будут предусмотрены объекты платформы (HWindow, HDocument и т.д.) имеющие тотже интерфейс что и нативные объекты, то если кто то пишет window.alert('Hack') игнорируя предусмотренные объекты, то у него явно нехорошие намерения.
Какая виртуальная машина? Вы о чем? Платформа предоставляет эти объекты HDocument, HWindow и т.д. Никакой виртуальной машины совершенно. И скрипт работает с этими объектами вот и все. А так как преобразование идет на стадии когда Script еще является текстом и только после преобразование уходит на конструктор Function, то вероятность взлома >>сильно уменьшается.
> Еще раз - речь идет о запрете доступа к глобальным объектам браузера из произвольного скрипта, подключаемого на странице.
В моей статье речь о запрете доступа к глобальным объектам браузера не идет! Читайте внимательней.
> приведите работающий пример защиты. Хорошо?
На создание полноценного secure модуля уйдет не один месяц. Для этого на стороне сервера делается ФИЛЬТР который прогоняет JS код и делает замены (было так: document.getElementById("id"), стало так: HDocument.getElementById("id"), где HDocument отностится к пространству ядра и позволяет брать только те элементы которые были созданы в КОНТЕКСТЕ АППЛЕТА, не разрешает брать чужие элементы. И т.д. так по всем объектам. Сложность состоит в том чтобы предусмотреть множество вариантов входных данных которые могут получить доступ как к глобальным объектам браузера, так и к объектам платформы.
РАБОЧИЙ пример не будет пока не будет готово то что необхдимо защищать. А если таке интересно возможноли это или нет посмотрите как сделан iGoogle (с его сотнями гаджетов от стронних разработчиков там наверное вообще одни дыры получается?), или пример Facebook platform, когда на страницу можно ставить приложения разработанные 3-ми лицами, которые также могут innerHTML заюзать и таскать конфиденцильную инфу. Но нет эти вопросы решены, скачайте Facebook platform и посмотрите как: http://developers.facebook.com/fbopen/
eval вообще нужно запретить, время уже играет не в пользу этой функции, от нее отказываются разработчики, второе вопросы безопасности клиентского кода станут острее когда количество платформ для разработки приложений увеличится и они будут занимать значительную часть инета. А eval мое мнение это серьезная брешь в безопасности клиентского кода.
Вот это офигенная идея. Единственно конечно нужно просчитать хеши для критичных к безопасности функций заранее и важно придумать где хранить хеши чтобы не было подмены. Самый простой вариант хранить хеши в базе и периодически обновлять на клиенте в фоновом режиме.
Ну во-первых класс Applet не занимается защитой. Это класс описывающий структуру приложения созданного сторонними разработчиками. Используется для присоединения к среде в которой будет работать. Класс Thread также не занимается защитой. Его цель создавать одно или несколько пространств для выполнения кода. Пример использования - есть апплет карты и вам нужно в информаторе на карте вывести миникарту, делается второй поток и юзаются теже, загруженные скрипты.
Во-вторых коду можно запретить обращаться к глобальным объектам браузера ;)
Смысл в том что бы в какой то степени обезопасить. Меньше лазеек лучше, чем много лазеек. Темболее что инфраструктура для разработки и развертывания веб-приложений не просто в веб переносится, а в платформы обеспечивающие их функционирование и взаимодействие. И вопросы безопасноти становятся актуальными.
В глобальном смысле безопасности достигнуть нереально. Но всегда можно уменьшить количество лазеек, например, не все предложили решение доступа к ядру: eval('alert(Core.sName);',arguments.callee.caller); В принципе это сделал только один человек, а чем меньше лазеек тем лучше.
Ирфейм вообще опасная штука. Для апплетов он вообще не нужен чтобы код разработчика его создавал. По сути проблему как с eval так и другими нативными методами и объектами браузера решается на уровне третьей проблемы о которой уже упоминал в статье. Решение будет базироваться на подмене глобальных объектов и методов в коде апплета.
Да Eval надо контроллировать, проверять на входные параметры и вызывать родной eval уже если все нормально. Например проверять на контекст, если запуск кода производится в контексте функций которые знают о ядре - останавливать запуск.
Серьезное замечание. Но чем более он защищен тем меньше вероятность появления вредоносного скрипта. Пока на ум приходит предварительная проверка кода на поиск таких конструкций, например регулярными выражениями.
http://labs.adobe.com/wiki/index.php/AIR…
Why restrict eval() for all Application content if there are legitimate use cases for using it?
eval() and its equivalents are being restricted in the Application sandbox because the common patterns where eval() is used are also the same patterns that represent the highest risk (i.e. cross-domain JSON, eval() for dynamic generation of code containing inline data from 3rd parties). There is no reliable way to determine when some data is safe to eval(), and when it is not.
Но вот это все равно не виртуальная машина. Где в этом подходе вы видите семантический анализ и последующее исполнение P-кода на виртуальной машине (допустим стековой архитектуры) это ничего не было заявлено предлагались только фильтры.
(New(y(a + b + c + d)))(), где New занимается созданием любых новых объектов в платформе, так эта часть y(a + b + c + d) у нас сформириуется во время выполнения, платформа перехватит аргумент поступивший в функцию New, далее этот же аргумент в виде текста проходит фильтр и создается уже объект, в нашем же случае можно сразу пометить такой код как вредоносный и не продолжать работу, так как для разработчиков будут предусмотрены объекты платформы (HWindow, HDocument и т.д.) имеющие тотже интерфейс что и нативные объекты, то если кто то пишет window.alert('Hack') игнорируя предусмотренные объекты, то у него явно нехорошие намерения.
В моей статье речь о запрете доступа к глобальным объектам браузера не идет! Читайте внимательней.
> приведите работающий пример защиты. Хорошо?
На создание полноценного secure модуля уйдет не один месяц. Для этого на стороне сервера делается ФИЛЬТР который прогоняет JS код и делает замены (было так: document.getElementById("id"), стало так: HDocument.getElementById("id"), где HDocument отностится к пространству ядра и позволяет брать только те элементы которые были созданы в КОНТЕКСТЕ АППЛЕТА, не разрешает брать чужие элементы. И т.д. так по всем объектам. Сложность состоит в том чтобы предусмотреть множество вариантов входных данных которые могут получить доступ как к глобальным объектам браузера, так и к объектам платформы.
Во-вторых коду можно запретить обращаться к глобальным объектам браузера ;)