экранировать апострофы в вызовах хранимых процедур на основе Linq, когда SP содержит динамический SQL - PullRequest
Новая
       15

экранировать апострофы в вызовах хранимых процедур на основе Linq, когда SP содержит динамический SQL

1 голос
/ 31 июля 2009

Я заметил следующее:

Веб-сайт ASP.NET MVC, находящийся в стадии разработки, получает ошибку SQL «Незакрытая кавычка ...» при вызове LINQ хранимой процедуры, содержащей динамический SQL.

Например:

SP GetEmployees, вызванный с параметром [имя_фильтра] со значением [n'for], выдает эту ошибку

Я могу решить проблему, выполнив .replace ("'", "' '") следующим образом: 

[Function(Name = "dbo.GetEmployees")]
public ISingleResult<EmployeeRow> GetEmployees(
            [Parameter(DbType = "NVarChar(MAX)")] string filter_name)
{
    IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), filter_name.Replace("'", "''"));
    return ((ISingleResult<EmployeeRow>)(result.ReturnValue));
}

Теперь мне не хочется проходить через все свои SP и делать это вручную. Есть ли способ сделать это общим правилом, которое должно применяться ко всем вызовам Linq SP, которые я имею сейчас и буду делать в будущем?

Кроме того, есть ли что-то еще, что я должен избегать, чтобы предотвратить атаки SQL-инъекций?

EDIT:

Добавлен вопрос: не вызовет ли это проблем с SP, которые не включают динамический sql? Я имею в виду, когда я добавлю это имя в базу данных, оно будет сохранено как [n''for]? Я только что понял, что это, вероятно, будет так, и тогда мне все равно придется делать вручную

Ответы [ 2 ]

1 голос
/ 31 июля 2009

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

Если вы не можете гарантировать, что динамический SQL, который вы создаете, безопасен (так что вы управляете этой логикой внутри, ничего не передавая от пользователя), это будет проблемой.

Что бы произошло, если бы filter_name содержало \ 'или -?

0 голосов
/ 31 июля 2009

Я собираюсь дать (возможный) ответ здесь на мой собственный вопрос. (дайте мне знать в комментариях, если вы согласны)

Кажется более правильным, что это должно быть обработано внутри SP. Приложение не должно беспокоиться о том, содержит ли определенный SP динамический SQL или нет.

...