KarleKremen
@KarleKremen
Игнорирую Bootstrap

Модульный фреймворк на PHP, как защитить?

Вопрос уже поднимался мной же, но тогда никто не дал мне ответа, который мне бы помог. Разрабатывается фреймворк для корпоративных интранетов, для большей гибкости и удобства разработки решено использовать модульную схему: есть ядро, состоящее из библиотек, и модули, подключаемые к этому ядру и использующее библиотеки для взаимодействия с базой данных, конфигурацией и проч. Стоит вопрос, как запретить модулю напрямую обращаться к БД, читать файлы и выполнять прочие потенциально опасные действия. Например, модуль может использовать для обращения к БД написанную библиотеку-обертку, но не может использовать напрямую MySQLi или PDO.

Был вариант использовать Suhosin и eval, но он не подходит по двум причинам:
  • Фреймворк становится тяжело переносимым, то есть для его работы нужно как минимум собирать и устанавливать Suhosin. Получаем фреймворк, работающий только на VPS/VDS.
  • Для передачи данных модулю нужно ставить дичайшие костыли типа манифестирования параметров функции для того, чтобы можно было получить нужные данные в эти параметры (блин, даже описать нормально не получается).


Есть ли вообще решение этой проблемы?
  • Вопрос задан
  • 501 просмотр
Решения вопроса 1
KarleKremen
@KarleKremen Автор вопроса
Игнорирую Bootstrap
Ответ от Алексей Ярков: Я честно говоря плохо представляю как можно запретить писать в коде модуля mysqli_query ))) Кстати, а кто писать модули будет? Я лично в PHP плохо шарю, но вижу один выход - модуль сначала проверяется компетентными людьми на наличие запрещенных функций, а только потом может быть использован. Но это при условии, что модули будет писать ограниченный круг разработчиков, а не любой желающий.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 5
Denormalization
@Denormalization
Данный пост напомнил мне местного кулибина, который тоже делал свой супер фреймворк со всякими безумными идеями а-ля "запретить модулям использовать PDO" и "Я использую eval, я дурачек".

Решение может и есть, но есть ли в нем смысл? Зачем запрещать что-то модулям? Тем кому надо, все равно обойдут запреты, а логику подобные запреты усложнят в разы.

Лучше придумайте нормальный интерфейс для общения с ядром, чтобы это было удобно, вместо того чтобы заниматься ерундой.
Ответ написан
usdglander
@usdglander Куратор тега PHP
Yipee-ki-yay
Я так понимаю что модуль знает логин и пароль для доступа к БД?
Ответ написан
trevoga_su
@trevoga_su
Проект рассчитывается на то, чтобы модули к нему писались не только моими руками, но и другими пользователями.
Например, модуль может использовать для обращения к БД написанную библиотеку-обертку, но не может использовать напрямую MySQLi или PDO.

Другие пользователи - это кто? Кухарки? Или программисты? Если второе, то в чем проблема написать документацию и четко объяснить клиентам, как пользоваться системой?

читать файлы и выполнять прочие потенциально опасные действия
Смысл тогда в этом фреймворке? Зачем он? Тут под условие подходит CMS, а не фреймворк.

PS код в студию, аж интересно стало,что это за чудо фреймворк такой.
Ответ написан
PretorDH
@PretorDH
HTML5, CSS3, PHP, JS - люблю в чистом виде.
Ты не стой стороны лезеш. Сделай отдельный сервер-сервис(котором управляют только ты и может быть доверенные) закрытый от других модулей, и отвечает на их ПРАВИЛЬНЫЕ-запросы, файлами или данными. Все неправильные запросы идут лесом. И все все твои проблемы отпали.
Ответ написан
Комментировать
API сделайте и все остальные модули общаются с ядром только через API куча проблем сразу решится и доступ к базе и безопасность и гибкость, о eval забудете как в страшном сне
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы