1
Я работаю над типом приложения для игровой площадки кода, где пользователь (веб-разработчик/дизайнер) может вводить HTML, CSS и Javascript и просматривать результат на iframe. Введенный код будет сохранен в базе данных (MySQL) и отображен обратно в iframe в представлении show_results/action.Безопасно ли сохранять созданный пользователем javascript в базе данных?
Теперь вопрос: безопасно ли сохранять javascripts непосредственно в базе данных? Если нет, то где/как его сохранить?
Безопасно хранить JS в любой базе данных. Риск возникает, когда вы извлекаете эту JS и отображаете ее на странице как '
База данных не будет вашей проблемой здесь. Достаточно тривиально использовать подготовленные операторы, позволяющие безопасно хранить все типы символов в базе данных. Использование чего-либо, кроме подготовленных инструкций для хранения пользовательских вводных данных, недостаточно и по существу никогда не рекомендуется.
Но вы говорите о разрешении произвольного javascript, который всегда будет проблемой безопасности. Как следует из комментариев выше, вы собираетесь копировать сложности jsfiddle.net без опыта безопасности, ноу-хау разработки или выразить желание исправлять уязвимости, которые будут продолжать возникать.
Конечно, вы должны знать, что то, что вы делаете, полностью скомпрометирует любой домен, на который вы его настроили, так что, по существу, этот javascript должен быть написан только в отбрасываемом домене или поддомене, который вы не используете для любых других целей. Конечно, в такой среде будет тривиальным, чтобы просто создать кадр и вытащить зрителя с сайта, на котором размещается кадр.
Я уверен, что это просто поцарапает поверхность потенциальных злоупотреблений, приведя с собой произвольное выполнение javascript (например, самонастраивающееся межсайтовый скриптинг).
Поскольку вы принципиально изобретаете очень опасное колесо с этой концепцией, почему бы просто не использовать некоторые из служб внедрения, которые уже существуют там? Например, codepen.io позволяет вставлять свои фрагменты.
источник
2014-09-19 18:57:06 Kzqai
Я создаю приложение, которое использует положения технологии за «программным обеспечением для игровых площадок» для совершенно другой цели. Codepen и CSSdeck потрясающие, я согласен с вами. Я готов пройти через уловы потенциальных атак XSS, исправить их и продолжать учиться у него в моем проекте. Было бы замечательно, если бы вы могли предложить мне написать взломы, лучшие практики и места для начала/ссылки? Заранее спасибо! – marvindanig
Ну, о чем вы говорите (помимо сохранения аспекта, который не является чрезмерно сложным после использования подготовленных операторов), все клиентские стороны, поэтому просто скопируйте jsfiddle или codepen или cssdeck, в зависимости от того, что ближе всего к тому, что вы на самом деле хотите, и уточнить оттуда. Просто не забудьте изучить его заголовки серверов и попытаться воспроизвести те, которые кажутся необходимыми, а также хорошо. Удачи. – Kzqai
Да, это безопасно как архитектурное решение, если вы выполняете javascript на стороне клиента.
На любом сайте вы можете использовать такие инструменты, как «элемент проверки» хром, чтобы манипулировать html, javascript и т. Д. На клиенте. Ваша система не может предположить, что элементы на клиенте не обрабатываются. Вот почему проверка на стороне сервера по-прежнему так важна.
Я полностью не согласен с kzqai. Если бы это было так, то у скрипача были бы серьезные проблемы.
Существуют потенциальные проблемы, которые могут быть легко выявлены с помощью того, что вы делаете, но эти проблемы уже существуют и просто неясны.
IFF Вы выполняете javascript на стороне сервера, это очень сложное решение. Я бы лично избегал его, если это возможно, потому что игра, в которую вы играете, состоит в том, что вы можете поймать каждый возможный сценарий для неприятностей против плохого парня, способного поймать 1, которого вы не сделали.
источник
2014-09-19 19:43:50 vereecjw
Вы, по сути, говорите, что очень осторожны с исполнением javascript на стороне сервера, потому что это очень сложное решение, но потом говорят, что выполнение его на стороне клиента - это просто отлично, а не проблема. Единственное различие заключается в том, кто стоит болеть. Серверная сторона - это ваш сервер, клиентская сторона - это ваши пользователи. Если вы считаете, что jsfiddle - это то, что разработчики могли бы просто «установить и забыть» без необходимости постоянно исправлять новые возможности атаки только потому, что это клиентская сторона, ну, вы просто не знаете о постоянном заграждении новых клиентских эксплойтов. – Kzqai
Это совсем не так. Я согласен, что javascript на стороне клиента может вызвать проблемы. Однако вы никогда не сможете доверять javascript любого типа в веб-среде, которая не должна выполняться на стороне клиента. На самом деле вы должны принять обратное. Например, скажем, новая угроза появится в будущем. Угроза эксплуатация со следующим яваскриптом кодом на стороне клиента: функции beBad() { .. } Вы не можете сказать: «Ну у нас все хорошо, потому что у нас нет этого кода». Вместо этого вы должны сказать и действовать по факту, что ЭТО БУДЕТ выполнено. Поэтому вам необходимо правильно справиться с этой угрозой. – vereecjw
Эта логика, позволяющая произвольному javascript хранить в db и выполняться на клиенте сама по себе не представляет угрозы безопасности. Более конкретным примером может служить: Предположим, что имеются данные IFF, у вас есть маркер безопасности. У каждого пользователя есть свой токен. Доступ к javascript, доступный для вас, разрешен для доступа другими пользователями. Данные, которые токен разрешает доступ, считаются конфиденциальными (позволяет просто указывать идентификационную информацию) Разрешение доступа к этому токену на javascript очевидно смертельно, поскольку они могут легко захватывать и передавать токен, предоставляя таким образом доступ. – vereecjw