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

Question

[Карл Майнхофф]

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

Был вариант использовать Suhosin и eval, но он не подходит по двум причинам:

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

Есть ли вообще решение этой проблемы?

Comments

[Алексей Ярков]

Я честно говоря плохо представляю как можно запретить писать в коде модуля mysqli_query ))) Кстати, а кто писать модули будет? Я лично в PHP плохо шарю, но вижу один выход - модуль сначала проверяется компетентными людьми на наличие запрещенных функций, а только потом может быть использован. Но это при условии, что модули будет писать ограниченный круг разработчиков, а не любой желающий.

Answer 1

[Карл Майнхофф]

Ответ от Алексей Ярков: Я честно говоря плохо представляю как можно запретить писать в коде модуля mysqli_query ))) Кстати, а кто писать модули будет? Я лично в PHP плохо шарю, но вижу один выход - модуль сначала проверяется компетентными людьми на наличие запрещенных функций, а только потом может быть использован. Но это при условии, что модули будет писать ограниченный круг разработчиков, а не любой желающий.

Answer 2

[D']

Данный пост напомнил мне местного кулибина, который тоже делал свой супер фреймворк со всякими безумными идеями а-ля "запретить модулям использовать PDO" и "Я использую eval, я дурачек".

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

Лучше придумайте нормальный интерфейс для общения с ядром, чтобы это было удобно, вместо того чтобы заниматься ерундой.

Comments

[Карл Майнхофф]

Это случайно не мой ли пост был? Нормальный интерфейс для общения с ядром придумать все же легче, чем придумать защищенный нормальный интерфейс. И кстати, насчет "все равно обойдут запреты" - не скажете, как именно?

[D']

Карл Кремень:
>Это случайно не мой ли пост был?
Нет, это был другой велосепидист. Но идеи были на столько же безумны (что-то вроде "Мой PHP фреймворк должен работать на хостингах без PHP")

>И кстати, насчет "все равно обойдут запреты" - не скажете, как именно?
Чтобы знать КАК обойти запреты, нужно знать КАК будут сделаны данные запреты. Если и есть решение по ограничению, то 99% есть и решение как обойти данное ограничение.

Answer 3

[Lander]

Я так понимаю что модуль знает логин и пароль для доступа к БД?

Comments

[Карл Майнхофф]

Тф... Да даже если он их и не знает, то узнать это при открытом доступе к файлам не составит труда. Ведь пароль придется хранить либо в PHP-файле, либо в конфиге. А проект опенсорцный, так что узнать будет несложно, где именно. И тогда file_get_contents и все, пароль уже есть. Разве не так?

[Lander]

Карл Кремень: Ну ХЗ. Тут на самом деле очень много зависит от того как этот фреймворк планируется использовать...
Как вариант - делать ядро дополнением к PHP, зашивать в него жестко параметры доступа к БД, и компилировать для каждого нового проекта. Хотя при желании, конечно и оттуда можно будет достать.

Answer 4

[trevoga_su]

Проект рассчитывается на то, чтобы модули к нему писались не только моими руками, но и другими пользователями.

Например, модуль может использовать для обращения к БД написанную библиотеку-обертку, но не может использовать напрямую MySQLi или PDO.

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

читать файлы и выполнять прочие потенциально опасные действия

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

PS код в студию, аж интересно стало,что это за чудо фреймворк такой.

Comments

[Карл Майнхофф]

Собственно говоря, это и есть CMS. Модули будут, конечно же, писать программисты. Но ведь это нек отменяет всяких кулхацкеров, у которых если они ничего не сломали, то день зря прошел. Кто мешает такому вот хацкеру написать "модуль", который залезет в БД и похерит всех пользователей? Или сменит пароль администратора в конфигах?

[D']

Карл Кремень:
>Или сменит пароль администратора в конфигах?
Яснопонятно :facepalm:

[Карл Майнхофф]

Код, говорите? Вы точно хотите ЭТО видеть? Оно же пустое как барабан.

[trevoga_su]

Карл Кремень: конечно хотим. Ща мы тебе ревью устроим))

[Карл Майнхофф]

D' Normalization: ошибся, конечно в конфигах нет никакой авторизационной информации. И тем не менее...

[Карл Майнхофф]

trevoga_su: https://bitbucket.org/kfkdevelcenter/intranet-core
Сильно не пинайте, но конструктивная критика к месту.

[D']

Карл Кремень: namespace, autoload, шаблонизаторы - не слышали?

[trevoga_su]

D' Normalization: ++++

Карл Кремень: почитай об MVC
о шаблонах

в коде набор каких-то непонятных директорий, файлов, так писали лет 10 назад
архитектуры нет, я ее не вижу
я не вижу что конкретно сделано в фреймворке
какие слои, в чем удобство?
где анонсированный слой для работы с СУБД?

[Карл Майнхофф]

trevoga_su:
О MVC я знаю сам и хочу реализовать это для модулей. Из слоев готов только libconfig. Архитектуры нет хотя бы потому, что пока почти ничего нет. Пока не решится вопрос о защите модулей, я могу писать только слои типа оберток над PDO. Ибо все остальное планируется реализовать как модули.

Answer 5

[Pretor DH]

Ты не стой стороны лезеш. Сделай отдельный сервер-сервис(котором управляют только ты и может быть доверенные) закрытый от других модулей, и отвечает на их ПРАВИЛЬНЫЕ-запросы, файлами или данными. Все неправильные запросы идут лесом. И все все твои проблемы отпали.

Answer 6

[Оптимус Пьян]

API сделайте и все остальные модули общаются с ядром только через API куча проблем сразу решится и доступ к базе и безопасность и гибкость, о eval забудете как в страшном сне

Comments

[Карл Майнхофф]

Ну хорошо. Есть API. И есть mysql_query. И есть file_get_contents. А мне нужно, чтобы: есть API и нету mysql_query, file_get_contents и прочей фигни.

[Оптимус Пьян]

Если есть API то зачем вам mysql_query и file_get_contents?