* [room] Предварительная фильтрация PHP кода - как разрешить только алгоритмические команды?
@ 2006-03-03 19:10 Sergey Stepanov
0 siblings, 0 replies; only message in thread
From: Sergey Stepanov @ 2006-03-03 19:10 UTC (permalink / raw)
To: smoke-room
Здравствуйте.
Вот решил запостить вопрос и сюда, вследствии собирания
здесь большого количества пытливых умов. :)
Вопрос, не совсем обычный...
Можно ли (и если можно, то каким образом) сделать так, чтобы
на сайте, который крутится на PHP, существовал раздел, который бы
позволял любому пользователю добавлять PHP-код и сразу _выполнять_ его.
Причем от языка PHP нужно разрешить только "алгоритмическую" часть,
то есть разрешить в коде использовать только
- работу с переменными
- работу с массивами
- функции, определенные в текущем коде
- вывод print или echo
- (опционально) математические функции
Возможные проблеммы зацикливания чужого кода, проблеммы потенциального
создания больших массивов, можно пока не рассматривать.
Так вот сам вопрос - можно ли такую вещь как-нибудь сделать?
Как ввести нужные ограничения? Конечно, понятно, что такой раздел
на сайте - огромнейшая дыра и потенциальная угроза, причем ещо какая.
Но вот может быть всеже есть возможность сделать такую вещь
без сильного нарушения безопасности?
Из возможных путей я пока вижу несколько -
- Предварительно фильтровать PHP код на наличие недопустимых функций,
и не позволять его запускать. Список недопустимых функций будет
весьма большой, и будет зависеть от подключенных модулей...
Так что все учесть сложно...
- Проанализировать код на наличие описания функций (Это более-менее просто сделать строковыми средствами PHP). Просканировать код и
определить все места вызова функций (кстати, как правильно это сделать?).
Если вызывается неописанная функция, не разрешать код к запуску...
- Комплексный подход средствами UNIX и PHP. Выделить директорию,
выход из которой для php скриптов невозможен (это вообще реально
сделать?). Назначить права для предотвращения записи внутри
директории с такими скриптами. Это ограничит файловые функции скриптов
пользователей. Обрезать опции по самые яйца в php.ini (а что там можно
реально обрезать в php.ini?).
(Дополнительные условия - все должно работать на обычном UNIX хостинге,
без экзотических конфигураций.. То есть, иметь два транслятора php
или два файла php.ini - для обыной части сайта и для "защищенной" - ни
один админ не будет с этим ковыряться.)
У кого есть какие соображения по этому поводу?
В каком направлении копать?
Со всяческими пожеланиями, Сергей.
http://xi.net.ru
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2006-03-03 19:10 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-03 19:10 [room] Предварительная фильтрация PHP кода - как разрешить только алгоритмические команды? Sergey Stepanov
Культурный офтопик
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/smoke-room/0 smoke-room/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 smoke-room smoke-room/ http://lore.altlinux.org/smoke-room \
smoke-room@lists.altlinux.org smoke-room@lists.altlinux.ru smoke-room@lists.altlinux.com smoke-room@altlinux.ru smoke-room@altlinux.org smoke-room@altlinux.com
public-inbox-index smoke-room
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.smoke-room
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git