Сделать язык программирования для вашего веб-приложения на JS, который компилируется в JS с PHP, чтобы обеспечить тщательную фильтрацию загруженных пользователем анимаций html5 canvas?

Question

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

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

Если я позволю одному полю формы textarea выступать в качестве IDE, использующего JS для моего языка программирования, написанного на JS, и выполняю замену строк, фильтрацию и проверку синтаксиса пользователя перед окончательной компиляцией его в JS, который будет отображаться PHP насколько плохо это может быть для меня, чтобы разместить этот контент? Пожалуйста, покажите мне, как вы могли бы обойти все мои объединенные соображения, с учетом также и серверной стороны:

• Если JavaScript отключен, предотвращая прохождение любого POST, постоянно отслеживая сеанс пользователя.
• Пространство имен класса, так что они могут только префикс своих функций и методов с EXAMPLE.
• Создание экземпляра
• Хранение моей JS Framework во внешнем (неизменяемом в браузере?) Файле JS, который должен быть вверху страницы для отдельного поля textarea в принимаемой форме, а также сгенерированного сервером ключа. который должен следовать за этим. На странице, на которой размещена скомпилированная пользователем загруженная пользователем игра / анимация (только по 1 на страницу), сервер проверит правильную строку имени файла JS, а затем выведет на экран все остальное.
• Нет вызовов внешних скриптов! Замена строки на клиенте и сервере.
• Допускаются ТОЛЬКО буквенно-цифровые символы, тире и звездочки.
• Удаление оповещений, eval, окон, XMLHttpRequest, прототипов, cookie, очевидных вещей. Нет собственных зарезервированных слов или синтаксиса JS.
• Запутывает и минимизирует другой внешний JS-файл, который помогает обслуживать IDE и распознавать методы API Canvas с уникальным названием языка программирования.
• Когда окно выгружается, сохраните внешний JS-код в двух динамически сгенерированных полях формы, которые будут проверяться сервером в POST. Весь исходный код будет тщательно каталогизирован в БД для целей фильтрации.
• Строгие соглашения о присвоении имен переменных ('example-square1-length PROPERTY ', 'example-circle-spin METHOD ')
• Copy / Paste Disabled, setInterval постоянно проверять, включен ли пользователь. Если это так, то инициируйте блок в базе данных, немедленно измените window.location и проверьте идентификатор сеанса через POST, чтобы подтвердить, если JS станет отключенным в этот период времени.

Я имею в виду, могу ли я сделать это тогда? Как можно навредить, если они не могут использовать HEX или ASCII и тому подобное?

Answer 1

htmlprufier состоит из тысяч регулярных выражений, которые пытаются "очистить" html в безопасное подмножество, неуязвимое для xss. Этот проект обходится очень мало месяцев, потому что он недостаточно сложен для решения проблемы XSS.

Вы понимаете сложность XSS?

Знаете ли вы, что javascript может существовать без букв или цифр ?

Ладно, самое первое, что я бы попробовал, это вставить метатег, который изменяет кодировку на незнакомую, скажем, UTF-7, которая отображается в IE. В этом HTML-кодировке utf-7 он будет содержать javascript. Вы думали об этом? Угадайте, что есть где-то между сотнями тысяч и несколькими миллионами других векторов, о которых я не думал.

Шпаргалка XSS так стара, что мои дедушка и бабушка невосприимчивы к ней. Вот более свежая версия .

(Да, кстати, вы будете взломаны, потому что то, что вы пытаетесь сделать, в принципе небезопасно.)

Answer 2

Я думаю, что есть несколько других вариантов.

Между прочим, хорошими местами для реальных тестов XSS являются Шпаргалка XSS и HTML5 Security Cheetsheet (новее). Однако проблема в том, что вы хотите разрешить Javascript, но запретить bad Javascript. Это другая и более сложная цель, чем обычный способ предотвращения XSS путем предотвращения всех сценариев.

Хостинг в отдельном домене

Я видел, что это называется "тюрьма Ифраме".

Цель атак XSS - иметь возможность запускать код в том же контексте, что и ваш сайт, то есть в одном домене. Это связано с тем, что код сможет считывать и устанавливать файлы cookie для этого домена, инициировать действия пользователя или исправлять ваш дизайн, перенаправлять и т. Д.

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

Конечно, он может устанавливать куки, сколько ему угодно, и даже читать те, которые он установил. Но они все равно будут изолированы от файлов cookie для вашего сайта. Он не сможет повлиять на файлы cookie вашего основного сайта или прочитать их. Он также может включать в себя другой код, который может раздражать / раздражать пользователя, например всплывающие окна, или может пытаться фишинг (вам нужно визуально прояснить в пользовательском интерфейсе вне фрейма, что обслуживаемый контент не является часть вашего сайта). Тем не менее, это все еще песочница с вашего основного сайта, где у вас есть личная полезная нагрузка - ваши сеансовые куки и целостность вашего всеобъемлющего дизайна страницы и сценариев, сохраняются. Это несёт не меньший, но не больший риск, чем любой сайт в Интернете, который вы можете встроить в iframe.

Использование подмножества Javascript

Были предложены подмножества Javascript, которые обеспечивают разделение сценариев - возможность загружать ненадежный код и не иметь возможности изменять или получать доступ к другому коду, если вы не предоставляете ему возможности для этого.

Посмотрите на такие вещи, как Google CAJA - цель которого - включить именно тот тип сервиса, который вы описали:

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

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