В этом разделе рассматриваются вопросы безопасности и конфиденциальности.

• Вопросы конфиденциальности
  
  
• Вопросы безопасности STS
  
  
• Вопросы безопасности проверяющей стороны
  
  
• Вопросы безопасности WS-FAM
  
  

Вопросы безопасности проверяющей стороны включают следующее:

• Доступность маркеров начальной загрузки
  
  
• Подделка межсайтовых запросов
  
  
• ProofEncryption
  
  
• Обязательная проверка поставщика маркера в приложении проверяющей стороны
  
  
• Обязательность шифрования в преобразовании, заменяющем ProtectedDataCookieTransform
  
  
• Использование маркеров начальной загрузки в сценарии ActAs с маркером имени пользователя
  
  
• Параметр wctx не должен содержать секретных данных
  
  
• WindowsClaimsIdentity.CertificateLogon не требует выдачи сертификата корневым центром, доверенным для Active Directory
  
  

Вопросы безопасности WS-FAM включают следующее:

• Собственные ресурсы и статические файлы по умолчанию не защищены средствами WS-FAM
  
  
• Пользователь может быть отключен от проверяющей стороны вредоносным веб-сайтом
  
  

При создании приложений, использующих Windows® Identity Foundation (WIF), разработчики должны составлять собственные заявления о конфиденциальности для конкретных приложений, поскольку заявление конфиденциальности для WIF не распространяется на такие приложения. Заявление о конфиденциальности для WIF приводится на страницах Заявление о конфиденциальности для Windows Vista и Заявление о конфиденциальности для Windows 7

В службе безопасности маркеров (STS) должны быть предусмотрены следующие меры безопасности:

• Необходимо проверять адрес и удостоверение значения, определяемого свойством AppliesTo входящего запроса RequestSecurityToken.
  
  
• При выдаче маркеров необходимо шифровать ключи подтверждения маркеров SAML для предполагаемых проверяющих сторон. Проверяющая сторона должна отклонять маркеры, чьи ключи подтверждения ей не удается расшифровать.
  
  
• Необходимо шифровать симметричные ключи подтверждения. Такой режим действует по умолчанию в WIF и может быть задан с помощью свойства EncryptingCredentials.
  
  
• Следует учитывать возможность совместно действующих угроз, например, когда два вредоносных или скомпрометированных приложения проверяющих сторон объединяют усилия для отслеживания пользователя или сбора его частной информации.
  
  
• Для симметричных ключей предпочтительным является использование объединенной энтропии.
  
  
• Выдаваемые маркеры необходимо подписывать. По умолчанию служба STS, построенная средствами WIF, подписывает выдаваемые маркеры с помощью алгоритма SHA-256.
  
  
• Значения во входящем запросе RequestSecurityToken должны рассматриваться как ненадежные входные данные. Например, если какое-либо значение служит ключом поиска по базе данных в методе GetOutputClaimsIdentity, это значение может использоваться в атаке с внедрением SQL. Для этого пользователю-злоумышленнику достаточно изменить параметр wrealm в строке запроса, передаваемой в службу STS ASP.NET.
  
  
• Рекомендуется вести кэш выдаваемых информационных карточек. Тогда при получении запроса на выдачу маркера служба сможет проверить, имеется ли в запросе ссылка на известную действующую информационную карточку. Если ссылка указывает на неизвестную или просроченную информационную карточку, STS сможет обработать запрос соответствующим образом.
  
  
• Исключения необходимо обрабатывать безопасным способом. Исключение может содержать небольшие фрагменты кода, трассы стека и пути к файлам, представляющие интерес для злоумышленников. Одна из возможных стратегий снижения риска состоит в том, чтобы записывать данные каждого исключения в базу данных и выдавать сообщение о внутренней ошибке сервера, включающее идентификатор записи базы данных (не указывая, что именно он обозначает).
  
  
• Не следует использовать известные суффиксы доменных имен (com, net, org и т. д.) в качестве имен узлов для STS, если они используются в интрасети. Это может сделать проверяющую сторону уязвимой для фишинговых атак с использованием параметра wreply сообщения WS-Trust SignOutCleanupRequest. Например, fabrikam.com будет считаться допустимой подсетью поставщика com и успешно пройдет фильтр проверки wreply в приложении проверяющей стороны. Затем, когда проверяющая сторона обработает параметр wreply, клиент может быть перенаправлен на вредоносный сайт с этим URL-адресом. Вероятность такой атаки мала, поскольку запрос должен поступить с компьютера, уже находящегося в той же интрасети, но для снижения риска предлагается все же следовать этой рекомендации.
  
  

В приложении проверяющей стороны должны быть предусмотрены следующие меры безопасности:

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

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

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

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

В ASP.NET и WCF доступ к маркеру начальной загрузки производится следующим образом:

	Копировать код
// Получение маркера начальной загрузки SecurityToken bootstrapToken = null; IClaimsPrincipal claimsPrincipal = Thread.CurrentPrincipal as IClaimsPrincipal; if ( claimsPrincipal != null ) { IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity; bootstrapToken = claimsIdentity.BootstrapToken; }

