Início / server / Perguntas / 1120740
Accepted
JohnLBevan
Asked: 2023-01-21 08:15:06 +0800 CST

Os SafeLinks do Outlook enviam solicitações GET - por que isso não é um problema maior?

  • 772

Percebemos um problema em nosso sistema de RH, onde os usuários solicitam licença, essa aprovação é enviada ao gerente e, quando o gerente clica no link para aprovar, eles veem um erro dizendo que a licença já foi aprovada ... Isso parece porque o Outlook envia uma solicitação GET para o URI de aprovação do sistema de RH para verificar se o link é malicioso; mas, ao fazê-lo, aprova a licença do empregado. Observação: esta solicitação GET é enviada antes mesmo de o e-mail ser visualizado/não é acionado por nenhuma ação do usuário destinatário.

O sistema de RH é de terceiros, com suporte ruim, então eles não puderam confirmar nossa teoria sobre o que está acontecendo... No entanto, testei enviando um e-mail de um endereço de e-mail externo que contém um link para um site que eu apoio (mas não está na lista de domínios verificados do Outlook). Olhando para os logs no meu servidor, vejo que momentos após este e-mail de teste chegar ao meu cliente de e-mail (sem que eu clique no link ou mesmo visualize o conteúdo do e-mail), com certeza uma solicitação GET aparece nos meus logs de um IP que pertence a MS (de acordo com um whois no IP).

Isso parece muito prejudicial... mas então trabalhamos com outros sistemas que possuem links de clique único (tanto para aprovações quanto também muitos e-mails que contêm unsubscribelinks ou verify my emaillinks que funcionam com um clique / não exigem acompanhamento manual) e parece que não temos problemas semelhantes com eles; e parece improvável que, em todos esses casos, os proprietários dos sites tenham colocado na lista negra os IPs do MS associados aos SafeLinks (especialmente como se fosse tão simples de contornar, um ator mal-intencionado também poderia usar esse truque para evitar a proteção de safelinks).

  • É provável que nossa teoria sobre SafeLinks esteja causando as aprovações corretas?
  • Em caso afirmativo, há alguma explicação de por que não está afetando mais sistemas?
exchange

3 respostas

  1. Apesar de existirem várias razões pelas quais "Links seguros" causam mais problemas do que resolvem, isso também é uma falha de design e uma vulnerabilidade no sistema de RH :

    1. Essa ação deve exigir autenticação , ou seja, o usuário com as permissões necessárias para a ação deve estar logado. Os "Links seguros" não vêm de uma sessão autenticada. Ele pode se encaixar em qualquer uma dessas categorias:

      • CWE-306: Autenticação ausente para função crítica

        O produto não executa nenhuma autenticação para funcionalidade que exija uma identidade de usuário comprovável ou que consuma uma quantidade significativa de recursos.

      • CWE-862: Autorização ausente

        O software não executa uma verificação de autorização quando um ator tenta acessar um recurso ou executar uma ação.

      • CWE-749: Método ou função perigosa exposta

        O software fornece uma interface de programação de aplicativos (API) ou interface semelhante para interação com atores externos, mas a interface inclui um método ou função perigosa que não está devidamente restrita.

      Mesmo que o link tenha uma parte aleatória, não é forte o suficiente, pois o link pode facilmente vazar ou ser adivinhado.

      • CWE-1390: autenticação fraca

        O produto usa um mecanismo de autenticação para restringir o acesso a usuários ou identidades específicos, mas o mecanismo não prova suficientemente que a identidade reivindicada está correta.

    2. O sistema não deve executar ações de aprovação ou recusa com base em uma única GETsolicitação, mas a página vinculada deve, por exemplo, ter botões para confirmar a ação desejada com POSTsolicitações separadas.

      Isso é até recomendado no HTTP Semantics, RFC 9110, 9.2.1 :

      9.2.1. Métodos seguros

      Os métodos de solicitação são considerados "seguros" se sua semântica definida for essencialmente somente leitura; ou seja, o cliente não solicita e não espera nenhuma mudança de estado no servidor de origem como resultado da aplicação de um método seguro a um recurso de destino. - -

      Dos métodos de solicitação definidos por esta especificação, os métodos GET, HEAD, OPTIONS e TRACE são definidos como seguros.

      O objetivo de distinguir entre métodos seguros e inseguros é permitir que processos de recuperação automatizados (spiders) e otimização de desempenho de cache (pré-busca) funcionem sem medo de causar danos. Além disso, permite que um agente de usuário aplique restrições apropriadas no uso automatizado de métodos inseguros ao processar conteúdo potencialmente não confiável.

    Informe esta vulnerabilidade ao fornecedor do software.

    • 3
  2. Best Answer

    Isso parece ocorrer porque o Outlook envia uma solicitação GET para o URI de aprovação do sistema de RH para verificar se o link é malicioso; mas, ao fazê-lo, aprova a licença do empregado.

    Isso viola a especificação técnica relevante e as melhores práticas.

    De RFC7231 :

    Os métodos de solicitação são considerados "seguros" se sua semântica definida for essencialmente somente leitura; ou seja, o cliente não solicita e não espera nenhuma mudança de estado no servidor de origem como resultado da aplicação de um método seguro a um recurso de destino. Da mesma forma, não se espera que o uso razoável de um método seguro cause qualquer dano, perda de propriedade ou carga incomum no servidor de origem.

    Get é uma solicitação segura e idempotente de acordo com o mesmo padrão. O que o Outlook faz é explicitamente permitido de acordo com o padrão:

    Dos métodos de solicitação definidos por esta especificação, os métodos GET, HEAD, OPTIONS e TRACE são definidos como seguros.

    O objetivo de distinguir entre métodos seguros e inseguros é permitir que processos de recuperação automatizados (spiders) e otimização de desempenho de cache (pré-busca) funcionem sem medo de causar danos. Além disso, permite que um agente de usuário aplique restrições apropriadas no uso automatizado de métodos inseguros ao processar conteúdo potencialmente não confiável.

    Seu aplicativo de RH está quebrado e deve ser atualizado.

    • 2

  3. Depois de um pouco mais de experimentação, acho que encontrei o motivo.

    Todos os URIs que não têm problemas incluem querystrings; aquele com quem tivemos um problema não.

    Enviando um teste para https://example.com/approve?try=this em vez de ver o URI exato retornado nos logs do meu site, vi que a GETsolicitação foi enviada para https://example.com/approve?try=bcce; ou seja, a parte do valor do par nome-valor na querystring foi substituída por um valor de lixo. Dito isso, esse comportamento não foi consistente em meus testes / não tenho certeza de quais regras o MS segue sobre quando substituir valores e quando deixá-los.

    Parece que outros já acertaram isso antes; há muita discussão boa neste tópico .

    Do ponto de vista do cliente, a melhor solução é colocar o URL na lista de permissões para que o SafeLinks não o verifique. Mais informações em MS Docs .

    • 0

relate perguntas