Как javascript (или расширение браузера) может обнаружить использование ограниченных функций?

Question

Я разрабатываю расширение для сценариев, похожее на Greasemonkey или Chrome Content-Engine. Это расширение позволит авторам сценариев делать очень опасные вещи, такие как доступ к локальным файлам.

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

Например, расширение может искать защищенную строку GM_openSQL_Connection и предупреждать пользователя - может быть так:

Предположим, что базовая веб-страница никогда не сможет получить доступ к GM_openSQL_Connection благодаря механизмам песочницы. Аналогично, никакой узел <script> не сможет.

Но автор сценария все еще может обойти простой поиск сверху с помощью чего-то вроде:

eval (decodeURI ("GM_op%65nSQL_Connection (...);") )

Таким образом, вопрос заключается в том, , каким образом злой сценарист может обмануть проверку на ограниченное использование функций , и как я могу предотвратить такое зло?

---

Примечание: ложные предупреждения могут быть в порядке. Например, если автор сценария использует текст «GM_openSQL_Connection» в статической строке, в противном случае ему просто придется мириться с (ложным) предупреждением.

Answer 1

Как злой сценарист может обмануть проверку ограниченных функций us [age]?

Существуют тысячи комбинаций, например, с eval(), new Function(), комбинациями String.fromCharCode() и decodeURI() (как в вашем примере).

Как я могу предотвратить такое зло?

Не могли бы вы перегрузить / затенить специфические плохие функции / объекты / переменные?

GM_openSQL_Connection = function() {
   warnUser();
};

Чтобы установить флаг, если расширение пытается получить доступ к запрещенной функции или переменной, просто укажите var isDangerous = false, установленное на true, если вызывается запрещенная функция, или get / set на запрещенном объекте доступен / изменен.

Если isDangerous равен true, то вы можете пометить это расширение как потенциально опасное для функций / свойств, вызывающих / обращающихся к ним.

Answer 2

Попытка отсканировать скрипт, чтобы определить, использует ли он какой-либо из этих интерфейсов, - неправильный подход. Слишком легко избежать путаницы, как вы, кажется, открываете. Это в основном небезопасно: нет способа заставить его работать.

Вот лучший подход. Требуйте, чтобы автор сценария включил манифест, который объявляет, к каким специальным API ему нужен доступ. Затем запустите сценарий в безопасной изолированной программной среде Javascript, которая предоставляет только те разрешенные API и API, которые были запрошены, но не более того. Если сценарий не запрашивает GM_openSQL_Connection в своем манифесте, не предоставляйте этот API сценарию.

Поскольку Javascript - это динамический язык, который допускает внесение исправлений обезьянами и неограниченный доступ к глобальному объекту, для создания защищенной изолированной программной среды, ограничивающей доступ к API-интерфейсам сценария, требуются некоторые действия. Поэтому я рекомендую вам использовать существующее решение для песочницы. Один из подходов состоит в том, чтобы запустить пользовательский сценарий в изолированной программной среде и предоставить изолированному программному коду библиотеку, заполненную заглушками для чувствительных API-интерфейсов, где заглушки просто используют postMessage для отправки RPC-запроса вашему коду расширения. Это позволяет избежать наличия ссылок, которые пересекают границу песочницы, что хорошо (в зависимости от технологии песочницы), когда ссылки такого типа обычно несут существенный потенциал для уязвимостей безопасности.

Затем вы можете отправлять предупреждения пользователей на основе содержимого манифеста. Важно: пожалуйста, подумайте об этом с точки зрения пользователя. Смогут ли обычные пользователи разобраться в предупреждениях? Смогут ли они принимать разумные решения? Будут ли пользователи лучше принимать правильные решения, чем вы? Будут ли пользователи перегружены постоянными предупреждениями, и они просто начнут игнорировать их и нажимать «ок» (эффект крика-волка)?

Для получения информации о технологии песочницы Javascript, пожалуйста, прочитайте следующий вопрос по IT-безопасности: Как сканировать Javascript на наличие вредоносного кода? . В будущем вы можете получить ответы на этот вопрос на сайте IT Security.