Верна ли логика работы с БД (разграничение прав и постоянное подключене) ?
Друзья, начитавшись разного, в голове каша, хочется разъяснения.
1.
Есть ли смысл для разного рода запросов использовать разных пользователей?
Например:
- Если нам нужно только прочитать данные, то используем пользователя у которого есть права только на выборку select
- Если добавлять/править/удалять, то пользователя с правилами select, insert, update, вместо прав delete будем помечать записи на удаление, после пробегаться по ним удаляя с помощью пользователя с расширенными правилами.
По идеи такие действия должны повысить защиту БД. Но есть ли в них смысл, если да то в каких случаях.
2.
Есть ли смысл только при выборки данных использовать постоянное соединение? А для всех других запросов обычное непостоянное соединение.
Тогда, мы вроде бы должны экономить на времени и ресурсах, ведь нам не нужно каждый раз осуществлять соединение.
---
Подскажите на сколько такое мышление верное? на сколько это актуально? кто-нибудь так делает?
Возможно ли оно на связке php + mysql ?
И спасибо!
Проблема начинающих защищателей, которых ты начитался, состоит в очень скудных знаниях об SQL инъекциях. И свои советы они строят исходя из этих самых знаний. Состоящих из ровно одного примера про Бобби-фейсом-об-тейбл.
Суровая же правда жизни состоит в том, что инъекция через SELECT может быть куда более разрушительной.
Поэтому заниматься такой ерундой, как разделение прав, не нужно. Нужно соблюдать одно очень простое правило при работе с БД - ЛЮБЫЕ данные должны попадать в запрос только через плейсхолдер - и проблема инъекций решена.
Во втором вопросе не вижу смысла вообще. Постоянное соединение, которое ты открыд для селекта, будет видно и тому скрипту, который выполняет апдейты. Не вижу причины, по которой надо открывать новое вместо того, чтобы воспользоваться уже открытым.
Stadinov Denis: негде. не бывает отельных инъекций через селект. Тип запроса для инъекции не важен. Инъекция либо есть, либо нет. Если есть - то у тебя проблемы. И надо думать о том, как убрать инъекцию, а не о том, в каком она запросе.
