У нас здесь еще одно обсуждение использования параметризованных SQL-запросов в нашем коде. У нас есть две стороны в обсуждении: я и некоторые другие, которые говорят, что мы всегда должны использовать параметры для защиты от SQL-инъекций, и другие парни, которые не считают это необходимым. Вместо этого они хотят заменить одиночные апострофы двумя апострофами во всех строках, чтобы избежать SQL-инъекций. Все наши базы данных работают на Sql Server 2005 или 2008, а наша база кода работает на .NET Framework 2.0.
Позвольте мне привести простой пример на C #:
Я хочу, чтобы мы использовали это:
string sql = "SELECT * FROM Users WHERE Name=@name";
SqlCommand getUser = new SqlCommand(sql, connection);
getUser.Parameters.AddWithValue("@name", userName);
//... blabla - do something here, this is safe
Пока другие парни хотят это сделать:
string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);
SqlCommand getUser = new SqlCommand(sql, connection);
//... blabla - are we safe now?
Где функция SafeDBString определяется следующим образом:
string SafeDBString(string inputValue)
{
return "'" + inputValue.Replace("'", "''") + "'";
}
Теперь, пока мы используем SafeDBString для всех строковых значений в наших запросах, мы должны быть в безопасности. Правильно?
Есть две причины использовать функцию SafeDBString. Во-первых, это так, как это было сделано с давних пор, а во-вторых, легче отлаживать операторы SQL, поскольку вы видите точный запрос, который выполняется в базе данных.
Итак. Мой вопрос заключается в том, действительно ли достаточно использовать функцию SafeDBString, чтобы избежать атак с использованием SQL-инъекций. Я пытался найти примеры кода, который нарушает эту меру безопасности, но я не могу найти никаких примеров этого.
Есть ли кто-нибудь, кто может сломать это? Как бы вы это сделали?
EDIT:
Подведем итоги ответов:
- Никто еще не нашел способа обойти SafeDBString на Sql Server 2005 или 2008. Это хорошо, я думаю?
- В нескольких ответах указывалось, что вы получаете прирост производительности при использовании параметризованных запросов. Причина в том, что планы запросов можно использовать повторно.
- Мы также согласны с тем, что использование параметризованных запросов дает более читаемый код, который легче поддерживать
- Кроме того, всегда проще использовать параметры, чем использовать различные версии SafeDBString, преобразования строки в число и преобразования строки в дату.
- Используя параметры, вы получаете автоматическое преобразование типов, что особенно полезно при работе с датами или десятичными числами.
- И, наконец: Не пытайтесь самостоятельно обеспечивать безопасность , как писал JulianR. Поставщики баз данных тратят много времени и денег на безопасность. Мы никак не можем добиться большего успеха, и нет причин, по которым мы должны стараться делать их работу.
Так что, хотя никто не смог нарушить простую защиту функции SafeDBString, у меня появилось много других хороших аргументов. Спасибо!