Алгоритм, чтобы избежать внедрения SQL на MSSQL Server из кода C #?

Question

Какой наилучший способ избежать внедрения SQL на платформе C # .net.

Пожалуйста, опубликуйте реализацию C #, если у вас есть.

Answer 1

Алгоритм не нужен - просто не используйте конкатенацию строк для построения операторов SQL. Вместо этого используйте коллекцию SqlCommand.Parameters. Это делает все необходимое экранирование значений (например, замену ' на '') и гарантирует, что команда будет безопасной, потому что кто-то другой (например, Microsoft) выполнил все тестирование.

например. вызов хранимой процедуры:

using (var connection = new SqlConnection("..."))
using (var command = new SqlCommand("MySprocName", connection))
{
    command.CommandType = CommandType.StoredProcedure;
    command.Parameters.AddWithValue("@Param1", param1Value);
    return command.ExecuteReader();
}

Этот метод также работает для встроенных операторов SQL, например,

var sql = "SELECT * FROM MyTable WHERE MyColumn = @Param1";
using (var connection = new SqlConnection("..."))
using (var command = new SqlCommand(sql, connection))
{
    command.Parameters.AddWithValue("@Param1", param1Value);
    return command.ExecuteReader();
}

Answer 2

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

1. Примите понятие, что «Все данные - зло». Все данные, даже данные, хранящиеся в базе данных или в нашей файловой системе, являются подозрительными. Не только ввод данных из приложений за пределами нашего брандмауэра, таких как строки запросов, поля форм, файлы cookie и т. Д. Все, что может быть взломано для системы.

2. Не полагайтесь на клиентскую проверку длины полей javascript или html или даже серверные веб-API, которые используют проверку на стороне клиента. Используйте его для улучшения юзабилити, но не полагайтесь на него как на единственного стража. Знать, как работают валидаторы, предоставляемые такими API, как NET. Не принимайте их как должное. Есть способы обойти их.

3. Выполните положительное сопоставление, чтобы перехватить все данные по мере их поступления. Если Данные соответствуют диапазонам символов регулярного выражения, тогда все в порядке. Это исключает странные символы юникода в нашей базе данных, которые могут случайно разделить что-то в sql или создать другие проблемы, такие как гомографические XSS / фишинговые атаки. Напротив, для отрицательного соответствия требуются списки всех плохих персонажей, которые, кажется, постоянно растут. Это плохой подход. Положительное совпадение лучше. Мы отвергаем неверные данные, не очищаем и не избегаем их.

4. Если возможно, рассмотрите возможность фильтрации, пометки или перехвата строковых данных с помощью «update», «delete», «drop», «select», «alter» и т. Д. Это может быть невозможно из-за характера строка. «1212 Lemondrop Ln», «Waltersburg, PA» и «Table Rock, NE» являются действительными адресными полями. Выполнение ежедневного сканирования всех данных таблицы на наличие полей, соответствующих любому из них, может выявить отложенные атаки или уязвимости. Также входящие данные могут быть использованы для регистрации, запрета ip, оповещений по электронной почте и т. Д.

5. Максимально используйте хранимые процедуры и / или параметризованные запросы. Избегайте динамического sql как в клиентском коде db, так и в sql. (Избегайте операторов exec с динамическим кодом с внешними разделами в ваших хранимых процедурах !!!) Параметризация будет избегать ограничителей строки, таких как апостроф, длина полей перехвата и проверка типа. Мы не всегда можем полагаться на API-интерфейсы, обеспечивающие безупречную параметризацию, но они написаны людьми, гораздо лучше осведомленными об особенностях баз данных, чем большинство из нас.

6. Убедитесь, что в общем читаемом / исполняемом веб-каталоге нет случайного кода. Если он не является частью активного сайта, заархивируйте его в безопасном месте и удалите из общего доступа. То же самое касается неиспользуемых хранимых процедур.

7. Будьте в курсе API баз данных. Некоторые способы выполнения операторов SQL в некоторых API-интерфейсах не так безопасны, как другие.

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

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

10. Извлекайте ошибки изящно. Это касается всего кода, а не только кода, который использует базу данных. Однако атаки с использованием SQL-инъекций, в частности, полагаются на сообщения об ошибках, поэтому желательно скрыть как можно больше информации о базе данных от общественности. Всегда пишите код, который обрабатывает исключения или пустые наборы данных в ванильной манере, чтобы как можно меньше раскрывать, какой тип базы данных мы используем, какие поля находятся в наших таблицах или какие запросы мы выполняем. Журнал ошибок на сервере. Даже в коде, не связанном с базой данных, лучше помалкивать о сторонних компонентах, структурах файловых папок, других службах, которые мы можем использовать, и т. Д. Предоставление недобросовестным пользователям как можно меньшего количества информации является ключом к их невежеству.

И # 11, всегда пересматривайте / пересматривайте этот список. Всегда будь в курсе. Быть инициативным. Сделайте это приоритетной задачей и требованием, а не последним.