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

Мне нужно запрограммировать систему управления приложениями для моей компании OJT. Передний конец будет выполнен на С# и в конце SQL.

Теперь я никогда раньше не делал проект этой области; в школе у нас были только базовые уроки по SQL. Каким-то образом наш учитель полностью не смог обсуждать инъекции SQL, что я только сейчас вступаю в контакт, читая об этом в сети.

Так или иначе, мой вопрос: как вы предотвращаете инъекции SQL в С#? Я смутно думаю, что это можно сделать, правильно маскируя текстовые поля приложения, чтобы он принимал вход только в указанном формате. Например: текстовое поле электронной почты должно иметь формат "[email protected]". Будет ли этот подход достаточным? Или .NET имеет предопределенные методы, которые обрабатывают такие вещи? Могу ли я применить фильтр к текстовому полю, чтобы он принимал только формат адреса электронной почты или текстовое поле имени, поэтому он не принимает специальные символы?

Ответ 1

Используя 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);
        }
    }
}

Ответ 2

Внедрение 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 = '''[email protected]+''''

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. Программисты часто пропускают этот материал, потому что они пытаются ускорить выполнение некоторых функций и не тратят слишком много времени на просмотр своего кода.

Ответ 3

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

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

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

Ответ 4

Использовать параметризованные SQL-запросы.

Посмотрите на эти вопросы и ответы: https://stackoverflow.com/search?tab=votes&q=sql%20injection

Понимание концепции SQL-инъекции: http://en.wikipedia.org/wiki/SQL_injection

Ответ 5

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

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

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

Ответ 6

Довольно просто, если мы проверяем любой введенный пользователем ввод намного раньше (как сам контроллер), а не блокируем его на уровне БД или Repo. Эта библиотека проверяет любое ключевое слово DML и атаку XSS. http://ow.ly/LRUxw