Риски, связанные с разрешением пользователям загружать файлы HTML / JS

Мы разрабатываем онлайн-аттракционы для игр HTML5. Пользователи могут загрузить zip-файл, содержащий их игру.

При загрузке zip распаковывается сервером, и каждый файл зацикливается, проверяя его расширение по белому списку, что позволяет:

  • .html
  • .js
  • .png
  • .jpg
  • .appcache
  • .m4a
  • .ogg

(Игры должны быть созданы в нашем игровом редакторе, который экспортирует эти файлы). Это должно помешать людям загружать zip-файлы, файлы сценариев на стороне сервера и т. Д.

Затем игры перемещаются на наш статический домен без файлов cookie (scirra.net). Когда игра запускается на нашей странице scirra.com, игра отображается в окне iframe, указывающем на домен scirra.net. Это должно предотвратить доступ вредоносного JS к cookie-файлам scirra.com.

Достаточно ли всеобъемлющи эта техника iframe и белый список, чтобы предотвратить любые злонамеренные действия? Обратите внимание, что мы не можем проверить каждый файл JS, поэтому следует предположить, что люди попытаются загрузить вредоносный JS.


javascript iframe security whitelist
person Tom Gullen    schedule 22.11.2011    source источник
comment
Я знаю, что это может вызвать некоторые неприятности, но вам нужен процесс утверждения, похожий на яблоко.   -  person Daniel A. White    schedule 22.11.2011
comment
Я думаю, это также зависит от того, какой тип безопасности вас интересует. Заинтересованы ли вы исключительно в защите своих серверов или вы также заинтересованы в том, чтобы не размещать вредоносный код для своих игроков. Если вы рассматриваете оба случая, вам, возможно, придется немного поработать, чтобы убедиться, что пользователь не создает (даже в вашем редакторе) какой-то хитрый JavaScript, который может использовать игрока.   -  person RLH    schedule 22.11.2011
comment
@ Дэниел, для нас это просто нереально. У нас есть большая аудитория людей, которые хотели бы использовать это и хотели бы изолировать каждую игру в песочнице, чтобы она была безопасной. Мне просто интересно, может ли JS, запущенный во фрейме в другом домене, нанести какой-либо ущерб.   -  person Tom Gullen    schedule 22.11.2011
comment
@RLH какой JS может эксплуатировать игрока? Мы заинтересованы в обоих.   -  person Tom Gullen    schedule 22.11.2011
comment
@Tom: window.location = http://somevirusinfestedsite.com для начала. while (true) alert('haha'); (и это варианты) воткнуть еще одну.   -  person Matt    schedule 22.11.2011
comment
@Matt Я думаю, что браузеры с поддержкой HTML5 обычно обрабатывают повторяющиеся предупреждения. Хорошо, я не думаю, что мне нужно о них беспокоиться. Window.location хорош, хотя подумаю об этом. В основном меня беспокоит возможность взаимодействия iframe с родительским окном.   -  person Tom Gullen    schedule 22.11.2011
comment
@TomGullen: У тебя также есть window.top.location = http://somevirusinfestedsite.com   -  person Matt    schedule 22.11.2011
comment
См. Сообщение Мэтта. Честно говоря, я самый увлеченный разработчик JS / HTML5 с ограниченными знаниями в этой области. Тем не менее, я стараюсь быть в курсе различных эксплойтов, которые используются как осведомленный пользователь этих технологий. Подвиг Мэтта, наверное, самый реалистичный. Поиска windows.location в файлах JS или HTML было бы недостаточно. Разработчик может хэшировать строку JS, которая будет делать что-то подобное, разблокировать ее на компьютере пользователя, а затем передать ее вызову Eval (). Запускайте каждую игру в песочнице и проверяйте их на людях. Если у вас не большой сайт, это не должно быть необоснованным.   -  person RLH    schedule 22.11.2011

Ответы (3)


arrow_upward
4
arrow_downward

правила наследования источника для iframe не позволяют iframe scirra.net вмешательство в scirra.com.

Однако это не предотвращает все атаки. По сути, вы вводите сохраненную уязвимость XSS. XSS может использоваться для внедрения атак на основе браузера, таких как использование переполнения буфера в компонентах ActiveX. Использование файлов в Flash, Adobe reader или Microsoft Office.

Вам следует подумать о запуске антивируса для содержимого scirra.net. Хотя это не предотвратит все атаки. Страница с ifram может перенаправлять или вводить другой iframe, содержащий вредоносный контент.

Как указал Чиксофт. Приложения смогут влиять друг на друга с помощью XSS. Вредоносное приложение может получить доступ к другому приложению автономному хранилищу или получить другие встроенные данные в другом приложении. Принуждение каждого приложения к поддомену смягчит эту проблему. Вы можете настроить DNS-запись, чтобы указать * .scirra.net на ваш сервер и позаботиться о доменном имени в вашем веб-приложении.

person rook    schedule 22.11.2011
comment
И если вы размещаете все отправленные приложения в одном домене, возможно, вы перестали сохранять (и отражать) xss в своем собственном домене, но одно вредоносное приложение может выполнять xss-атаки против всех других приложений. Обслуживайте каждое из их собственного динамически генерируемого доменного имени и пытайтесь убедить разработчиков всегда устанавливать свои файлы cookie на myapp.scirra.net и никогда не устанавливать только scirra.net. - person Cheekysoft; 22.11.2011
comment
@Cheekysoft, да, это хороший момент. Я не думал об этом векторе, возможно, ценная информация хранится в других приложениях или в автономных системах хранения js. - person rook; 22.11.2011

arrow_upward
1
arrow_downward

Как насчет включения некоторых функций скрининга в редактор игры, который вы предоставляете? Отфильтровывайте ссылки на внешние URL-адреса, выполняйте проверку кода, проверяйте кодировку и т. Д.

Вам придется заблокировать zip-файл, чтобы предотвратить подделку, но в любом случае это может быть хорошей идеей.

person schroeder    schedule 22.11.2011

arrow_upward
0
arrow_downward

Для всех, кто это читает, есть атрибут тестовой среды iFrame экспериментальный / бета:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

Обратите внимание, что в настоящее время он работает только в Chrome и Opera. Это позволяет вам указать некоторые ограничивающие функции.

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

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

person Tom Gullen    schedule 22.11.2011