Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Как разграничить полномочия между php-скриптами
Покинул форум
Сообщений всего: 5
Дата рег-ции: Апр. 2009 Откуда: Москва, Россия
Помог: 0 раз(а)
Допустим, над проектом работает команда программистов.
Проверять код всех скриптов, которые они пишут, перед
выкладыванием на сервер - не всегда реально.
А ведь любой из них может опубликовать конфиденциальную инфу,
которая, допустим, хранится в файле access.php, вынесенном за пределы
web-сервера.
Т.е. во-первых, надо придумать, как не позволить потенциально
опасным скриптам инклюдить защищаемые файлы типа 'access.php'.
Причём эти скрипты не обязательно запускаются как самостоятельные.
Они могут быть включены в index.php, например, если скрипт реализует
какую-нибудь функцию, которая, скажем, рисует формочку: feedback_form().
Во-вторых, возникает такая задача:
Есть класс DB для связи с базой данных.
В нём есть поле $connection, а его методы инкапсулируют
SQL-запросы. Надо, чтобы другие разработчики могли
использовать его методы, но не могли делать к базе данных
произвольных запросов типа 'SELECT', т.к. в БД кое-где тоже
содержится конфиденциальная инфа.
Т.е. если какой-то сторонний программер написал для меня скрипт,
добавляющий сообщения с форума в БД, этот сторонний программер
не должен иметь возможности получить e-mail-ы всех юзеров из таблицы USERS.
Значит, надо защитить поле $connection так, чтобы его никак нельзя было выцепить,
даже с помощью var_export($db).
У кого какие соображения?
Может, есть альтернативные методы разграничения полномочий?
Ch_chov
Отправлено: 17 Апреля, 2009 - 17:40:09
Постоянный участник
Покинул форум
Сообщений всего: 2121
Дата рег-ции: Июль 2008 Откуда: из города
Помог: 90 раз(а)
Если для работы с базой используются какой либо framework, то в нем и ограничить доступ к конфеденциальным данным.
А сторонним программистам просто не сообщать имя базы, логин и пароль пользователя базы.
Такой же принцип можно реализовать и при работе с файлами.
З.Ы. Лучше все таки не работать с тем, кому не доверяешь...
valenok
Отправлено: 17 Апреля, 2009 - 19:01:15
Здесь могла бы быть ваша реклама
Покинул форум
Сообщений всего: 4574
Дата рег-ции: Июль 2006 Откуда: Israel
Помог: 3 раз(а)
касаемо первого можно просто разрешить инклудить класс db..
в котором уже произошло подключение к бд. А после подключения удалились твои переменные.
Касаемо второго, тут уже получится фактически свой фреймворк..
Создаешь такого рода файл с правами. Дал задание написать форму фидбэка
пусть называет файл определенным именем именем или прописывает какую нибудь переменную-ключ идентифицирующую его скрипт.
Если переменная отсутвует или не находитсяв списке с разрешенными ключами
то блокировать выполнение скрипта. А если есть, то смотреть какие права выданы определенному скрипту, а именно работа с какими таблицами, полями, файлами и т.д.
но это не меньше всяких классов для работы с бд которых придётся переписывать
для анализа запросов.
А вообще в готовом проекте тебе придётся так или иначе просмотреть все скрипты.
Он тебе может какой нибудь бэкдор оставить не дай бог.
----- Truly yours, Sasha.
timix
Отправлено: 18 Апреля, 2009 - 13:48:35
Новичок
Покинул форум
Сообщений всего: 5
Дата рег-ции: Апр. 2009 Откуда: Москва, Россия
Помог: 0 раз(а)
Согласен, что лучше не работать с теми, кому не доверяешь. А ещё лучше быть
молодым здоровым и богатым, чем старым бедным и больным
Однако, не хотелось бы ограничивать круг разработчиков только теми, кому я 100% доверяю. Архитектура должна быть выстроена таким образом, чтобы не допускалось даже случайных утечек (по-глупости). В целом задача актуальна даже для маленьких коллективов разработчиков.
Конечно, фреймворки городить я бы тоже не стал. Это обойдётся дороже, чем сам проект.
Кое-что я всё-таки придумал. Я использую возможности php5, хотя можно и обойтись.
Вот набросок кода:
Покинул форум
Сообщений всего: 2132
Дата рег-ции: Дек. 2008 Откуда: Москваль
Помог: 52 раз(а)
Возникает вопрос: видят ли программисты чужой код ? Если весь процесс основывается на написании классов с определённым API и разработчик видит только свой класс и полное api сторонних классов других разработчиков, но не исходный код - то нужно сделать такой же API для работы с бд (базовый класс и куча методов, вынимающих инфу о пользователе, стат. контент и тд). Если же программист видит чужой код - то вся эта городьба на от чего не спасет
timix
Отправлено: 20 Апреля, 2009 - 11:45:07
Новичок
Покинул форум
Сообщений всего: 5
Дата рег-ции: Апр. 2009 Откуда: Москва, Россия
Помог: 0 раз(а)
Конечно же, исходный код остальные программисты не видят. Если надо, им выдётся пароль для доступа к строго определённому набору запросов к БД, т.е. к определённому API. Исходный код лежит в папке, куда "посторонним В".
Ограничивать же доступ через пользователей БД - неудобно, т.к. по данному тарифному плану хостинга, можно иметь только одного пользователя БД. Естественно, этот пользователь с админскими правами. (Конечно, когда проект заработает, тарифный план тоже изменится... )
Теперь задача состоит в том, чтобы иметь переменные, зарегистрированные в сессии, доступ к которым можно было бы получить только по паролю.
Это может быть полезно, например, в такой ситуации:
Пользователь сайта залогинился. В некой переменной хранится его id в БД и флаг, что он авторизован. Нехорошо, если любой скрипт (функция), будет иметь доступ на запись к таким переменным. В такой ситуации каждый хитрый хакер, не говоря уже об инсайдерах, сможет от лица любого пользователя производить всякие операции, например, перевод денег на другой счёт, или отправку сообщений.
Stierus
Отправлено: 20 Апреля, 2009 - 14:33:34
Рекордсмен по количеству сообщений за 7 дней
Покинул форум
Сообщений всего: 2132
Дата рег-ции: Дек. 2008 Откуда: Москваль
Помог: 52 раз(а)
У автора паранойя, мне кажется ))
По теме : с сессиями тебе поможет session_set_save_handler, пропиши свои функции для доступа с дополнительными проверками, нужными тебе
Покинул форум
Сообщений всего: 5
Дата рег-ции: Апр. 2009 Откуда: Москва, Россия
Помог: 0 раз(а)
Чем Вам не нравится постановка вопроса? Для интернет-магазина или
фото-галереи это всё как @ пятая нога. А если мы пишем web-интерфейс для системы
типа Янекс-деньги? И чем тут может помочь session_set_save_handler()? Без разницы,
кто восстанавливает сессию, главное, что она уже восстановлена к рассматриваемому моменту.
Впрочем, я уже придумал, как это сделать малой кровью.
Stierus
Отправлено: 21 Апреля, 2009 - 13:12:21
Рекордсмен по количеству сообщений за 7 дней
Покинул форум
Сообщений всего: 2132
Дата рег-ции: Дек. 2008 Откуда: Москваль
Помог: 52 раз(а)
Цитата:
т.к. по данному тарифному плану хостинга, можно иметь только одного пользователя БД
Цитата:
Для интернет-магазина или фото-галереи это всё как @ пятая нога. А если мы пишем web-интерфейс для системы типа Янекс-деньги?
Прикреплено изображение (Нажмите для увеличения)
timix
Отправлено: 21 Апреля, 2009 - 18:13:58
Новичок
Покинул форум
Сообщений всего: 5
Дата рег-ции: Апр. 2009 Откуда: Москва, Россия
Помог: 0 раз(а)
Теперь я понимаю за счёт чего г-н 65%-й огурец - рекордсмен по количеству сообщений.
Если Вам не хочется вникать в данную тему - не читайте мой 'бред'.
А лучше, напишите что-нибудь дельное.
Дочерние классы имеют такой вид:
class DB_User extends DB {
public function __construct() { parent::__construct(); }
public function __destruct() { parent::__destruct(); }
private function getDB_key() { return 'tdmked78'; }
private function getDB_User_key() { return 'hgdji498'; }
function login ($login,$psw,$key='')
{
if ($key !== getDB_User_key()) return FALSE;
$result = $this->perform(
"SELECT `ID`,`NICK` FROM `USERS` WHERE `LOGIN`=\"$login\" AND PSW=\"$psw\"",
$this->getDB_key());
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.