Защита служб WCF Data Services

  • Статья

В этом разделе приведены сведения по безопасности, связанные с разработкой, развертыванием и запуском Службы WCF Data Services и приложений, которые обращаются к службам, поддерживающим Протокол Open Data Protocol (OData). Необходимо также следовать инструкциям по созданию безопасных приложений .NET Framework.

При планировании безопасности службы OData на базе Службы WCF Data Services следует позаботиться как о проверке подлинности (о процедуре определения и аутентификации участника), так и об авторизации (о процедуре, определяющей, разрешен ли прошедшему проверку подлинности участнику доступ к запрашиваемым ресурсам). Следует также рассмотреть необходимость шифрования сообщения с помощью протокола SSL.

Проверка подлинности клиентских запросов

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

Параметры аутентификации для службы данных WCF

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

Параметры аутентификации

Описание

Анонимная аутентификации

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

Обычная и дайджест-аутентификация

Для аутентификации необходимы учетные данные, состоящие из имени пользователя и пароля. Поддерживает аутентификации клиентов, отличных от Windows.

Примечание по безопасностиПримечание по безопасности

Учетные данные для обычной аутентификации (имя пользователя и пароль) отправляются в открытом виде и могут быть перехвачены.При дайджест-аутентификации отправляется хэш, основанный на переданных учетных данных, что обеспечивает большую безопасность по сравнению с обычной аутентификацией.Оба эти метода проверки подлинности уязвимы для атак типа «злоумышленник в середине».При использовании этих методов аутентификации следует организовать зашифрованное соединение между клиентом и службой данных с помощью протокола SSL.

В службах Microsoft IIS предусмотрена реализация как обычной, так и дайджест-аутентификации для HTTP-запросов в приложении ASP.NET. Эта реализация поставщика аутентификации Windows позволяет клиентскому приложению .NET Framework передавать учетные данные службе данных в HTTP-заголовке запроса, что дает возможность беспрепятственно согласовывать аутентификацию пользователя Windows. Дополнительные сведения см. в разделе Технический справочник по дайджест-аутентификации.

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

Пример применения пользовательской схемы обычной аутентификации с Службы WCF Data Services см. в сообщении на тему Custom Basic Authentication в серии сообщений OData и на тему аутентификации.

Аутентификация Windows

Обмен учетными данными на базе Windows происходит с помощью NTLM или Kerberos. Этот механизм более надежен, чем простая или дайджест-аутентификация, но он требует, чтобы клиент был приложением на базе Windows. Кроме того, в службах IIS предусмотрена реализация аутентификации Windows для HTTP-запросов в приложении ASP.NET. Дополнительные сведения см. в разделе ASP.NET Forms Authentication Overview.

Пример применения аутентификации Windows с Службы WCF Data Services см. в сообщении на тему Windows Authentication в серии сообщений OData и на тему аутентификации.

Аутентификация с помощью форм в ASP.NET

Аутентификация с помощью форм позволяет проверять подлинность пользователей с помощью собственного кода и затем предоставлять маркер аутентификации в куки-файле или в URL-адресе страницы. Проверка подлинности имени пользователя и пароля пользователя выполняется с помощью созданной вами формы входа в систему. Запросы без проверки подлинности перенаправляются на страницу входа, на которой пользователь указывает учетные данные и отправляет их. Если приложение удостоверяет подлинность запроса, система создает билет подлинности, который содержит ключ для повторного запроса данных. Дополнительные сведения см. в разделе Forms Authentication Provider.

Примечание по безопасностиПримечание по безопасности

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

Пример применения аутентификации с помощью форм с Службы WCF Data Services см. в сообщении на тему Forms Authentication в серии сообщений OData и на тему аутентификации.

Аутентификация на основе утверждений

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

Преимущество использования поставщика аутентификации на базе утверждений заключается в том, что этот метод можно использовать для проверки подлинности клиентов различных типов между несколькими доверенными доменами. Благодаря применению такого стороннего поставщика, служба данных может быть освобождена от дополнительной нагрузки по поддержке и проверке подлинности пользователей. OAuth 2.0 — это протокол аутентификации на основе утверждений, поддерживаемый системой контроля доступа к фабрике приложений Windows Azure для федеративной проверки подлинности и реализованный в виде службы. Этот протокол поддерживает службы на основе REST. Пример том, как использовать OAuth 2.0 с Службы WCF Data Services, см. публикацию по теме OData и OAuth в ряду по OData и аутентификации.

Аутентификация в клиентской библиотеке

По умолчанию клиентская библиотека Службы WCF Data Services не поддерживает учетные данные при формировании запроса к службе OData. Если службе данных для проверки подлинности пользователя требуются учетные данные, то их можно предоставить в объекте NetworkCredential, доступном через свойство Credentials контекста DataServiceContext, как показано в следующем примере:

' Set the client authentication credentials.
context.Credentials = _
    New NetworkCredential(userName, password, domain)

// Set the client authentication credentials.
context.Credentials =
    new NetworkCredential(userName, password, domain);

Дополнительные сведения см. в разделе Как указать учетные данные клиента для запроса службы данных (службы WCF Data Services).

