Алгоритм, чтобы избежать SQL-инъекции на сервере MSSQL из кода С#?

Ответ 1

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

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

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

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

• По возможности рассмотрите фильтрацию, пометку или привязку строковых данных с помощью "обновления", "удаления", "падения", "выбора", "изменения" и т.д. Это может быть невозможно, учитывая характер Струна. "1212 Lemondrop Ln", "Waltersburg, PA" и "Table Rock, NE" являются действительными адресными полями. Выполнение ежедневного сканирования всех табличных данных для полей, которые соответствуют любому из них, может выявлять задерживаемые атаки или уязвимости. Также можно использовать регистрацию, запрет ip, оповещения по электронной почте и т.д. И т.д., Поскольку данные поступают в входящие.

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

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

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

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

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

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

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

Ответ 2

Нет никакого алгоритма - просто не используйте конкатенацию строк для создания операторов 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();
}