Алгоритм, позволяющий избежать SQL-инъекции на сервере MSSQL из кода C#?

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

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, всегда пересматривайте / пересматривайте этот список. Всегда будьте в курсе. Быть инициативным. Сделайте это предварительным приоритетом и требованием, а не последними размышлениями.