Я использую create_function для запуска некоторого кода пользователя на сервере. Я ищу любой из этих двух:
Благодаря!
Вы можете использовать тонкенизатор, чтобы выяснить, что будет делать код, а затем белый список определенных функций и операций. Я думаю, что в конечном итоге это будет очень сложно (или невозможно) сделать его надежным, особенно с учетом гибкости PHP:
$f = "shell_exec"; $arg = 'rm -rf /'; $f($arg); // ouch call_user_func($f, $arg); // ouch eval("$f('$arg');"); // ouch $newF = create_user_function('', "$f('$arg');"); $newF(); // ouch Единственная песочница, которая даст вам 100% -ную защиту (ну, 99,9% …) – это виртуальная машина, которую вы можете просто выбросить.
Мы используем токенизатор для анализа кода статически, а также для изменения кода для выполнения проверок времени выполнения для определенных вещей. Это делается с помощью токенизатора и скриптов, основанных на токенизаторе. Поскольку токенизатор тот же, что использует PHP, он улучшает вашу удачу по написанию собственного.
Я видел людей, использующих регулярные выражения, чтобы попытаться проанализировать язык. Это действительно плохая идея.
Но …
Поскольку PHP – довольно глупо-простая грамматика, и у вас есть доступ к токенизатору, вы можете фактически остановить большую часть неудачи, отказавшись от переменных функций и разрешив только небольшое количество белых функций. Если вам не нужен ООП, еще лучше.
Тем не менее, мы не чувствуем себя достаточно уверенно, что мы прибиваем 100% проблем, и мы используем это для питания песочницы для бэкэнд- пользователей, которые платят клиентам, а не каждому пользователю на планете Земля с клавиатурой и, возможно, злой.
Я тоже думаю, что люди здесь, которые poo-poo идею 100%, как «плохая практика», должны понять. Есть основания для этого.
Вы не можете надежно дезинфицировать ввод пользователя – определенный хакер найдет какой-то неясный способ обойти ваш код санитарии.
Песочница может быть возможна, но в равной степени вредна. Если вы действительно хотите быть в безопасности, вы должны создать песочницу для каждого вызова. В конце концов, кто-то может выполнить фальшивый код, который вреден для всех других пользователей вашей песочницы.
Я не думаю, что вы действительно этого хотите. Подумайте об этом так: вы предоставляете программный доступ к серверу!
Вы можете попробовать использовать Quercus, основанный на Java PHP-интерпретатор, для создания безопасной изолированной среды PHP. Вы можете сделать то же самое для JavaScript с помощью Rhino, поэтому я думаю, что это возможно с Quercus.
Вы можете подумать о создании пользовательского (ized) языка, который могут использовать ваши пользователи. Тогда вам решать создать библиотеку поддерживаемых функций, которые вполне могут быть просто оболочками собственных функций PHP. Но даже тогда, делая его взломанным или просто работающим, в лучшем случае это утомительная работа. Возможно, вам следует переоценить, почему вы хотите, чтобы пользователи имели доступ к коду в первую очередь? Я бы хотел помочь, если вам нужен кто-то, чтобы обсудить это с (или обновить свой вопрос, я думаю? 🙂
Надеюсь, вы сможете это исправить!
-Dave
Это класс на GitHub, который может помочь, на ранних этапах, но выглядит многообещающим.
В целом плохая идея и слишком опасная ИМО, независимо от того, какую защиту вы вводите в действие. Лучше создать псевдоязык, ограниченный только тем, что пользователям разрешено делать.