Как я могу безопасно позволить пользователям запрашивать мою базу данных с помощью (Postgre) SQL?

84
5

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


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


Как я вижу, основные проблемы, вызывающие озабоченность, следующие:


    Злоумышленник может запустить DOS (можно отслеживать это путем ведения журнала и удаления их разрешений)
    Кто-то может запустить функцию вредоносным способом.
    Кто-то может получить доступ/изменить данные, которые не принадлежат им (включая схему базы данных)
    Кто-то может удалить или изменить данные в запросе (я бы предпочел, чтобы они делали это контролируемым образом)

Что было бы самым безопасным способом обеспечения безопасного доступа к этим пользователям?

спросил(а) 2021-01-13T23:55:01+03:00 2 недели назад
1
Решение
126

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


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


Во-первых, (как указывал NoBugs), чтобы пользователи не выполняли явные вредоносные действия (например, UPDATES, DELETES, DROPS и т.д.), вам необходимо убедиться, что учетная запись пользователя, подключающаяся к серверу, имеет только разрешения SELECT для db (s) и таблицы (ы), с которыми они должны быть в состоянии читать. Посмотрите в руководстве, чтобы узнать, как определить роли для пользователей, и предоставить конкретные разрешения для этих ролей.


http://www.postgresql.org/docs/9.0/static/user-manag.html
http://www.postgresql.org/docs/9.0/static/database-roles.html


Обратите внимание, что вы можете ограничить пользователя только определенной таблицей. Если каждому пользователю должен быть предоставлен доступ к различным частям таблицы, затем PostgreSQL (и почти все СУБД) не будет поддерживать это из коробка. Единственный вариант - попытаться создать какой-то SQL/TCP proxy, который перехватывает запросы и изменяет их как-то, чтобы ограничить результаты запроса, прежде чем перейти к серверу базы данных. Это было бы чрезвычайно сложно даже для очень опытного разработчика!



Чтобы предотвратить (или, по крайней мере, обнаружить) атаки DOS, вам понадобится внешний script или процесс, чтобы следить за использованием ресурсов базы данных (и/или всего сервера) каждые несколько секунд и, возможно, строить в механизме перезапуска службы PostgreSQL, если она превышена.

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



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


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



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


    Разрешать доступ только для ваших пользователей от определенных IP-адресов/хостов (не давайте широкой общественности никаких шансов при подключении к вашему серверу). Вашим клиентам потребуется статический IP-адрес для доступа к системе, но это, безусловно, стоит учитывать для снижения рисков.
    Следите за всеми стандартными административными задачами для сервера (особенно резервные копии, дисковое пространство, обслуживание файла журнала, использование индекса и т.д.).

ответил(а) 2021-01-13T23:55:01+03:00 2 недели назад
43

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


Есть также некоторые другие соображения - разрешить только доверенный ввод (возможно, использовать https в ваших вызовах api?) и знать, что Mysql может обращаться к файлам и материалам, которые вы не хотели бы разрешать ему.

Смотрите также: http://www.greensql.com/article/protect-yourself-sqli-attacks-create-backdoor-web-server-using-mysql

ответил(а) 2021-01-13T23:55:01+03:00 2 недели назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема