Бөлісу құралы:

Вопросы безопасности (Entity Framework)

  • Мақала

В этой статье описываются вопросы безопасности, относящиеся к разработке, развертыванию и запуску приложений Entity Framework. Также следует следовать рекомендациям по созданию безопасных платформа .NET Framework приложений. Дополнительные сведения см. в обзоре безопасности.

Общие рекомендации по безопасности

Следующие рекомендации по обеспечению безопасности применяются ко всем приложениям, используюющим Entity Framework.

Использование только доверенных поставщиков источников данных

Для обеспечения связи с источником данных поставщик должен выполнить следующие действия:

  • Получение строка подключения из Entity Framework.
  • перевести дерево команд на собственный язык запросов источника данных;
  • собрать и возвратить результирующие наборы.

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

Шифрование подключения для защиты конфиденциальных данных

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

Защита строка подключения

Защита доступа к источникам данным - одна из важнейших целей защиты приложения. Строка соединения потенциально уязвима, если не защищена или не сформирована должным образом. Хранение сведений о соединении в виде простого текста или хранение их в памяти представляет угрозу безопасности для всей системы. Ниже представлены рекомендуемые методы защиты строки соединения.

  • Используйте управляемые удостоверения для ресурсов Azure при подключении к SQL Azure.

    Дополнительные сведения см. в разделе "Управляемые удостоверения" для ресурсов Azure.

  • Используйте проверку подлинности Windows с локальным источником данных SQL Server.

    При использовании проверки подлинности Windows для соединения с источником данных SQL Server строка соединения не содержит сведений об имени входа и пароле.

  • Шифрование разделов файла конфигурации с использованием защищенной конфигурации.

    В ASP.NET 2.0 предоставляется возможность, известная как защищенная конфигурация, которая позволяет шифровать конфиденциальные сведения в файле конфигурации. Безусловно, защищенная конфигурация разрабатывалась в первую очередь для ASP.NET, но ее можно также использовать для шифрования разделов файлов конфигурации в приложениях Windows.

  • Хранение строк соединения в защищенных файлах конфигурации.

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

  • Использование построителей строки соединения при динамическом создании соединений.

    Если необходимо создать строка подключения во время выполнения, используйте EntityConnectionStringBuilder класс. Этот класс построителя строк соединения помогает предотвратить атаки внедрения кода путем проверки входных данных и экранирования недопустимых данных. Также используйте соответствующий класс построителя строк для создания источника данных строка подключения, который является частью строка подключения Entity Framework. Сведения о построителях строка подключения для поставщиков ADO.NET см. в разделе "Построитель строк подключения".

Дополнительные сведения см. в разделе Защита сведений о подключении.

Не предоставляйте EntityConnection ненадежным пользователям

Объект EntityConnection отображает строку соединения базового соединения. Пользователь, получивший доступ к объекту EntityConnection, может также изменить ConnectionState базового соединения. Класс EntityConnection не является потокобезопасным.

Не передавать подключения за пределы контекста безопасности

После установки соединения его нельзя передавать за пределы контекста безопасности. Например, один поток с разрешением открыть соединение не должен хранить это соединение в глобальном местоположении. Если соединение доступно в глобальном местонахождении, то другой вредоносный поток может использовать открытое соединение, не имея на это явно предоставленного разрешения.

Помните, что сведения о входе и пароли могут отображаться в дампах памяти.

Если данные о входе в систему и пароль передаются в строке соединения, эти сведения хранятся в памяти до тех пор, пока операция сборки мусора не освободит ресурсы. В результате этого становится невозможным определение того, с какого момента строка пароля перестает находиться в памяти. После сбоя приложения файл дампа памяти может содержать конфиденциальные данные, а возможность просматривать этот файл дампа памяти способен получить пользователь, эксплуатирующий это приложение, а также любой другой пользователь с административным доступом к компьютеру. Для соединения с Microsoft SQL Server используйте проверку подлинности Windows.

Предоставление пользователям только необходимых разрешений в источнике данных

