Повышение прав доступа
Несанкционированное получение прав происходит, когда злоумышленник получает более широкие права по сравнению с правами, которые ему были предоставлены изначально. Например, злоумышленник, ранее имевший разрешение «только для чтения», может каким-либо образом расширить его до уровня «чтение и запись».
Доверенная служба маркеров безопасности должна подписывать утверждения маркеров 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 для ограничения набора разрешенных сертификатов для подписывания. Дополнительные сведения см. в разделе Управление утверждениями и авторизацией с помощью модели удостоверения и Федерация и выданные маркеры.
Смена удостоверения без контекста безопасности
Приведенные ниже сведения относятся только к Платформа .NET Framework 3.0.
При установке подключения между клиентом и сервером удостоверение клиента не изменяется, если только не имеет место следующая ситуация: после открытия клиента WCF, если выполняются все приведенные ниже условия:
процедуры определения контекста безопасности (с помощью сеанса безопасности транспорта или безопасности сообщений) отключены (свойству EstablishSecurityContext присвоено значение false в случае безопасности сообщений или используется транспорт, не поддерживающий создание безопасных сеансов, в случае безопасности транспорта. Пример подобного транспорта — HTTPS.);
используется проверка подлинности Windows;
учетные данные не задаются явным образом;
служба вызывается в олицетворенном контексте безопасности.
Если эти условия выполняются, удостоверение, которое используется для проверки подлинности клиента на стороне службы, может измениться (в данном случае не может использоваться олицетворенное удостоверение, но может использоваться удостоверение процесса) после открытия клиента WCF. Это происходит потому, что удостоверение Windows, которое используется для проверки подлинности клиента на стороне службы, передается с каждым сообщением, а удостоверение, которое используется для проверки подлинности, получается из удостоверения Windows текущего потока. Если удостоверение Windows текущего потока изменяется (например, путем олицетворения другого вызывающего объекта), удостоверение, которое прикрепляется к сообщению и используется для проверки подлинности клиента на стороне службы, также может измениться.
Если при использовании проверки подлинности Windows совместно с олицетворением требуется детерминированное поведение, необходимо явным образом задать учетные данные Windows или установить со службой контекст безопасности. Для этого следует использовать сеанс безопасности сообщений или сеанс безопасности транспорта. Например, сеанс безопасности транспорта можно обеспечить с помощью транспорта net.tcp. Кроме того, при вызове службы необходимо использовать только синхронную версию операций клиента. При установки контекста безопасности сообщений необходимо поддерживать подключение к службе открытым дольше, чем длится настроенный период обновления сеанса, поскольку удостоверение также может измениться в процессе обновления сеанса.
Получение учетных данных
Приведенные ниже сведения относятся к .NET Framework, версия 3.5 и последующим версиям.
Учетные данные, используемые клиентом или службой, основаны на текущем потоке контекста. Получение учетных данных происходит, когда вызывается метод Open (или BeginOpen для асинхронных вызовов) клиента или службы. Для классов ServiceHost и ClientBase методы Open и BeginOpen наследуются от методов Open и BeginOpen класса CommunicationObject.
.gif "Aa751843.note(ru-ru,VS.100).gif") Примечание |
|---|
| При использовании метода BeginOpen невозможно гарантировать, что получаемые учетные данные принадлежат процессу, вызвавшему метод. |
Кэширование делает возможным повторное использование маркеров с помощью устаревших данных
WCF использует функцию LogonUser подсистемы LSA для проверки подлинности пользователей по их имени и паролю. Поскольку при вызове функции входа используется большое количество ресурсов, WCF позволяет в целях повышения производительности кэшировать маркеры, представляющие прошедших проверку подлинности пользователей. Механизм кэширования сохраняет результаты предыдущей функции LogonUser для использования в будущем. По умолчанию этот механизм отключен; чтобы включить его, присвойте свойству CacheLogonTokens значение true или воспользуйтесь атрибутом cacheLogonTokens элемента userNameAuthentication element.
Чтобы установить срок жизни кэшированных маркеров, задайте для свойства CachedLogonTokenLifetime значение TimeSpan или установите значение атрибута cachedLogonTokenLifetime элемента userNameAuthentication; значение по умолчанию — 15 минут. Обратите внимание, что пока маркер находится в кэше, любой клиент, который указывает соответствующие имя пользователя и пароль, может использовать маркер, даже если учетная запись была удалена из Windows или если пароль изменился. До истечения срока жизни и удаления маркера из кэша WCF позволяет пользователям (в том числе и потенциально опасным) проходить проверку подлинности.
Чтобы ограничить связанные с этим угрозы, уменьшите вероятность атаки, задав в качестве значения cachedLogonTokenLifetime минимальный промежуток времени, который может потребоваться пользователям.
Авторизация выданных маркеров: сброс времени истечения до больших значений
При выполнении некоторых условий для свойства ExpirationTime объекта AuthorizationContext может быть установлено неожиданно большое значение (значение поля MaxValue минус один день или 20 декабря 9999 г.).
Это происходит при использовании WSFederationHttpBinding и любой из предоставляемых системой привязок, которые получили в качестве типа удостоверения клиента выданный маркер.
Кроме того, это происходит при создании пользовательских привязок с помощью одного из следующих методов.
Чтобы ограничить эту проблему, политика авторизации должна проверять действие и срок действия каждой политики авторизации.
Служба использует не тот сертификат, который ожидает клиент
При выполнении определенных условий клиент может снабдить сообщение цифровой подписью с сертификатом X.509, но служба извлечет другой сертификат.
Это может произойти при следующих обстоятельствах.
Клиент снабжает сообщение цифровой подписью с сертификатом X.509, но не прикрепляет к сообщению сертификат X.509; вместо этого он только ссылается на сертификат, используя идентификатор ключа субъекта.
Компьютер службы содержит один или несколько сертификатов с одним и тем же открытым ключом, но они содержат различную информацию.
Служба извлекает сертификат, соответствующий идентификатору ключа субъекта, но оказывается, что это не тот сертификат, использования которого ожидал клиент. Когда среда WCF получает сообщение и проверяет подпись, WCF сопоставляет информацию в извлеченном сертификате X.509 с набором утверждений, которые отличаются от ожидаемых клиентом и, возможно, предоставляют расширенные полномочия.
Чтобы избежать этого, следует ссылаться на сертификат X.509 иначе, например с помощью поля IssuerSerial.
См. также
Основные понятия
Раскрытие информации
Отказ в обслуживании
Атаки с повторением
Подделка
Неподдерживаемые сценарии