Elevação de Privilégios
A elevação de privilégio resulta da concessão a um invasor de permissões de autorização além daquelas inicialmente concedidas. Por exemplo, um invasor com um conjunto de privilégios de permissões "somente leitura" de alguma forma eleva o conjunto para incluir "leitura e gravação".
STS confiável deve assinar declarações de token SAML
Um token SAML (Security Assertions Markup Language) é um token XML genérico que é o tipo padrão para tokens emitidos. Um token SAML pode ser construído por um STS (Serviço de Token de Segurança) no qual o serviço Web final confia em uma troca típica. Os tokens SAML contêm declarações em instruções. Um invasor pode copiar as declarações de um token válido, criar um novo token SAML e assiná-lo com um emissor diferente. A intenção é determinar se o servidor está validando emissores e, se não, utilizar a fraqueza para construir tokens SAML que permitam privilégios além daqueles pretendidos por um STS confiável.
A SamlAssertion classe verifica a assinatura digital contida em um token SAML, e o padrão SamlSecurityTokenAuthenticator requer que os tokens SAML sejam assinados por um certificado X.509 que é válido quando o CertificateValidationMode da IssuedTokenServiceCredential classe é definido como ChainTrust. ChainTrust por si só, é insuficiente para determinar se o emissor do token SAML é confiável. Os serviços que exigem um modelo de confiança mais granular podem usar políticas de autorização e imposição para verificar o emissor dos conjuntos de declarações produzidos pela autenticação de token emitida ou usar as configurações de validação X.509 para IssuedTokenServiceCredential restringir o conjunto de certificados de assinatura permitidos. Para obter mais informações, consulte Gerenciando declarações e autorização com o modelo de identidade e federação e tokens emitidos.
Alternando identidade sem um contexto de segurança
O seguinte aplica-se apenas ao WinFX.
Quando uma conexão é estabelecida entre um cliente e um servidor, a identidade do cliente não muda, exceto em uma situação: depois que o cliente WCF é aberto, se todas as seguintes condições forem verdadeiras:
Os procedimentos para estabelecer um contexto de segurança (usando uma sessão de segurança de transporte ou sessão de segurança de mensagem) são desativados (EstablishSecurityContext propriedade é definida para
falseno caso de segurança de mensagem ou transporte não capaz de estabelecer sessões de segurança é usado em caso de segurança de transporte. HTTPS é um exemplo desse transporte).Você está usando a autenticação do Windows.
Você não define explicitamente a credencial.
Você está chamando o serviço sob o contexto de segurança representado.
Se essas condições forem verdadeiras, a identidade usada para autenticar o cliente no serviço pode mudar (pode não ser a identidade representada, mas a identidade do processo) depois que o cliente WCF for aberto. Isso ocorre porque a credencial do Windows usada para autenticar o cliente no serviço é transmitida com cada mensagem e a credencial usada para autenticação é obtida da identidade do Windows do thread atual. Se a identidade do Windows do thread atual for alterada (por exemplo, representando um chamador diferente), a credencial anexada à mensagem e usada para autenticar o cliente no serviço também poderá ser alterada.
Se você quiser ter um comportamento determinístico ao usar a autenticação do Windows junto com a representação, precisará definir explicitamente a credencial do Windows ou estabelecer um contexto de segurança com o serviço. Para fazer isso, use uma sessão de segurança de mensagem ou uma sessão de segurança de transporte. Por exemplo, o transporte net.tcp pode fornecer uma sessão de segurança de transporte. Além disso, você deve usar apenas uma versão síncrona das operações do cliente ao chamar o serviço. Se você estabelecer um contexto de segurança de mensagem, não deverá manter a conexão com o serviço aberta por mais tempo do que o período de renovação da sessão configurado, pois a identidade também pode ser alterada durante o processo de renovação da sessão.
Captura de credenciais
O seguinte se aplica ao .NET Framework 3.5 e versões subsequentes.
As credenciais usadas pelo cliente ou pelo serviço são baseadas no thread de contexto atual. As credenciais são obtidas quando o Open método (ou BeginOpen, para chamadas assíncronas) do cliente ou serviço é chamado. Para as ServiceHost classes e ClientBase<TChannel> , os Open métodos e BeginOpen herdam dos Open métodos e BeginOpen da CommunicationObject classe.
Nota
Ao usar o BeginOpen método, as credenciais capturadas não podem ser garantidas como sendo as credenciais do processo que chama o método.
Caches de token permitem a reprodução usando dados obsoletos
O WCF usa a função de autoridade de segurança local (LSA) LogonUser para autenticar usuários por nome de usuário e senha. Como a função de logon é uma operação cara, o WCF permite armazenar em cache tokens que representam usuários autenticados para aumentar o desempenho. O mecanismo de cache salva os resultados para LogonUser usos subsequentes. Este mecanismo está desativado por padrão; para habilitá-lo, defina a CacheLogonTokens propriedade como true, ou use o <cacheLogonTokens atributo de userNameAuthentication>.
Você pode definir um tempo de vida (TTL) para os tokens armazenados em cache definindo a CachedLogonTokenLifetime propriedade como um TimeSpan, ou usar o cachedLogonTokenLifetimeuserNameAuthentication atributo do elemento , o padrão é 15 minutos. Observe que, enquanto um token é armazenado em cache, qualquer cliente que apresente o mesmo nome de usuário e senha pode usar o token, mesmo que a conta de usuário seja excluída do Windows ou que sua senha tenha sido alterada. Até que o TTL expire e o token seja removido do cache, o WCF permite que o usuário (possivelmente mal-intencionado) se autentique.
Para atenuar isso: diminua a janela de ataque definindo o cachedLogonTokenLifetime valor para o menor período de tempo que seus usuários precisam.
Autorização de token emitida: redefinição de expiração para grande valor
Sob certas condições, a ExpirationTimeAuthorizationContext propriedade do pode ser definida como um valor inesperadamente maior (o MaxValue valor do campo menos um dia, ou 20 de dezembro de 9999).
Isso ocorre ao usar o WSFederationHttpBinding e qualquer uma das associações fornecidas pelo sistema que têm um token emitido como o tipo de credencial do cliente.
Isso também ocorre quando você cria associações personalizadas usando um dos seguintes métodos:
Para atenuar isso, a política de autorização deve verificar a ação e o tempo de expiração de cada política de autorização.
O serviço usa um certificado diferente do que o cliente pretendia
Sob certas condições, um cliente pode assinar digitalmente uma mensagem com um certificado X.509 e fazer com que o serviço recupere um certificado diferente do pretendido.
Isto pode ocorrer nas seguintes circunstâncias:
O cliente assina digitalmente uma mensagem usando um certificado X.509 e não anexa o certificado X.509 à mensagem, mas apenas faz referência ao certificado usando seu identificador de chave de assunto.
O computador do serviço contém dois ou mais certificados com a mesma chave pública, mas eles contêm informações diferentes.
O serviço recupera um certificado que corresponde ao identificador de chave de assunto, mas não é aquele que o cliente pretendia usar. Quando o WCF recebe a mensagem e verifica a assinatura, o WCF mapeia as informações no certificado X.509 não intencional para um conjunto de declarações que são diferentes e potencialmente elevadas do que o cliente esperava.
Para atenuar isso, faça referência ao certificado X.509 de outra maneira, como usar IssuerSerialo .