Как избежать внедрения SQL в параметры строки запроса Web API

Question

У нас есть контроллер ASP.NET Web API, который принимает разделенную запятыми строку имен столбцов базы данных из строки запроса.Эта строка имен столбцов проверяется, чтобы убедиться, что в строке присутствуют только буквы, подчеркивания и запятые;пробелы, специальные символы или цифры не допускаются.Эта строка в конечном итоге добавляется в оператор SQL посредством интерполяции строк в точности так, как она передается API в строке запроса.

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

Хотя это и не идеально, существуют ли какие-либо дополнительные меры для предотвращения атак с использованием SQL-инъекций через этот вектор?

В настоящее время мы используем Dapper для доступа к данным, но часто используем простой ADO.NET.

Answer 1

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

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

Еще один уровень защиты может исходить от самого API.Убедитесь, что вы:

1. аутентифицируете доступ к вашему контроллеру, анонимные пользователи не допускаются, возможно, что-то вроде OAUTH2, если можете.
2. превратите этот вызов API в POST и отправьте списокстолбцов в теле запроса не в строке запроса.
3. отправьте запрос по HTTP.

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