Свойство ProofEncryption используется для передачи сведений о том, как следует шифровать запрошенный маркер подтверждения и как шифровать энтропию в ответе на запрос маркера безопасности (RSTR). Оно предназначено для применения в случаях, когда транспорт или сообщение не использует средства безопасности. Если свойство применяется, когда транспорт или сообщение использует какой-либо вид безопасности, оно позволяет выполнить двойное шифрование маркера и энтропии: один раз на уровне маркера и энтропии и еще раз на уровне сообщения и транспорта. Например, Служба WCF (Windows Communication Foundation) позволяет выбрать вид безопасности для канального уровня взаимодействия между клиентом и STS. Следовательно, в этом случае свойству ProofEncryption можно присвоить значение null.

При использовании ActAs с маркером имени пользователя необходимо соблюдать осторожность, чтобы не допустить утечки пароля клиента. WCF открывает доступ к объекту UserNameSecurityToken в свойстве OperationContext.Current.IncomingMessageProperties.Security.IncomingSupportingTokens при отключении безопасного диалога. Если такой маркер используется непосредственно вместе с WSTrustChannel или FederatedClientCredentials, пароль клиента будет считан в сеть.

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

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

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

При проверке подлинности клиента, обращающегося к веб-сайту, WIF использует файлы Сookie для поддержки проверенного сеанса. Файлы Cookie могут быть созданы для домена STS (для единого входа на несколько веб-сайтов) или для домена проверяющей стороны (для единого входа на страницы федеративного приложения). В результате такого использования файлов Cookie возникает риск подделки межсайтовых запросов: файлы Cookie используются для проверки подлинности и выполнения определенных действий при посещении пользователем сторонней веб-страницы с вредоносным содержимым. Разработчики служб STS и приложений проверяющих сторон должны предвидеть такой риск и принимать меры по его снижению.

В операционных системах, выпущенных до Windows Vista и Windows Server 2008, метод CertificateLogon создает удостоверение Windows, опираясь исключительно на имя SubjectAltName, содержащееся в сертификате. Он не требует, чтобы сертификат был выдан корневым центром, доверенным для Active Directory. Отсюда возникает возможность олицетворения любого пользователя домена – путем использования сертификата, связанного по цепочке с корнем, который является доверенным для локального компьютера, но не для Active Directory.

Метод CertificateLogon также вызывается службой Служба c2WTS (Claims to Windows Token Service), поэтому аналогичная проблема возникает, если приложение проверяющей стороны, работающее в операционной системе более ранней версии, чем Windows Vista и Windows Server 2008, вызывает CertificateLogon и передает сертификат от клиента.

Сообщения SignOut и SignOutCleanup, определенные в спецификации WS-Federation, не подвергаются проверке подлинности. Это позволяет вредоносному веб-сайту (в лице проверяющей стороны) отключать пользователей от STS, перенаправляя их в STS с помощью сообщения SignOut. Для снижения этого риска можно, например, сделать так, чтобы служба STS игнорировала сообщение WS-Federation SignOut/SignOutCleanup, вместо этого предлагая пользователю страницу, на которой тот может выполнить выход.

Если проверяющая сторона использует WS-FAM, вредоносный веб-сайт может создать канал для передачи сообщения SignOutCleanup от проверенного пользователя проверяющей стороне, несмотря на то что SignOutCleanup не проходит проверку подлинности. Событие WS-FAM OnSigningOut наступает прежде, чем пользователь действительно выйдет из сеанса, что дает возможность блокировать это действие или выполнить вместо него какое-либо другое действие. WIF выполняет проверку параметра wreply сообщения, чтобы блокировать фишинговые атаки, которые могли бы переправить пользователя на фиктивный сайт после выхода из приложения проверяющей стороны. Пользователь перенаправляется на URL-адрес wreply, только если он находится в том же домене, что и поставщик. В противном случае пользователь просто перенаправляется обратно к поставщику.

По умолчанию IIS возвращает собственные ресурсы и статические файлы, включая файлы с расширениями TXT, GIF, HTML и XML, не вызывая ASP.NET, так что они не будут защищены средствами WIF. Программа FedUtil и шаблоны проектов Visual Studio, предлагаемые в ASP.NET, по умолчанию добавляют модуль федеративной проверки подлинности в файл app.config или web.config приложения так, что это обеспечивает только защиту управляемых ресурсов. Это делается намеренно. Чтобы включить защиту собственных ресурсов, удалите атрибуты preCondition = “managedHandler” из элементов <system.webServer>/<modules>, добавляющих модули WSFederationAuthenticationModule и SessionAuthenticationModule.

Следует иметь в виду, что при отладке веб-приложений, использующих встроенный веб-сервер Visual Studio, атрибут preCondition="managedHandler" игнорируется, так что защищены будут и управляемые, и собственные ресурсы. Однако при доступе к веб-приложению через IIS атрибут preCondition принимается во внимание, в результате чего WS-FAM защищает только управляемые ресурсы.