У нас тут ще одна дискусія на роботі щодо використання параметризованих запитів 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, у мене з’явилося багато інших хороших аргументів. Дякую!