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

В этом разделе приводятся сведения по безопасности, связанные с разработкой, развертыванием и запуском приложений Entity Framework . Необходимо также следовать инструкциям по созданию безопасных приложений .NET Framework. Дополнительные сведения см. в разделе Security Overview (ADO.NET).

Общие вопросы безопасности

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

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

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

• получить строку соединения от Entity Framework ;

• перевести дерево команд на собственный язык запросов источника данных;

• собрать и возвратить результирующие наборы.

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

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

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

Защита строки соединения

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

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

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

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

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

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

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

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

  Если строки соединения необходимо конструировать во время выполнения, используется класс EntityConnectionStringBuilder. Этот класс построителя строк соединения помогает предотвратить атаки внедрения кода путем проверки входных данных и экранирования недопустимых данных. Дополнительные сведения см. в разделе Как построить строку соединения EntityConnection (платформа Entity Framework). Соответствующий класс построителя используется также для создания строки соединения с источником данных, являющейся частью строки соединения Entity Framework . Сведения о построителях строк соединения для поставщиков ADO.NET см. в разделе Connection String Builders (ADO.NET).

Дополнительные сведения см. в разделе Protecting Connection Information (ADO.NET).

Не следует предоставлять доступ к объекту EntityConnection пользователям, не заслуживающим доверия

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

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

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

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

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

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

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

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

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

• FileIOPermission. Разрешение Write на открытие заданных файлов метаданных или разрешение PathDiscovery на поиск в каталоге файлов метаданных.

• ReflectionPermission. Разрешение RestrictedMemberAccess на поддержку запросов LINQ to Entities.

• DistributedTransactionPermission. Разрешение Unrestricted на участие в транзакции System.Transactions Transaction.

• SecurityPermission. Разрешение SerializationFormatter на сериализацию исключений с помощью интерфейса ISerializable.

• Разрешение на открытие соединения с базой данных и выполнение в ней команд, таких как SqlClientPermission для базы данных SQL Server.

Дополнительные сведения см. в разделе Code Access Security and ADO.NET.

Не устанавливайте приложения, не заслуживающие доверия

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

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

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

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

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

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

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

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

Предотвращение атак путем внедрения кода SQL

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

• Атаки путем внедрения кода Entity SQL .

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

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

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

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

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

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

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

• в запросах, создающих декартовы соединения на сервере;

• во вложенных запросах Entity SQL .

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

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

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

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

  public IQueryable<Customer> GetCustomer(int customerId)
  

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

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

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

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

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

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

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

При нарушении безопасности типов 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 из ненадежных источников. Вместо этого необходимо явно создать и заполнить рабочую область из такого источника.

См. также

Основные понятия

Вопросы развертывания (платформа Entity Framework)
Вопросы переноса (платформа Entity Framework)

Другие ресурсы

ADO.NET Application Security