Документ фиксирует гарантии безопасности, которые мы предоставляем в EF Core (и последующих версиях), а также рекомендации по безопасности, которые должны следовать разработчики при использовании Entity Framework.

Документ выполняет две задачи:

• Проектирование, проверка и верификация Entity Framework, чтобы гарантировать соответствие согласованным принципам безопасности.
• Помощь разработчикам в создании безопасных приложений, повышая осведомленность о проблемах безопасности, с которыми работает EF, и руководствах, которые следует соблюдать при использовании EF.

Замечание: Данный документ общественно зафиксирован для безопасной концепции EF Core. Вот почему EF Core вещь pre-release, не все гарантии, указанные в этом документе, могут быть реализованы и/или проверены ещё.

Ввод пользователя

Замечание по безопасности: Подтверждение ввода пользователя

Хотя EF обеспечивает защиту от атак SQL-инъекций (что будет рассмотрено позднее в этом документе), он не выполняет общую проверку ввода данных.

Руководство: Если значения, передаваемые API, используемые в запросах LINQ, присваиваемые свойствам объектов и т. д., происходят из ненадёжного источника, то должна быть выполнена соответствующая проверка данных в соответствии с требованиями вашего приложения.Замечание: Это включает любой ввод пользователя, который используется для динамического создания запросов. Даже когда используются LINQ, если вы принимаете входные данные пользователя для построения выражений, вам необходимо проверить, что могут быть созданы только намеренные выражения.

Хранилища данных

Замечание по безопасности: EF полагается на безопасность хранилищ данных

Entity Framework не реализует никакой функциональности безопасности и полагается на базовое хранилище данных для предоставления соответствующего контроля на основе предоставленной информации соединения.

Руководство: Информация соединения, предоставленная EF, должна иметь права доступа только для выполнения операций, запланированных приложением.

Руководство: Если некоторые пользователи приложения не должны иметь возможность выполнять операции, которые разрешены соединением, предоставленным EF, это ограничение должно быть реализовано в логике приложения.

Замечание по безопасности: Защита информации соединения хранилища данных

EF требует информации соединения для подключения к хранилищу данных. Эта информация должна храниться в защищенном месте.

Руководство: Чувствительные части информации соединения, которые будут переданы EF (например, имя пользователя и пароль), должны храниться в защищенном месте.### Примечание по безопасности: Microsoft.AspNet.Diagnostics.Entity предназначен только для разработки

Компоненты в Microsoft.AspNet.Diagnostics.Entity предназначены только для использования во время разработки приложения и не должны быть активированы после развертывания приложения. Это включает страницу ошибок базы данных и конечную точку миграций. Эти компоненты не реализуют никаких средств защиты информации.

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

Руководство: Регистрируйте промежуточное программное обеспечение (middleware) из Microsoft.AspNet.Diagnostics.Entity только при разработке приложения. Лучше всего это сделать с помощью функциональности в Startup.cs, которая позволяет использовать дополнительную конфигурацию для режима разработки.

Руководство: Если вы выбрали активацию этих компонентов в развёрнутом приложении, вы ответственны за обеспечение соответствующих средств защиты информации для предотвращения несанкционированного доступа.## Журналирование, Исключения и т.д.

Определения:

• Журналирование: Относится к данным, отправленным методу Write экземпляра ILogger, зарегистрированного с EF. Это может включать экземпляры ILogger, зарегистрированные с внешним IServiceProvider, переданным EF (например, экземпляры ILogger, зарегистрированные в Startup.cs приложений ASP.NET).
• Сообщение(ия): Относится к строке, которая будет журнализоваться и/или отображаться или записана. Это включает свойство Exception.Message, метод Exception.ToString и строку, возвращённую действием message, переданным ILogger.Write.
• Данные приложения: Относится к данным, полученным из источника данных или предоставленным конечным пользователем приложения. В зависимости от приложения эти данные могут содержать чувствительную информацию (логины, номера кредитных карт и т.д.). Примерами являются результаты запросов, значения, хранящиеся в экземплярах сущностей, и постоянные значения, используемые в выражениях LINQ.

Гарантия безопасности: сообщения не содержат учетных данных хранилища

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

