Каковы хорошие способы предотвращения SQL-инъекций?

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

Вот пример, взятый из одной из статей выше:

private static void UpdateDemographics(Int32 customerID,
    string demoXml, string connectionString)
{
    // Update the demographics for a store, which is stored  
    // in an xml column.  
    string commandText = "UPDATE Sales.Store SET Demographics = @demographics "
        + "WHERE CustomerID = @ID;";

    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        SqlCommand command = new SqlCommand(commandText, connection);
        command.Parameters.Add("@ID", SqlDbType.Int);
        command.Parameters["@ID"].Value = customerID;

        // Use AddWithValue to assign Demographics. 
        // SQL Server will implicitly convert strings into XML.
        command.Parameters.AddWithValue("@demographics", demoXml);

        try
        {
            connection.Open();
            Int32 rowsAffected = command.ExecuteNonQuery();
            Console.WriteLine("RowsAffected: {0}", rowsAffected);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }
}

SQL-инъекция может быть сложной проблемой, но есть способы ее обойти. Ваш риск снижается просто за счет использования ORM, такого как Linq2Entities, Linq2SQL, NHibrenate. Однако у вас могут возникнуть проблемы с SQL-инъекциями даже с ними.

Главное в SQL-инъекциях — это ввод, контролируемый пользователем (как и в XSS). В самом простом примере, если у вас есть форма входа (надеюсь, у вас никогда не будет такой, которая просто делает это), которая принимает имя пользователя и пароль.

SELECT * FROM Users WHERE Username = '" + username + "' AND password = '" + password + "'"

Если бы пользователь ввел следующее для имени пользователя Admin' --, оператор SQL выглядел бы так при выполнении в базе данных.

SELECT * FROM Users WHERE Username = 'Admin' --' AND password = ''

В этом простом случае использование параметризованного запроса (что делает ORM) устранит ваш риск. У вас также есть проблема с менее известным вектором атаки SQL-инъекцией, а именно с хранимыми процедурами. В этом случае, даже если вы используете параметризованный запрос или ORM, у вас все равно будет проблема с внедрением SQL. Хранимые процедуры могут содержать команды выполнения, и сами эти команды могут быть уязвимы для атак путем внедрения кода SQL.

CREATE PROCEDURE SP_GetLogin @username varchar(100), @password varchar(100) AS
DECLARE @sql nvarchar(4000)
SELECT @sql = ' SELECT * FROM users' +
              ' FROM Product Where username = ''' + @username + ''' AND password = '''+@password+''''

EXECUTE sp_executesql @sql

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

Мои рекомендации заключаются в том, чтобы использовать ORM, чтобы немедленно снизить вероятность возникновения проблемы с SQL-инъекцией, а затем научиться определять код и хранимые процедуры, которые могут иметь проблему, и работать над ее устранением. Я не рекомендую использовать ADO.NET (SqlClient, SqlCommand и т. д.) напрямую, если вам это не нужно, не потому, что использовать его с параметрами как-то небезопасно, а потому, что гораздо проще облениться и просто начать писать SQL запрос с использованием строк и просто игнорируя параметры. ORMS прекрасно заставляют вас использовать параметры, потому что именно это они и делают.

Далее Посетите сайт OWASP по внедрению SQL https://www.owasp.org/index.php/SQL_Injection и используйте шпаргалка по SQL-инъекциям, чтобы убедиться, что вы можете обнаружить и устранить любые проблемы, которые возникнут в вашем коде. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet, наконец, я бы сказал внедрите хороший обзор кода между вами и другими разработчиками в вашей компании, где вы можете просматривать код друг друга на предмет таких вещей, как внедрение SQL и XSS. Очень часто программисты пропускают этот материал, потому что пытаются поторопиться с какой-то функцией и не тратят слишком много времени на просмотр своего кода.

Мой ответ довольно прост:

Используйте Entity Framework для связи между C# и вашей базой данных SQL. Это сделает параметризованные строки SQL, которые не уязвимы для SQL-инъекций.

Как бонус, с ним очень легко работать.

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

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

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