Несанкционированное получение привилегий
Повышение привилегий дает злоумышленнику разрешения на авторизацию за пределами первоначально предоставленных. Например, злоумышленник, ранее имевший разрешение «только для чтения», может каким-либо образом расширить его до уровня «чтение и запись».
Доверенная служба маркеров безопасности должна подписывать утверждения маркеров SAML
Маркер языка SAML (Security Assertions Markup Language) - это универсальный маркер XML, являющийся типом по умолчанию для выдаваемых маркеров. Маркер SAML может создаваться при обмене данными службой маркеров безопасности, которой веб-служба доверяет. Маркеры SAML содержат утверждения в операторах. Злоумышленник может скопировать утверждения из действительного маркера, создать новый маркер SAML и подписать его именем другого издателя. Идея состоит в том, чтобы проверить, проверяет ли сервер издателей, и, если сервер этого не делает, создать маркеры SAML, расширяющие права по сравнению с правами, которые выдаются доверенной службой маркеров безопасности.
Класс SamlAssertion проверяет цифровые подписи в токене SAML, и класс SamlSecurityTokenAuthenticator по умолчанию требует, чтобы токены SAML были подписаны сертификатом X.509, если свойство CertificateValidationMode класса IssuedTokenServiceCredential имеет значение ChainTrust. Одного использования режима ChainTrust недостаточно, чтобы определить, является ли издатель токена SAML доверенным. Службы, которым требуется более детальная модель управления безопасностью, могут использовать политики авторизации и принудительного применения для проверки издателей наборов утверждений, создаваемых при проверке подлинности токенов, или использовать параметры проверки X.509 в IssuedTokenServiceCredential для ограничения набора разрешенных сертификатов подписи. Дополнительные сведения см. в разделе "Управление утверждениями и авторизацией" с помощью модели удостоверений и федерации и выданных маркеров.
Смена удостоверения без контекста безопасности
Приведенные ниже действия относятся только к WinFX.
При установке соединения между клиентом и сервером удостоверение клиента не изменяется, за исключением одной ситуации: после открытия клиента WCF, если все следующие условия верны:
Процедуры для установления контекста безопасности (с использованием сеанса безопасности транспорта или сеанса безопасности сообщений) отключены (EstablishSecurityContext свойство устанавливается
falseв случае безопасности сообщений или транспорта, которое не может устанавливать сеансы безопасности транспорта, используется в случае безопасности транспорта. HTTPS является одним из примеров такого транспорта.используется проверка подлинности Windows;
учетные данные не задаются явным образом;
служба вызывается в олицетворенном контексте безопасности.
Если эти условия верны, удостоверение, используемое для проверки подлинности клиента в службе, может измениться (это может быть не олицетворенный идентификатор, а удостоверение процесса) после открытия клиента WCF. Это происходит потому, что удостоверение Windows, которое используется для проверки подлинности клиента на стороне службы, передается с каждым сообщением, а удостоверение, которое используется для проверки подлинности, получается из удостоверения Windows текущего потока. Если удостоверение Windows текущего потока изменяется (например, путем олицетворения другого вызывающего объекта), удостоверение, которое прикрепляется к сообщению и используется для проверки подлинности клиента на стороне службы, также может измениться.
Если при использовании проверки подлинности Windows совместно с олицетворением требуется детерминированное поведение, необходимо явным образом задать учетные данные Windows или установить со службой контекст безопасности. Для этого следует использовать сеанс безопасности сообщений или сеанс безопасности транспорта. Например, сеанс безопасности транспорта можно обеспечить с помощью транспорта net.tcp. Кроме того, при вызове службы необходимо использовать только синхронную версию операций клиента. При установки контекста безопасности сообщений необходимо поддерживать подключение к службе открытым дольше, чем длится настроенный период обновления сеанса, поскольку удостоверение также может измениться в процессе обновления сеанса.
Получение учетных данных
В следующих случаях применяется платформа .NET Framework 3.5 и последующих версий.
Учетные данные, используемые клиентом или службой, основаны на текущем потоке контекста. Получение учетных данных происходит, когда вызывается метод Open (или BeginOpen для асинхронных вызовов) клиента или службы. Для классов ServiceHost и ClientBase<TChannel> методы Open и BeginOpen наследуются от методов Open и BeginOpen класса CommunicationObject.
Примечание.
При использовании метода BeginOpen невозможно гарантировать, что получаемые учетные данные принадлежат процессу, вызвавшему метод.
Кэширование делает возможным повторное использование маркеров с помощью устаревших данных
WCF использует функцию локального центра безопасности (LSA) LogonUser для проверки подлинности пользователей по имени пользователя и паролю. Так как функция входа является дорогостоящей операцией, WCF позволяет кэшировать маркеры, представляющие пользователей, прошедших проверку подлинности, для повышения производительности. Механизм кэширования сохраняет результаты предыдущей функции LogonUser для использования в будущем. Этот механизм отключен по умолчанию; чтобы включить его, задайте для свойства значение или используйте cacheLogonTokens атрибут <userNameAuthentication>.trueCacheLogonTokens
Чтобы установить срок жизни кэшированных маркеров, задайте для свойства CachedLogonTokenLifetime значение TimeSpan или установите значение атрибута cachedLogonTokenLifetime элемента userNameAuthentication; значение по умолчанию - 15 минут. Обратите внимание, что пока маркер находится в кэше, любой клиент, который указывает соответствующие имя пользователя и пароль, может использовать маркер, даже если учетная запись была удалена из Windows или если пароль изменился. До истечения срока действия TTL и удаления маркера из кэша WCF позволяет пользователю (возможно, злоумышленнику) пройти проверку подлинности.
Чтобы ограничить связанные с этим угрозы, уменьшите вероятность атаки, задав в качестве значения cachedLogonTokenLifetime минимальный промежуток времени, который может потребоваться пользователям.
Авторизация выданных маркеров: сброс времени истечения до больших значений
При выполнении некоторых условий для свойства ExpirationTime объекта AuthorizationContext может быть установлено неожиданно большое значение (значение поля MaxValue минус один день или 20 декабря 9999 г.).
Это происходит при использовании WSFederationHttpBinding и любой из предоставляемых системой привязок, которые получили в качестве типа удостоверения клиента выданный маркер.
Кроме того, это происходит при создании пользовательских привязок с помощью одного из следующих методов.
Чтобы ограничить эту проблему, политика авторизации должна проверять действие и срок действия каждой политики авторизации.
Служба использует не тот сертификат, который ожидает клиент
При выполнении определенных условий клиент может снабдить сообщение цифровой подписью с сертификатом X.509, но служба извлечет другой сертификат.
Это может произойти при следующих обстоятельствах.
Клиент снабжает сообщение цифровой подписью с сертификатом X.509, но не прикрепляет к сообщению сертификат X.509; вместо этого он только ссылается на сертификат, используя идентификатор ключа субъекта.
Компьютер службы содержит один или несколько сертификатов с одним и тем же открытым ключом, но они содержат различную информацию.
Служба извлекает сертификат, соответствующий идентификатору ключа субъекта, но оказывается, что это не тот сертификат, использования которого ожидал клиент. Когда WCF получает сообщение и проверяет подпись, WCF сопоставляет сведения в непреднамерованном сертификате X.509 с набором утверждений, которые отличаются от ожидаемого клиента.
Чтобы избежать этого, следует ссылаться на сертификат X.509 иначе, например с помощью поля IssuerSerial.