Администратор источника данных должен предоставлять пользователям только необходимые разрешения. Несмотря на то, что Entity SQL не поддерживает инструкции DML, которые изменяют данные, такие как INSERT, UPDATE или DELETE, пользователи по-прежнему могут получить доступ к подключению к источнику данных. Злонамеренный пользователь может с помощью этого соединения выполнять инструкции DML на собственном языке источника данных.

Запуск приложений с минимальными разрешениями

Если разрешить управляемому приложению выполняться с разрешением на полное доверие, платформа .NET Framework не ограничивает доступ приложения к компьютеру. Это может стать предпосылкой появления в приложении потенциально уязвимого места, что представляет угрозу для всей системы. Чтобы использовать безопасность доступа к коду и другие механизмы безопасности в платформа .NET Framework, следует запускать приложения с помощью разрешений с частичным доверием и с минимальным набором разрешений, необходимых для включения работы приложения. Следующие разрешения доступа к коду — это минимальные разрешения, необходимые приложению Entity Framework.

Для получения дополнительной информации см. Code Access Security and ADO.NET.

Не устанавливайте ненадежные приложения

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

Ограничение доступа ко всем файлам конфигурации

Администратор должен ограничить доступ на запись ко всем файлам, определяющим конфигурацию приложения, включая enterprisesec.config, security.config, machine.conf и приложение файла <конфигурации приложения>.exe.config.

Неизменяемое имя поставщика можно изменить в файле app.config. Клиентское приложение должно обеспечивать доступ к базовому поставщику через фабричную модель стандартного поставщика с использованием строгого имени.

Ограничение разрешений для файлов модели и сопоставления

Администратор должен предоставлять доступ для записи к файлам модели и сопоставления (EDMX-файлы, CSDL-файлы, SSDL-файлы и MSL-файлы) только тем пользователям, которые изменяют модель или сопоставления. Entity Framework требует только доступ на чтение к этим файлам во время выполнения. Администратор также должен ограничить доступ к уровню объектов и предварительно скомпилированному представлению файлов исходного кода, созданных средствами модели данных сущности.

Вопросы безопасности применительно к запросам

При запросах к концептуальной модели применимы следующие рекомендации по безопасности. Эти рекомендации применяются к запросам Entity SQL с помощью EntityClient и к запросам объектов с помощью методов LINQ, Entity SQL и построителя запросов.

Предотвращение атак на внедрение SQL

Приложения часто получают внешние входные данные (от пользователя или другого внешнего агента) и выполняют действия над этими входными данными. Любые входные данные, прямо или косвенно полученные от пользователя или внешнего агента, могут иметь содержимое, в котором используется синтаксис целевого языка для выполнения несанкционированных действий. Если целевой язык является язык SQL (SQL), например Transact-SQL, эта манипуляция называется атакой внедрения SQL. Злонамеренный пользователь может внедрить данные непосредственно в запрос и удалить таблицу базы данных, вызвать отказ в обслуживании или другим образом изменить характер выполняемой операции.

  • Атаки на внедрение сущностей SQL:

    Атаки на внедрение SQL можно выполнять в Entity SQL, предоставляя вредоносные входные данные значениям, которые используются в предикате запроса и в именах параметров. Чтобы избежать риска внедрения SQL, не следует объединять входные данные пользователя с текстом команды Entity SQL.

    Запросы Entity SQL принимают параметры везде, где принимаются литералы. Необходимо использовать параметризованные запросы, а не внедрять литералы, полученные от внешних агентов, непосредственно в запрос. Также следует использовать методы построителя запросов для безопасного создания Entity SQL.

  • Атаки внедрения LINQ to Entities:

    Хотя композиция запросов возможна в сущностях LINQ to Entities, она выполняется через API объектной модели. В отличие от запросов Entity SQL, запросы LINQ to Entity не создаются с помощью обработки строк или объединения, и они не подвержены традиционным атакам на внедрение SQL.

Предотвращение очень больших результирующих наборов

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

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

