Elevação de privilégio
A elevação de privilégios resulta da concessão de permissões de autorização de invasor além daquelas concedidas inicialmente. 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 de Security Assertions Markup Language (SAML) é um token XML genérico que é o tipo padrão para tokens emitidos. Um token de SAML pode ser construído por um Serviço de Token de Segurança (STS) em que o serviço Web final confia em uma troca típica. Os tokens de SAML contêm declarações em instruções. Um invasor pode copiar as declarações de um token válido, criar um novo token de 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 de SAML que permitem privilégios além daqueles pretendidos por um STS confiável.
A classe SamlAssertion verifica a assinatura digital contida em um token de SAML e o padrão SamlSecurityTokenAuthenticator exige que os tokens de SAML sejam assinados por um certificado X.509 válido quando a CertificateValidationModeda classe IssuedTokenServiceCredential é definida como ChainTrust. O modo ChainTrust por si só é insuficiente para determinar se o emissor do token de 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 do X.509 no IssuedTokenServiceCredential para restringir o conjunto de certificados de autenticação permitidos. Para obter mais informações, consulte Como gerenciar 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 se aplica apenas ao WinFX.
Quando uma conexão é estabelecida entre um cliente e um servidor, a identidade do cliente não é alterada, 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 (a propriedade EstablishSecurityContext é definida como
falseno caso de segurança de mensagem ou transporte não capaz de estabelecer sessões de segurança ser usada 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 poderá ser alterada (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, ao representar 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 autenticação do Windows junto com a representação, você precisa 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 do transporte. Por exemplo, o transporte net.tcp pode fornecer uma sessão de segurança do 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 de 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 a .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 método Open (ou BeginOpen, para chamadas assíncronas) do cliente ou serviço é chamado. Para as classes ServiceHost e ClientBase<TChannel>, os métodos Open e BeginOpen herdam dos métodos Open e BeginOpen da classe CommunicationObject.
Observação
Ao usar o método BeginOpen, não é possível garantir que as credenciais capturadas sejam as credenciais do processo que chama o método.
Caches de token permitem 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 dispendiosa, o WCF permite que você armazene tokens que representam usuários autenticados para aumentar o desempenho. O mecanismo de cache salva os resultados de LogonUser para usos subsequentes. Esse mecanismo é desabilitado por padrão; para habilitá-lo, defina a propriedade CacheLogonTokens como true ou use o atributo cacheLogonTokens do <userNameAuthentication>.
Você pode definir um Time to Live (TTL) para os tokens armazenados em cache definindo a propriedade CachedLogonTokenLifetime como um TimeSpan ou usar o atributo cachedLogonTokenLifetime do elemento userNameAuthentication; o padrão é 15 minutos. Observe que, enquanto um token é armazenado em cache, qualquer cliente que apresenta 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 se sua senha tiver sido alterada. Até que o TTL expire e o token seja removido do cache, o WCF permitirá que o usuário (possivelmente mal-intencionado) se autentique.
Para atenuar isso: diminua a janela de ataque definindo o valor cachedLogonTokenLifetime para o intervalo de tempo mais curto de que os usuários precisam.
Autorização de token emitida: redefinição de expiração para valor grande
Em determinadas condições, a propriedade ExpirationTime do AuthorizationContext pode ser definida como um valor inesperadamente maior (o valor do campo MaxValue menos um dia, ou 20 de dezembro de 9999).
Isso ocorre ao usar a 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 pretendido pelo cliente
Em determinadas 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.
Isso 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 da entidade.
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 da entidade, mas não é aquele que o cliente pretende 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 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 IssuerSerial.