Про веб-приложения и базы данных

[dil]

Это для веб-девелоперов, остальным неинтересно будет.

Как известно, у веб-девелоперов случаются ошибки, в результате чего в приложениях появляются уязвимости. Вопрос у меня о том, как можно дополнительно превентивно от этих уязвимостей защититься на уровне разграничения прав доступа в базе данных.

Вот в файловой системе как – приложение, конечно, может и само проверять, надо ли позволять  текущему пользователю выполнять ту или иную операцию с файлом или директорией, но администратор системы дополнительно устанавливает права на чтение/запись/…, которые приложение обойти не может.

А в веб-приложениях, работающих с базой, обычно все операции выполняются от имени одного пользователя, и разграничение полномочий целиком возлагается на приложение. Поскольку обычно этому пользователю разрешены операции модификации данных в базе, то при эксплуатации уязвимостей хакер имеет возможность поменять не только “пользовательские” данные (скажем, содержание текстов на сайте), но и “системные” (например, шаблоны, привилегии веб-пользователей и прочие, которые нормально подлежат редактированию только администраторами сайта).

Вопрос: а что мешает веб-приложению, работающему в “режиме обычного пользователя” и в “режиме администратора сайта” подключаться к базе от имени разных пользователей, которым назначены разные привилегии – первому поменьше, второму побольше? Чтобы хакер, работающий с приложением в первом режиме, в принципе не имел возможности поменять “системные” данные.

Я никаких принципиальных ограничений не вижу, кроме небольшого усложнения приложения и необходимости разделения данных на две группы и более тонкой настройки прав в базе.

Понятно, что это не панацея, но как дополнительная мера защиты покатит. Но я ни в одном распространенном движке для веб-приложений такого не видел. Кто-нибудь такие знает?

P.S. Про Windows Integrated Authentication в IIS я в курсе, но у него область применения довольно узкая. Если его включить, то придётся всех пользователей заводить на уровне ОС. Для публичных веб-приложений с большим количеством пользователей это неприемлемо.

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

Comments

[motto.livejournal.com]

Делают так, делают

хотя редко, да :(

[1master.livejournal.com]

Альтернативный вариант - хранимыми процедурами, но архитектуру придется проектировать самому.

[dil.livejournal.com]

http://dil.livejournal.com/825912.html?thread=5482296&format=light#t5482296

[knutov.livejournal.com]

С учетом того, что хостингов, кроме вдс, позволяющих такое сделать - около нуля - нет и поддержки со стороны приложений.

[dmarck.livejournal.com]

вот-вот, кто ж тебе даст хотя бы и двух пользователей создать?

[knutov.livejournal.com]

Вот кстати о - у нас шаред хостинговых клиентов где-то около 300 с хвостиком и за пять лет раздельные права для баз просил только один, на сколько я помню.

[dil.livejournal.com]

не понял. а кто не даёт?

[dma.livejournal.com]

Во-первых, далеко не все базы предоставляют разграничение доступа на уровне отдельных записей в таблицах. Это о "своих данных".

Во-вторых, за лишние пользовательские лицензии жадные вендоры хотят _очень_ много денег.

В-третьих, заведение пользователей на уровне ОС не сильно отличается по геморойности от заведения пользователей на уровне БД.

В-четвёртых, это напрочь убивает persistent database connections. После генерации каждой страницы коннект надо закрывать. Иначе можно сломать выбор коннекта из пула, получить коннект другого пользователя, и мы получим ту же самую систему с одним пользователем, но со всеми вышеперечисленными недостатками.

[dil.livejournal.com]

1) я про разграничение прав на уровне таблиц, а не отдельных записей. в таблицу "post" пользователь web_user писать может, а в таблицу "templates" - нет, только читать. а писать туда может web_admin.

2) не понял. какие вендоры, какие лицензии? обычный LAMP для веб-форумов, или там, блогов.

3) на уровне базы я предлагаю завести только двух пользователей: непривилегированный web_user и привилегированный web_admin.