Гарантия безопасности: сообщения не содержат прикладные данныеПо умолчанию, сообщения не будут содержать никаких прикладных данных. Это помогает защитить данные, так как эти сообщения могут быть отображены конечному пользователю или занесены в журнал. Отображение исключений конечному пользователю не рекомендуется, но это не слишком редкое явление (как намеренно, так и случайно). Это также помогает защитить данные, которые могут быть занесены в журнал в место, которое не имеет таких же прав доступа, как база данных.

ПРЕДУПРЕЖДЕНИЕ: Эта гарантия больше не применима к логированию сообщений, если флаг IncludeSensitiveDataInLog активирован.

Гарантия безопасности: состояние логирования не содержит прикладные данные

Состояние, переданное методу ILogger.Write (например, параметры состояния и исключения), не будет содержать ссылки на прикладные данные или объекты, из которых можно получить прикладные данные. Поскольку некоторые системы логирования могут хранить информацию о состоянии в журнале, она может непреднамеренно оказаться в недостаточно защищённом месте.

ПРЕДУПРЕЖДЕНИЕ: Эта гарантия больше не применима к состоянию логирования, если флаг IncludeSensitiveDataInLog активирован.

Примечание по безопасности: флаг IncludeSensitiveDataInLog приводит к наличию прикладных данных в состоянии логирования и сообщенияхЕсли флаг IncludeSensitiveDataInLog активирован, сообщения логирования могут содержать прикладные данные, а состояние, переданное методу ILogger, может содержать ссылки на прикладные данные или объекты, из которых можно получить прикладные данные.

Руководство: Активируйте флаг IncludeSensitiveDataInLog только тогда, когда прикладные данные являются некритичными, или вы правильно обеспечили безопасность места, куда отправляются данные журнала.

Пример: Когда флаг IncludeSensitiveDataInLog включен и Entity Framework логирует, что запрос готовится к отправке в базу данных, EF включает модель запроса как часть состояния, передаваемого методу ILogger.Write. Это состояние может включать ссылки на параметры, которые будут включены в запрос, что может происходить из значения, предоставленного пользователем, использованного в условии Where LINQ-запроса.

Примечание по безопасности: Свойства исключений могут содержать данные приложения

Хотя сообщения об исключениях не будут содержать данные приложения, объект исключения может предоставлять ссылки на сущности или другие объекты, которые позволяют получить доступ к данным приложения.

Руководство: При обработке исключений следует обеспечить надлежащую защиту конфиденциальных данных.Пример

Когда происходит нарушение согласованности базы данных, EF выбрасывает исключение типа DbUpdateConcurrencyException. Этот тип исключения имеет свойство StateEntries, которое предоставляет доступ к информации отслеживания изменений для сущностей, вовлечённых в нарушение согласованности.

Примечание по безопасности: Сообщения могут содержать информацию о модели/схеме

Сообщения могут содержать информацию о форме вашей модели и/или схемы хранилища данных. Это включает явно брошенные исключения EF, а также исключения из нижележащих компонентов, используемых EF (например, SqlClient).

Руководство: Всегда используйте конструкцию try/catch вокруг операций EF и реализуйте подходящую логику для обработки ошибок без отображения сообщения об исключении конечному пользователю приложения.

Примеры

Тип сущности включён в модель, но ключевого свойства не настроен, и нет свойства, которое будет распознано как ключ по соглашению. Сообщение об исключении включает имя рассматриваемого типа сущности.

ModelItemNotFoundException: Тип сущности 'MusicStore.Models.Album' требует определения ключа.

Модель настроена для отображения сущности на таблицу, которая не существует в базе данных. SQL Server выбрасывает исключение, указывающее, что таблица не существует. Это исключение не обрабатывается EF и возвращается обратно в код, выполняющий операцию с использованием EF.> SqlException: Недопустимое имя объекта 'Customer'.

Представители отношений

Гарантия безопасности: Запросы LINQ используют параметризацию и экранирование

Любые значения, предоставленные в запросах LINQ, будут правильно параметризоваться или экранироваться для защиты от атак SQL-инъекции. Это важно, так как значения могут поступать от конечного пользователя приложения.

Пример

Например, следующий метод ищет клиентов с заданным фамилием в базе данных.

