Если мой пользователь базы данных только для чтения, зачем мне беспокоиться о внедрении SQL?

Question

Могут ли они (злоумышленники) описывать таблицы и получать важную информацию? Что если я заблокирую пользователя для определенных таблиц? Я не говорю, что хочу инъекцию sql, но мне интересно, что у нас есть старый код, который восприимчив, но пользователь БД заблокирован. Спасибо.

РЕДАКТИРОВАТЬ: Я понимаю, что вы говорите, но если у меня нет ответа. Напишите для других данных, как они могут это увидеть. Привлечение к сканированию и выполнению задач имеет смысл, как и другие, но как они на самом деле увидят данные?

Answer 1

Кто-то может внедрить SQL, чтобы проверка авторизации возвращала эквивалент true вместо false, чтобы получить доступ к вещам, которые должны быть запрещены.

Или же они могут добавить соединение таблицы каталога к себе 20 или 30 раз, чтобы повысить производительность базы данных.

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

Answer 2

'); SELECT * FROM Users

Да, вы должны заблокировать их только для тех данных (таблиц / представлений), которые они действительно должны видеть, особенно если они общедоступны.

Answer 3

Только если вы не против произвольных пользователей, читающих всю базу данных. Например, вот простая вводимая последовательность входа в систему:

select * from UserTable where userID = 'txtUserName.Text' and password = 'txtPassword.Text'

if(RowCount > 0) {
     // Logged in
}

Мне просто нужно войти под любым именем пользователя и паролем 'или 1 = 1 , чтобы войти в систему под этим пользователем.

Answer 4

Будь очень осторожен. Я предполагаю, что вы удалили удаленную таблицу, изменили таблицу, создали таблицу и усеченную таблицу, верно?

В принципе, с хорошим SQL-инъекцией вы сможете изменять все, что зависит от базы данных. Это может быть авторизация, разрешения, доступ к внешним системам, ...

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

Вы также можете определить, что это за данные, используя ситуацию, когда ожидается конкретное возвращаемое значение. То есть если SQL возвращает true, выполнение продолжается, если нет, выполнение останавливается. Затем вы можете использовать бинарный поиск в вашем SQL. выберите количество (*) где user_password> 'H'; Если счет> 0, он продолжается. Теперь вы можете найти точный текстовый пароль, не требуя его печати на экране.

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

Jacob

Answer 5

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

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

• Не разрешать доступ к вашей пользовательской таблице или системным таблицам:

Postgres:

REVOKE ALL ON SCHEMA PG_CATALOG, PUBLIC, INFORMATION_SCHEMA FROM PUBLIC

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

Postgres:

GRANT USAGE ON SCHEMA X TO READ_ONLY_USER;
GRANT SELECT ON ALL TABLES IN SCHEMA X TO READ_ONLY_USER

• Настройка базы данных для отбрасывания длительных запросов

Postgres:

Set statement_timeout in the PG config file 
/etc/postgresql/(version)/main/postgresql.conf

• Подумайте о том, чтобы поместить конфиденциальную информацию в собственную схему

Postgres:

 GRANT USAGE ON SCHEMA MY_SCHEMA TO READ_ONLY_USER;

 GRANT SELECT ON ALL TABLES IN SCHEMA MY_SCHEMA TO READ_ONLY_USER;

 ALTER USER READ_ONLY_USER SET SEARCH_PATH TO MY_SCHEMA;

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

Редактировать: обратите внимание, что полностью удалив доступ к системным таблицам, вы больше не позволяете пользователю совершать вызовы, такие как cast (). Так что вы можете запустить это снова, чтобы разрешить доступ:

GRANT USAGE ON SCHEMA PG_CATALOG to READ_ONLY_USER;

Answer 6

Была ошибка Oracle, которая позволяла вам вызвать сбой экземпляра, вызвав открытый (но недокументированный) метод с неверными параметрами.

Answer 7

Да, продолжайте беспокоиться о внедрении SQL. Вредоносные операторы SQL - это не только записи.

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

SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary;