Изоляция в PHP?

Я кое-что об этом подумал.
Я создаю приложение, в котором мои пользователи будут загружать собственные пользовательские темы, а это значит, что у всех, у кого есть базовые навыки PHP / XSS, есть хорошая возможность вызвать много головной боли.

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

Будет ли это хорошей практикой и как это будет сделано?

Чтобы безопасно использовать произвольный html / javascript, каждый пользователь должен иметь свой собственный поддомен. Если каждый пользователь имеет свой собственный поддомен, тогда JavaScript-скрипт пользователя будет ограничен собственной песочницей из-за той же политики происхождения . Если вы хотите только «безопасный html», то htmlpurifer является опцией, а затем вы можете использовать 1 домен.

Разрешение пользовательского PHP немного опаснее. Поставщики «общего хостинга» полагаются на suPHP, который заставляет скрипт php запускаться как конкретный пользователь. Это потребует от каждого пользователя собственной учетной записи в вашей системе. Этот метод защиты существует некоторое время. Это не идеально, но это делает трюк.

Еще одно возможное решение для настраиваемых тем – использовать механизм шаблонов, который может препятствовать тому, чтобы шаблоны получали полный доступ к PHP. SOM популярные рамки для этого:

  1. smarty , у него нет лучшей послужной записи secuirty, но вы постоянно ее обновляете, у вас, вероятно, не будет проблемы. Он должен быть настроен для запрета нативного php .
  2. twig – относительно новый движок от разработчиков Symfony Framework. Это означает, что у него приличная база для разработчиков, и поскольку она поставляется с Symfony, она также тестировалась в дикой природе. Twig не позволяет вызывать любые функции PHP, если только вы специально не создаете для них функцию ветвления / фильтр.

Поскольку вы не хотите предоставлять своим пользователям доступ к PHP, вы должны использовать механизм шаблонов, который поддерживает песочницу. Характерным примером здесь является Twig .

глобальный охват всегда будет доступен.

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

но выполнение неподтвержденного стороннего кода – сложная вещь. Я бы порекомендовал здесь какую-то изоляцию процесса. что означает, что вы открываете процесс, используя popen или что-то еще, в сочетании с suphp вы можете сделать ограниченного пользователя linux. это очень хорошо и безопасно с соблюдением правильных мер безопасности.

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

когда дело доходит до html-кода, это проще. есть хороший html tidy – хорошее начало. есть хорошие решения, позволяющие использовать только специальные теги.

javascript может быть «защищен» так, как это делали старые приложения facebook fbml. который включает перезаписывание на стороне сервера, имена динамических переменных и т. д. его довольно сложно.

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

edit: конечно, вы можете анализировать любой код и ограничивать его определенными утверждениями или отрицать определенные утверждения, но это очень сложно, а для php очень тяжелое ограничение. его, вероятно, лучше перейти на некоторые алгоритмические языки более высокого уровня или перейти на клиентскую сторону с javascript.

То, что вы хотите сделать, действительно рискованно. Вы никогда не должны позволять своим пользователям загружать файлы PHP. Вот почему вы не найдете много PHP-скрипачей вокруг сети (хотя теперь есть некоторые).

Также JS опасен некоторыми косвенными способами, и почти никто не позволяет его загрузить (за исключением Tumblr).

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

Поскольку проблема безопасности – проблема, попробуйте проверить рекомендации безопасности, такие как Secunia, при выборе механизма шаблонов.