Я создаю поиск SQL в EF Core. Microsoft рекомендует не объединять строки, поскольку это делает приложение уязвимым для SQL-инъекций, как подробно описано в документации Microsoft: https://docs.microsoft.com/en-us/ef/core/querying/raw-sql..
Всегда используйте параметризацию для необработанных SQL-запросов: в дополнение к проверке пользовательского ввода всегда используйте параметризацию для любых значений, используемых в необработанном SQL-запросе/команде. API-интерфейсы, которые принимают необработанную строку SQL, например FromSql и ExecuteSqlCommand, позволяют легко передавать значения в качестве параметров. Перегрузки FromSql и ExecuteSqlCommand, которые принимают FormattableString, также позволяют использовать синтаксис интерполяции строк таким образом, который помогает защититься от атак путем внедрения кода SQL.
Если вы используете конкатенацию строк или интерполяцию для динамического построения какой-либо части строки запроса или передаете пользовательский ввод операторам или хранимым процедурам, которые могут выполнять эти вводы как динамический SQL, то вы несете ответственность за проверку любого ввода для защиты от атак путем внедрения кода SQL. .
Информация, хранящаяся в этой базе данных, не является конфиденциальной, но, очевидно, я не хотел бы оставлять базу данных уязвимой.
У меня есть параметр List<string> searchTerms
, который мне нужно перебрать и построить запрос на основе этого списка.
Я собираюсь объединить строки с моим SQL-запросом, но я вижу, как это сделать только с конкатенацией. Прямо сейчас мой код выглядит так.
var query = String.Format("SELECT ... where MySqlField like '%{0}%'", searchTerm[0]);
for (int i = 1; i < searchTerm.Count(); i++)
{
query += String.Format(" and MySqlField like '%{0}%'", searchTerm[i]);
}
var results = context.MySqlTable.FromSql(query);
Несмотря на то, что я использую интерполяцию, будет ли здесь достаточно дополнительной проверки? Я что-то упустил?
Есть ли запрос linq, который может сделать то же самое со списком?
STRING_SPLIT
. - person Larnu   schedule 15.04.2019