4) пул держать только для непривилегированного пользователя. для нечастых административных операций открывать отдельные коннекты по мере надобности и закрывать после использования

[dma.livejournal.com]

А. Это тема, конечно, но на хостингах отдельных пользователей Не Дают, как тебе уже писали выше :)

Но опять же - ну чего ты хочешь от пхп-программистов?

[sanmai]

Хранимые процедуры и виды - решают. Всё уже придумано.

[dil.livejournal.com]

что они решают? если пользователь с точки зрения базы один и тот же, он может запускать все эти хранимые процедуры, включая административные

[sanmai]

Пользователь может запускать только то, что ему можно.

[1master.livejournal.com]

А пользователь ОС может вызывать все функции, включая административные, код с точки зрения ОС один и тот же :)

Это я к тому, что как сдизайнишь, так и будет. Требуй передачи авторизационного тикета в процедуру, как обязательного параметра, и будет возможность проверить его для любого вызова. Неудобно, зато безопасно.

[dma.livejournal.com]

Они решают проблему job security того, кто написал процедуры.

[alexkuklin.livejournal.com]

Хранимые процедуры и виды работают только для очень простых структур данных.
Равно как и разграничение прав на уровне БД.

[dil.livejournal.com]

как связана сложность данных с разграничением прав?

[spb-nick.livejournal.com]

Проблема в том, что на большинстве публичных сервисов наибольшую ценность представляют не шаблоны и настройки - а контент созданный теми же пользователями. Так что, в первую очередь, нужно изолировать пользователей друг от друга.

[blacklion.livejournal.com]

Обычно мешает не очень богатая система прав. Вон, в PostreSQL только в грядущем релизе будут права на столбцы.
Хотя в MySQL Это давно есть.
И когда я писал веб-приложения я это активно использовал -- анонимус на форуме подключался пользователем только для чтения, залогинившийся -- с правами записи на таблицу messages, админ -- с правами на всю базу, модератор -- с правом DELETE в messages. Хотя, как ты правильно заметил, не панацея, так как теоретичесик модератор одного раздела мог снести все, потому что таблица messages -- одна. И ещё это не очень хорошо для пулинга
соединений к базе.

Да что говорить -- моя домашняя система обработк логов апача имеет 4 пользователя а не одного -- сам logger, нормализатор, интегратор, лочиститель. Это разные компоненты и у них даны минимальные потребные права.

[dil.livejournal.com]

ну вот хотя бы на таблицы права разграничить можно же?

вот, у тебя правильно построенная система, ибо не следует давать пользователю больше прав, чем ему действительно нужно :)

[otnes.livejournal.com]

Мысль интересная. Хорошо, пускай web_user и web_admin.

А как быть с такими сценариями, как "пользователь добавил контент на сайт" (например, комментарий) и "пользователь зарегистрировался"?

[mcjabberwock.livejournal.com]

А вот тут уже работают хранимые процедуры..

[pash7ka.livejournal.com]

Сделать-то конечно можно. Но когда я пишу EJB, мне удобнее получать Entity Manager из контейнера, а там получается задать только одye настройку для всего приложения. Можно конечно написать все иначе, но по моему, лишние сложности не стоят того. Лучше те же силы потратить на проверку исходных данных. Тем более, что всякие SQL Injection при доступе к БД через фреймворки типа Hibernate или DB_DataObject в случае PHP - не сильно актуальны.

[levgem.livejournal.com]

Есть небольшая проблема с тем, что соединения то стараются не закрывать между запросами. В связи с этим надо иметь пул соединений под разными пользователями и уметь в зависимости от разной логики переключаться между ними. Это мало кто из фреймворков умеет из коробки.

И как же будет грустно, когда во время транзакции прийдется поднять права!

[dil.livejournal.com]

во время транзакции права менять не придётся, к началу транзакции уже можно сообразить, будет ли она "администраторская" или "пользовательская"

а вот почему никто из фреймворков этого не умеет - в том и вопрос..