Когда служба данных требует учетные данные входа в систему, которые нельзя указать с помощью объекта NetworkCredential, например токен на базе утверждений или куки-файл, необходимо вручную задать заголовки в HTTP-запросе, обычно это заголовки Authorization и Cookie. Дополнительные сведения об этом сценарии аутентификации см. в сообщении OData and Authentication: Client-Side Hooks. Пример задания HTTP-заголовков в сообщении запроса см. в разделе Как установить заголовки в клиентском запросе (службы WCF Data Services).

Олицетворение

Как правило, служба данных обращается к требуемым ресурсам, например к файлам на сервере или к базе данных, с использованием учетных данных рабочего процесса, в котором размещается служба данных. При использовании олицетворения приложения ASP.NET могут выполняться с удостоверением Windows (учетной записью) пользователя, выполняющего запрос. Олицетворение обычно используется в приложениях, которым проверку подлинности пользователя обеспечивают службы IIS, а учетные данные участника используются для доступа к требуемым ресурсам. Дополнительные сведения см. в разделе ASP.NET Impersonation.

Настройка авторизации службы данных

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

Ограничение доступа к ресурсам службы данных

По умолчанию в Службы WCF Data Services можно предоставлять общий доступ на чтение и запись для ресурсов служб данных (набора сущностей и операций службы) любому пользователю, у которого есть доступ к службе данных. Правила, определяющие доступ для чтения и записи, можно задавать отдельно для каждого набора сущностей, предоставляемого службой данных, а также для любой операции службы. Рекомендуется ограничить доступ для чтения и записи только теми ресурсами, которые необходимы клиентскому приложению. Дополнительные сведения см. в разделе Configuring the Data Service (WCF Data Services).

Реализация перехватчиков на базе ролей

Перехватчики позволяют перехватывать запросы к ресурсам службы данных до того, как они будут обработаны службой данных. Дополнительные сведения см. в разделе Перехватчики (службы WCF Data Services). Перехватчики позволяют принимать решения об авторизации с учетом того, какой пользователь, прошедший проверку подлинности, выполняет запрос. Пример том, как ограничить доступ к ресурсам службы данных на основе удостоверения пользователя, прошедшего проверку подлинности, см. в разделе Как перехватить сообщения службы данных (службы WCF Data Services)..

Ограничение доступа к хранилищу материализованных данных и локальным ресурсам

Учетным записям, используемым для доступа к хранилищу материализованных данных, должны быть предоставлены только те права в базе данных или файловой системе, которых достаточно для выполнения требований службы данных. При использовании анонимной аутентификации это будет учетная запись, под которой запущено приложение размещения. Дополнительные сведения см. в разделе Как разработать службу данных WCF Data Service, работающую на IIS. При использовании олицетворения пользователям, прошедшим проверку подлинности, должен предоставляться доступ к этим ресурсам — как правило, в рамках группы Windows.

Другие вопросы безопасности

Защита полезных данных

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

Пропускаемые заголовки сообщений и куки-файлы

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

Куки-файлы можно использовать в составе схемы проверки подлинности, например при проверке подлинности ASP.NET с помощью форм. Однако любые куки-файлы HTTP, заданные во входящем запросе, Службы WCF Data Services пропускает. Сервер, на котором размещена служба данных, может обрабатывать куки-файл, но среда выполнения Службы WCF Data Services никогда не анализирует и не возвращает куки-файлы. Клиентская библиотека Службы WCF Data Services также не обрабатывает куки-файлы, присланные в ответе.

Требования к пользовательскому размещению

По умолчанию Службы WCF Data Services создается как приложение ASP.NET, размещаемое в службах IIS. Это позволяет службе данных использовать методы защиты этой платформы. Вы можете определить приложения Службы WCF Data Services как размещаемые на пользовательском узле. Дополнительные сведения см. в разделе Размещение службы данных (службы WCF Data Services). Компоненты и платформа, на которой размещается служба данных, должны поддерживать приведенные ниже методы защиты для предотвращения атак на службу данных.

  • Ограничение длины URI, принимаемого в запросе к службе данных для всех возможных операций.

  • Ограничение размера как входящих, так и исходящих HTTP-сообщений.

  • Ограничение общего числа необработанных запросов в любой момент времени.

  • Ограничение размера HTTP-заголовков и их значений, а также доступ Службы WCF Data Services к данным заголовков.

  • Определение и отражение известных атак, например TCP SYN и атак повторной передачи ранее переданных сообщений.

Отсутствие дальнейшего кодирования значений

Среда выполнения Службы WCF Data Services не выполняет дальнейшего кодирования значений свойств, отправляемых в службу данных. Например, если строковое свойство сущности содержит отформатированное HTML-содержимое, теги не кодируются службой данных в HTML. Кроме того, служба данных не выполняет дальнейшего кодирования значений свойств в ответе. Клиентская библиотека также не выполняет дополнительного кодирования.

Замечания по клиентским приложениям

Следующие замечания по безопасности относятся к приложениям, в которых клиент Службы WCF Data Services используется для доступа к службам OData.

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

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

  • Клиентская библиотека не считывает никакие параметры из файлов конфигурации приложения.

  • В клиентской библиотеке не реализовано никаких механизмов междоменного доступа. Вместо этого механизмы предоставляются базовым стеком HTTP.

  • Клиентская библиотека не имеет элементов пользовательского интерфейса и никогда не пытается отобразить или вывести получаемые или отправляемые данные.

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

См. также

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

Служба данных (WCF Data Services)

Данные клиента (WCF Data Services)