Vulnerabilidades comuns em SAML e como corrigi-las

A Security Assertion Markup Language (SAML) é uma estrutura baseada em XML que desempenha um papel fundamental na gestão segura de identidade e acesso. Ela atua como intermediária confiável entre diferentes entidades de um ecossistema digital, como provedores de identidade, provedores de serviço e usuários. O principal objetivo da SAML é viabilizar o logon único (SSO), um processo de autenticação simples e eficiente que permite acessar vários aplicativos e serviços com um único conjunto de credenciais. Embora a SAML ofereça muitos benefícios em relação à autenticação tradicional com nome de usuário e senha, ainda podem ocorrer vulnerabilidades, dependendo de:

1. Biblioteca SAML usada pelo desenvolvedor

2. Configurações SAML usadas pelo desenvolvedor

Este artigo apresenta uma breve visão geral das vulnerabilidades mais comuns em SAML e mostra como corrigi-las com alguns exemplos.

Vulnerabilidades comuns em SAML

Validação de assinatura e assinatura de mensagens

A validação de asserções XML pode ser usada para impedir ataques de adulteração de XML. Ela confirma a autenticidade das mensagens XML contidas nas asserções SAML. O wrapping de assinatura XML é uma vulnerabilidade que explora falhas na forma como as assinaturas XML são processadas e pode permitir a manipulação maliciosa dos dados.

No exemplo abaixo (VulnerableSAMLApp), ao fazer a autenticação como usuário comum, estas informações aparecem no perfil do usuário após a autenticação.

É possível elevar os privilégios desse usuário modificando a solicitação SAML e alterando a associação ao grupo para torná-lo administrador.

Para corrigir um problema como esse, é preciso tomar algumas medidas:

1. As asserções precisam ser assinadas. Isso adiciona uma assinatura ao atributo da asserção, que é assinada com o certificado confiável.

2. Os valores das asserções precisam ser validados para garantir que as assinaturas correspondam aos dados da mensagem como um todo, incluindo a asserção.

A maioria das bibliotecas SAML modernas oferece configurações que podem ser ativadas para permitir a assinatura e a validação de mensagens. Veja aqui um exemplo no samlify: https://github.com/tngan/samlify/blob/master/docs/sp-configuration.md

Criptografia fraca

Na autenticação SAML, é essencial criptografar determinadas partes da mensagem para garantir a segurança e a confidencialidade dos dados sensíveis. Em especial, as asserções SAML, que contêm informações sobre o usuário e seus atributos, precisam ser criptografadas. Essas asserções são trocadas entre o Provedor de Identidade (IdP) e o Provedor de Serviço (SP) para verificar a identidade e as permissões do usuário.

1const idp = IdentityProvider({
2  isAssertionEncrypted: true,
3  metadata: fs.readFileSync('./metadata_idp.xml'),
4  dataEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#aes256-cbc',
5  keyEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#rsa-1_5' 
6});
7An example on setting the encryption on an IdentityProvider when using Samilify: https://github.com/tngan/samlify/blob/master/docs/encrypted-saml-response.md

Expiração de mensagens

Por padrão, as mensagens SAML podem estar vulneráveis a ataques de repetição. Nesse tipo de ataque, uma mensagem SAML válida que foi interceptada é reutilizada sem autorização para se passar por uma ação SAML legítima, como o logon único (SSO) ou o logout único (SLO). Os atributos "NotBefore" e "NotOnOrAfter" podem ser usados para impedir esses ataques.

• NotBefore (atributo): Esse atributo define o primeiro momento em que a asserção SAML pode ser considerada válida. Em outras palavras, a asserção não deve ser usada para autenticação ou autorização antes do horário especificado em "NotBefore". Isso garante que a asserção não seja usada antes da hora, algo especialmente importante em operações sujeitas a restrições de tempo. Antes do horário "NotBefore", a asserção costuma ser considerada inválida.

• NotOnOrAfter (atributo): Esse atributo especifica o último momento em que a asserção SAML permanece válida. Após o horário definido em "NotOnOrAfter", a asserção não deve ser usada para autenticação ou autorização. Essa restrição de tempo ajuda a impedir o uso indevido de asserções expiradas que possam ter sido interceptadas ou obtidas de forma maliciosa.

Redirecionamento aberto

A SAML é, por natureza, um protocolo assíncrono. Quando começa um processo de login iniciado pelo SP, ele cria uma solicitação de autenticação SAML e a encaminha ao Provedor de Identidade (IdP). Nesse momento, o Provedor de Serviço não armazena nenhuma informação sobre a solicitação. Por isso, quando recebe a resposta SAML do IdP, o Provedor de Serviço não sabe qual link direto levou à solicitação de autenticação. A SAML resolve esse problema com a inclusão de um parâmetro essencial chamado "RelayState".

O RelayState é um parâmetro HTTP que pode ser incluído tanto na solicitação quanto na resposta SAML. Em um fluxo de login iniciado pelo SP, o SP pode usar o parâmetro RelayState para incluir informações adicionais na solicitação SAML. Esse mecanismo garante que o contexto e os dados essenciais não se percam durante o processo assíncrono. No entanto, um invasor pode abusar desse parâmetro RelayState para realizar ataques de redirecionamento aberto.

Para evitar ataques de redirecionamento aberto, confirme que o valor de RelayState é um URL confiável antes de redirecionar. Veja um exemplo fornecido pelos mantenedores da biblioteca python3-saml.

Conclusão

Apresentamos alguns exemplos de vulnerabilidades comuns em SAML e como corrigi-las, mas vale lembrar que as correções podem variar — ou, em alguns casos, nem ser possíveis — dependendo da biblioteca SAML e do Provedor de Identidade que você usa. Por isso, consulte a documentação dessas bibliotecas e dos provedores terceirizados para saber como prevenir essas vulnerabilidades de forma eficaz.

Por fim, embora a SAML ofereça uma estrutura para a gestão segura de identidade e acesso, o OpenID Connect (OIDC) pode ser uma boa alternativa que não usa XML. O OIDC é uma camada moderna de identidade construída sobre o OAuth 2.0 e o JWT. Em vez de usar asserções baseadas em XML, o OIDC usa JSON Web Tokens (JWTs) para transmitir informações de identidade, o que o torna mais adequado para aplicativos modernos na web e em dispositivos móveis. Com o OIDC, o processo de integração pode ser simplificado. Ele também oferece recursos como a recuperação de informações do perfil do usuário, sendo uma opção atraente para desenvolvedores que preferem não lidar com a segurança de XML. Muitos dos ataques mencionados neste artigo não se aplicam ao OIDC. Por isso, vale considerar o OIDC como alternativa: sua adoção pode reduzir algumas das complexidades associadas à SAML.