Поделиться через


Отказ в обслуживании

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

Избыточное потребление памяти

Проблема может возникнуть при чтении XML-документа с большим количеством уникальных локальных имен, пространств имен или префиксов. Если вы используете класс, производный от XmlReader, и вызываете либо свойство LocalName, Prefix, либо NamespaceURI для каждого элемента, возвращаемая строка добавляется в NameTable. Коллекция, находящаяся на NameTable, никогда не уменьшается, создавая виртуальную "утечку памяти" обработчиков строк.

К устранению рисков относятся следующие:

  • Наследуйте от класса NameTable и установите максимальную квоту размера. (Вы не можете предотвратить использование NameTable или переключить NameTable, когда оно заполнено.)

  • Избегайте использования упомянутых свойств и, где это возможно, вместо этого используйте метод MoveToAttribute с методом IsStartElement; эти методы не возвращают строки и таким образом избежать проблемы переполнения коллекции NameTable.

Вредоносный клиент отправляет чрезмерные запросы лицензий в службу

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

Устранение рисков. Используйте следующие свойства LocalServiceSecuritySettings класса:

  • MaxCachedCookies: управляет максимальным числом ограниченных по времени SecurityContextToken, которые сервер кэширует после SPNego или SSL согласования.

  • IssuedCookieLifetime: управляет сроком действия SecurityContextTokens, которые сервер выдает после SPNego или SSL переговоров. Сервер кэширует SecurityContextTokens в течение этого периода времени.

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

  • InactivityTimeout: управляет максимальным временем поддержания безопасного разговора, если от клиента не получено сообщение приложения. Эта квота запрещает клиентам устанавливать защищённые соединения в службе, тем самым заставляя службу поддерживать состояние для каждого клиента, но они никогда не используются.

WSDualHttpBinding или двойные настраиваемые привязки требуют проверки подлинности клиента

По умолчанию WSDualHttpBinding включён режим безопасности. Однако возможно, что если проверка подлинности клиента отключена, задав значение ClientCredentialType для свойства None, злоумышленник может вызвать атаку типа "отказ в обслуживании" в отношении третьей службы. Это может произойти, так как вредоносный клиент может направлять службу для отправки потока сообщений в третью службу.

Чтобы устранить эту проблему, не задайте для свойства значение None. Кроме того, следует учитывать эту возможность при создании пользовательской привязки с двумя шаблонами сообщений.

Журнал событий аудита можно заполнить

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

Чтобы устранить эту проблему, задайте свойству SuppressAuditFailuretrue и используйте свойства Средства просмотра событий для управления процессом аудита. Дополнительные сведения об использовании средства просмотра событий для просмотра журналов событий и управления ими см. в средстве просмотра событий. Дополнительные сведения см. в разделе Аудит.

Неправильные реализации IAuthorizationPolicy могут привести к тому, что служба перестает отвечать

Evaluate Вызов метода в неисправной реализации IAuthorizationPolicy интерфейса может привести к тому, что служба не отвечает.

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

Максимальный размер токена Kerberos может потребовать увеличения

Если клиент принадлежит к большому количеству групп (примерно 900, хотя фактическое число зависит от групп), проблема может возникнуть, когда блок заголовка сообщения превышает 64 килобайта. В этом случае можно увеличить максимальный размер маркера Kerberos. Кроме того, может потребоваться увеличить максимальный размер сообщения WCF для размещения более крупного токена Kerberos.

Автоматическая регистрация приводит к нескольким сертификатам с одинаковым именем субъекта для компьютера

Автоматическая регистрация — это возможность Windows Server 2003 автоматически регистрировать пользователей и компьютеры для сертификатов. Если компьютер находится на домене с включенной функцией, сертификат X.509 с целевой целью проверки подлинности клиента автоматически создается и вставляется в хранилище личных сертификатов локального компьютера при каждом присоединении нового компьютера к сети. Однако автоматическая регистрация использует одинаковое имя субъекта для всех сертификатов, создаваемых в кэше.

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

Чтобы устранить эту проблему, наведите ссылку на точный сертификат, используемый с помощью более точного критерия поиска в <serviceCredentials>. Например, используйте FindByThumbprint опцию и укажите сертификат по его уникальному отпечатку.

Дополнительные сведения о функции автоматической регистрации см. в разделе "Автоматическая регистрация сертификатов" в Windows Server 2003.

Последняя из нескольких альтернативных имен субъектов, используемых для авторизации

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

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

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

Для устранения проблемы: требуется доступ к компьютеру для изменения файла конфигурации. Используйте списки управления доступом к файлам (ACL) для защиты файлов конфигурации. WCF требует, чтобы код был в каталоге приложения или глобальном кэше сборок, прежде чем он позволит загрузить такой код из конфигурации. Используйте списки управления доступом для обеспечения безопасности каталогов.

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

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

Замечание

При использовании сеансов с сохранением состояния предыдущий абзац не применяется. Дополнительные сведения о сеансах с сохранением состояния см. в Практическое руководство: Создание маркера контекста безопасности для безопасного сеанса.

Чтобы устранить эту проблему, задайте ограничение для максимального количества активных сеансов и максимального времени существования сеанса, задав SecurityBindingElement свойство SecurityBindingElement класса.

См. также