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

[dil]

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

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

Вот в файловой системе как - приложение, конечно,

Comments

[sanmai]

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

[dil]

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

[sanmai]

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

[dmarck]

Так речь-то (во всяком случае, для shared hosting) именно о том, что пользователь создан один, база ему тоже создана, как правило, одна, и ему на неё даны все права. Добиться от хостера создания альтернативных пользунов -- сильно нетривиальная задача.

[sanmai]

Не вижу, где бы в исходном посте упоминался shared hosting.

[dil]

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

[dil]

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

[sanmai]

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

[dil]

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

[1master]

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

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

[dil]

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

проверка авторизационного тикета внутри базы - это просто перенос части прикладного кода из приложения в базу. он принципиально ничего не меняет, нативные возможности самой СУБД по разграничению доступа не задействуются.

[dma]

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

[dil]

да, это тоже отдельная печальная тема по отношению к окружающей ОС вообще и к файловой системе в частности.

[scarab]

В своё время как минимум "Русский экспресс" перепиливал апач на предмет запуска под отдельным пользователем для каждого хостингового клиента. Думаю, были и ещё прецеденты.
А сейчас это уже в общем не очень актуально, потому что VPS.

[dma]

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

впс да, но он дороже.

[scarab]

То, что было в 1.3 - лажа, потому как работало оно, ЕМНИП, только в режиме
KeepAlive off
MaxRequestsPerChild 1
Соответственно оверхед на заметных нагрузках был просто нереальный.

Экспрессовский же патч, сколь я помню, держал в памяти таблицу "юзер - процесс" и в зависимости от виртуалсервера передавал коннект на обработку соответствующему потомку.