Является ли хорошей практикой безопасности разделение пользователей для чтения и записи для базы данных?

Question

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

Answer 1

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

Answer 2

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

Более важной вещью будет защита вашего веб-приложения.,Вы по-прежнему можете стать жертвой разрушительной атаки SQL-инъекций, даже если пользователь не пишет в вашу базу данных (например, номера украденных кредитных карт или пароли).

Answer 3

Да.В дополнение к хорошим ответам Abe и Cade Roux, он может помочь аудиторам безопасности расставить приоритеты и упростить судебную экспертизу после атаки.

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

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

Answer 4

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

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

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

Например, при доступе к записи через хранимые процедуры единственное внедрение, которое может произойти, - выполнение этих процедур с соответствующими параметрами.

Answer 5

Кажется, что ваша идея SQL-инъекций пришла из этого глупого комика Бобби Таблиц.
Но на самом деле просто чтение из базы данных может быть более катастрофическим, чем запись.

Кроме того, у меня есть сильное чувство, что НИКТО из хороших парней, которые говорили «это хорошая практика», не использовал его в реальной жизни.Скажем, веб-интерфейс (в реальной, а не воображаемой жизни) также должен иметь права на запись.

Вы лаете не на то дерево.
Если у вас есть некоторые части кода, склонные к внедрению SQL -ПРАВИЛА ЭТИХ ЧАСТЕЙ.Это единственное разумное решение.

Answer 6

В большинстве случаев это излишне, но в большинстве случаев следует использовать параметризованные запросы, которые в любом случае не подвержены внедрению SQL.

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

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