Принимая ввод от пользователя, необходимо убедиться в том, что входные данные не могут привести к созданию слишком больших результирующих наборов, которые не сможет обработать система. Вы также можете использовать Take метод в LINQ to Entity или оператор LIMIT в Entity SQL, чтобы ограничить размер результирующий набор.

Избегайте возврата результатов IQueryable при предоставлении методов потенциально ненадежным вызывающим абонентам

Старайтесь не возвращать типы IQueryable<T> из методов, которые доступны потенциально ненадежным вызывающим объектам, по следующим причинам.

  • Объект-получатель запроса, обеспечивающего доступ к типу IQueryable<T>, может вызвать метод, предоставляющий доступ к защищенным данным или увеличивающий размер результирующего набора. Например, рассмотрим следующую сигнатуру метода.

    public IQueryable<Customer> GetCustomer(int customerId)

    Объект-получатель этого запроса может вызвать метод .Include("Orders"), возвращающий IQueryable<Customer>, по которому можно извлечь данные, доступ к которым через этот запрос не планировался. Этого можно избежать, если изменить тип возвращаемого значения метода на IEnumerable<T> и вызвать метод (например, .ToList()) для материализации результатов.

  • Поскольку запросы IQueryable<T> выполняются при переборе результатов, объект-получатель запроса, обеспечивающего доступ к типу IQueryable<T>, может обработать возникшие исключения. Исключения могут содержать информацию, не предназначенную объекту-получателю.

Вопросы безопасности применительно к сущностям

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

Не совместно использовать ObjectContext в доменах приложений

Совместное использование ObjectContext в нескольких доменах приложений может создать предпосылки получения доступа к данным в строке соединения. Вместо этого следует передать сериализованные объекты или графы объектов в домен другого приложения, а затем присоединить эти объекты к ObjectContext в этом домене приложения. Дополнительные сведения см. в разделе "Сериализация объектов".

Предотвращение нарушений безопасности типов

Если безопасность типов нарушена, Entity Framework не может гарантировать целостность данных в объектах. Нарушения безопасности типов могут происходить, если разрешается эксплуатация ненадежных приложений с полным уровнем доверия для управления доступом для кода.

Выполните обработку исключений

Доступ к методам и свойствам ObjectContext в блоке try-catch. Обработка исключений предотвращает их попадание в пользовательское приложение, и поэтому пользователи приложения не смогут получить доступ к записям в ObjectStateManager или к данным модели (например, именам таблиц).

Вопросы безопасности применительно к приложениям ASP.NET

При работе с путями в приложениях ASP.NET следует учитывать следующее.

Проверка того, выполняется ли узел проверки путей

|DataDirectory| Если используется строка подстановки (заключенная в символы канала), ADO.NET проверяет, поддерживается ли разрешенный путь. Например, недопустима подстрока ".." после DataDirectory. Эта же проверка разрешения корневого оператора веб-приложения (~) выполняется процессом размещения ASP.NET. Эту проверку выполняют службы IIS, однако узлы, отличные от IIS, могут не проверять, поддерживается ли преобразованный путь. Вы должны знать поведение узла, на котором развертывается приложение Entity Framework.

Не делать предположений о именах разрешенных путей

Хотя значения, к которым разрешается корневой оператор (~) и DataDirectory строка подстановки, должны оставаться постоянными во время выполнения приложения, Entity Framework не ограничивает узел от изменения этих значений.

Проверка длины пути перед развертыванием

Перед развертыванием приложения Entity Framework необходимо убедиться, что значения корневого оператора (~) и DataDirectory строки подстановки не превышают пределы длины пути в операционной системе. ADO.NET поставщики данных не гарантируют, что длина пути находится в допустимых ограничениях.

Вопросы безопасности применительно к метаданным ADO.NET

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

Не предоставляйте конфиденциальную информацию с помощью ведения журнала

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

Не принимать объекты MetadataWorkspace из ненадежных источников

Приложения не должны принимать экземпляры объектов класса MetadataWorkspace из ненадежных источников. Вместо этого необходимо явно создать и заполнить рабочую область из такого источника.

См. также