Это для веб-девелоперов, остальным неинтересно будет.
Как известно, у веб-девелоперов случаются ошибки, в результате чего в приложениях появляются уязвимости. Вопрос у меня о том, как можно дополнительно превентивно от этих уязвимостей защититься на уровне разграничения прав доступа в базе данных.
Вот в файловой системе как – приложение, конечно, может и само проверять, надо ли позволять текущему пользователю выполнять ту или иную операцию с файлом или директорией, но администратор системы дополнительно устанавливает права на чтение/запись/…, которые приложение обойти не может.
А в веб-приложениях, работающих с базой, обычно все операции выполняются от имени одного пользователя, и разграничение полномочий целиком возлагается на приложение. Поскольку обычно этому пользователю разрешены операции модификации данных в базе, то при эксплуатации уязвимостей хакер имеет возможность поменять не только “пользовательские” данные (скажем, содержание текстов на сайте), но и “системные” (например, шаблоны, привилегии веб-пользователей и прочие, которые нормально подлежат редактированию только администраторами сайта).
Вопрос: а что мешает веб-приложению, работающему в “режиме обычного пользователя” и в “режиме администратора сайта” подключаться к базе от имени разных пользователей, которым назначены разные привилегии – первому поменьше, второму побольше? Чтобы хакер, работающий с приложением в первом режиме, в принципе не имел возможности поменять “системные” данные.
Я никаких принципиальных ограничений не вижу, кроме небольшого усложнения приложения и необходимости разделения данных на две группы и более тонкой настройки прав в базе.
Понятно, что это не панацея, но как дополнительная мера защиты покатит. Но я ни в одном распространенном движке для веб-приложений такого не видел. Кто-нибудь такие знает?
P.S. Про Windows Integrated Authentication в IIS я в курсе, но у него область применения довольно узкая. Если его включить, то придётся всех пользователей заводить на уровне ОС. Для публичных веб-приложений с большим количеством пользователей это неприемлемо.
> Вопрос: а что мешает веб-приложению, работающему в “режиме обычного пользователя” и в “режиме администратора сайта” подключаться к базе от имени разных пользователей
Наверное, больше всего мешает connection pooling / persistent connections: обычно там не для каждого запроса создаётся соединение, а нарожалось на старте сколько-то штук и потом используются уже готовые.
Политика фундаментального анального огораживания – не есть хорошо, разрешение анонимных комментов в отдельно стоящем блоге с нормальным антиспам-плагином работы прибавит некритично.
В принципе, ничто не мешае из разных частей приложения подключаться под разными пользователями с ограниченными правами.
Но, насколько я знаю, по умолчанию пользователей с ограниченными правами не создается и большинство user-friendly инструментов управления БД такого не предлагает, тем более не видел более продвинутых фичей типа управления правами на уровне таблиц и столбцов. Плюс, если сервер баз не отдельный, то хостер никогда не даст клиенту самостоятельно копаться в привилегиях, т.е. на каждый чих привилегии менять никто не будет и ждать изменений надо будет довольно долго.
Кроме того, если большая часть сайта работает из-под read-onlyюзера, но есть возможность комментирования, надо будет создать подключение от другого юзера для возможности вставить комментарий. Не уверен, что это делается тривиально из php, да и лишние подключения нагрузку на базу создают.
По-моему такие вещи для большинства сайтов просто не рентабельны, т.к. оверхед гарантирован довольно большой, а безопасность повысить можно и другими способами.
парсер-лох >:(
есть несуществующие теги типа <offtopic> – идиотизм!