public IEnumerable<Customer> FindCustomers(string lastName)
{
    using(var context = new CustomerContext())
    {
        var customers = context.Customers
            .Where(c => c.LastName == lastName)
            .ToList();
    }
}

Значение фамилии передается как параметр, так как оно может приходить от конечного пользователя приложения и подвергаться злонамеренному вводу данных.

SELECT [c].[CustomerId], [c].[Name]
FROM [Customer] AS [c]
WHERE [c].[LastName] = @p0

Гарантия безопасности: Обновление конвейера использует параметризацию и экранирование

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

Пример

Например, следующий метод создает нового клиента в базе данных на основе предоставленного имени и фамилии.```csharp public Customer CreateCustomer(string firstName, string lastName) { using(var context = new CustomerContext()) { var customer = new Customer { FirstName = firstName, LastName = lastName };

    context.Customers.Add(customer);
    context.SaveChanges();

    return customer;
}

}

Имена передаются как параметры, поскольку они могут поступать от конечного пользователя приложения и подвергаться злонамеренному вводу данных.

```sql
INSERT INTO [Customer] ([FirstName], [LastName])
OUTPUT INSERTED.[CustomerId]
VALUES (@p0, @p1)

Примечание по безопасности: Используйте параметризацию для сырых SQL запросов

Когда используются API, принимающие сырые SQL-строковые запросы, API позволяет легко передавать значения как параметры.

Примечание: В настоящее время нет API в Entity Framework, которые принимали бы сырые SQL-строковые запросы. Однако данное руководство применимо ко всему коду, который работает с нижележащими компонентами ADO.NET, на которых строятся провайдеры Entity Framework.

Руководство: Всегда используйте параметризацию для любых значений, используемых в сыром SQL-запросе/команде.

Руководство: Если вы используете конкатенацию строк для динамического создания любой части строки запроса, то вы должны быть ответственным за проверку входных данных для защиты от атак внедрения SQL.

ПримерНапример, следующий код использует параметры для некоторых строковых данных, предоставленных конечным пользователем, при выполнении сырого SQL-запроса против базы данных. Команда выполняется путем перехода к нижележащей реализации ADO.NET DbCommand.

public void ПереместитьКлиентов(string старыйСобственник, string новыйСобственник)
{
    using (var контекст = new OrdersContext())
    {
        var соединение = контекст.Database.AsRelational().Connection.DbConnection;
        var cmd = соединение.CreateCommand();
        cmd.CommandText = "UPDATE [dbo].[Customer] SET [Owner] = @p0 WHERE [Owner] = @p1";
        cmd.Parameters.Add(new SqlParameter("@p0", новыйСобственник));
        cmd.Parameters.Add(new SqlParameter("@p1", старыйСобственник));
        соединение.Open();
        cmd.ExecuteNonQuery();
        соединение.Close();
    }
}
```### Примечание по безопасности: API миграций не предназначены для ввода данных от ненадёжных источников

API-интерфейсы миграций предназначены для приема доверенных значений, которые компилируются в вашем приложении как часть файлов кода миграций. Большинство значений правильно экранировано, но если вы принимаете недоверенные входные данные, следует обеспечить правильную проверку. Некоторые API (например, метод `Sql(string)` и параметр `defaultValueSql`) имеют пропускающий характер и не выполняют никакой проверки или экранирования.

**Руководство:** API-интерфейсы миграций не предназначены для приема данных от недоверенного источника. Если данные от недоверенного источника (например, конечного пользователя приложения) передаются API-интерфейсам миграций, они должны быть проверены для защиты от атак SQL-инъекции.

## ПредположенияСледующие предположения сделаны и должны быть рассмотрены при обновлении этого документа:
* Assemblies Entity Framework не выполняют специальных действий с точки зрения безопасности и просто выполняются в контексте безопасности вызывающего кода. Entity Framework не может использоваться для выполнения чего-либо, что не мог бы уже сделать вызывающий код.
* Entity Framework использует существующие .NET API для всех операций ввода/вывода и не реализует какие-либо протоколы, парсинг файлов и т.д.
* Вывод состояния из командной строки (например, миграций) использует стандартную функциональность `ILogger` и соответствует содержанию данного документа.