Por que os dados trocados entre meus dois aplicativos da Web usando redirecionamento com parâmetros de consulta ou postagem automática de formulário não podem ser confiáveis para cada aplicativo da Web, mesmo ao usar HTTPS?
Observação:
Entendo que a troca de dados usando parâmetros de consulta apresenta riscos de segurança inerentes, como CSRF, vazamento de dados por meio do histórico do navegador e logs de acesso , e auto-form-post apresenta riscos de segurança inerentes de CSRF . Contudo, esse não é o ponto de discussão aqui. Vamos supor que mitigamos o CSRF. A questão em questão é: "Por que cada aplicação web não pode confiar nos dados trocados, mesmo com HTTPS?"
Caso de uso: considere dois aplicativos da web em execução em https://one.abc.com e https://two.xyz.com . Ambos desejam trocar dados, mas não conseguem se comunicar diretamente.
Fluxo detalhado: ao visitar https://one.abc.com , uma página exibe um botão. Quando clicado, ele é enviado para https://one.abc.com e redirecionado para https://two.xyz.com . Em https://two.xyz.com , existe outro botão que, ao ser clicado, envia para https://two.xyz.com e redireciona para https://one.abc.com .
Como tudo ocorre em HTTPS, todos os elementos, incluindo URLs, parâmetros de consulta e cabeçalhos, são criptografados durante o redirecionamento.
Com esta configuração, a troca de dados entre os dois aplicativos da web pode ser alcançada usando parâmetros de consulta ou postagem automática de formulário.
No entanto, por que cada aplicação web não pode confiar nos dados trocados, mesmo com HTTPS?
Em termos mais simples, durante a primeira etapa, se https://one.abc.com
enviar dados usando redirecionamento com parâmetros de consulta ou auto-form-post para https://two.xyz.com
, https://two.xyz.com
não será possível confiar que os dados realmente se originaram de https://one.abc.com
, mesmo quando HTTPS for usado.
Da mesma forma, durante a segunda etapa, se https://two.xyz.com
enviar dados usando redirecionamento com parâmetros de consulta ou auto-form-post para https://one.abc.com
, https://one.abc.com
não será possível confiar que os dados realmente se originaram de https://one.abc.com
, mesmo quando HTTPS for usado.
A técnica acima é usada em SAML, OIDC para SSO.
Por favor, deixe-me saber se meu seguinte entendimento está correto:
No fluxo de redirecionamento descrito de one.abc.com
e two.xyz.com
para one.abc.com
, a criptografia TLS (Transport Layer Security) é estabelecida separadamente entre seu navegador e cada servidor envolvido. Vamos decompor o fluxo:
De one.abc.com
para two.xyz.com
:
- Ao clicar no botão
one.abc.com
, seu navegador inicia uma solicitaçãoone.abc.com
via HTTPS (HTTP sobre TLS). one.abc.com
responde com uma resposta de redirecionamento (HTTP 302 encontrado) instruindo seu navegador a acessartwo.xyz.com
.- Seu navegador então inicia uma nova solicitação HTTPS para
two.xyz.com
, estabelecendo uma conexão TLS separada entre seu navegador etwo.xyz.com
.
De two.xyz.com
volta para one.abc.com
:
- Ao clicar no botão
two.xyz.com
, seu navegador inicia uma solicitaçãotwo.xyz.com
via HTTPS (HTTP sobre TLS). two.xyz.com
responde com uma resposta de redirecionamento (HTTP 302 encontrado) instruindo seu navegador a acessarone.abc.com
.- Seu navegador então inicia uma nova solicitação HTTPS para
one.abc.com
, estabelecendo uma conexão TLS separada entre seu navegador eone.abc.com
.
Cada uma dessas conexões (do navegador para two.xyz.com
e do navegador para one.abc.com
) é criptografada usando TLS de forma independente. A criptografia TLS garante a confidencialidade e integridade da comunicação entre o seu navegador e cada servidor, protegendo os dados trocados durante o fluxo de redirecionamento.
No entanto, não há nenhuma ligação TLS direta estabelecida entre two.xyz.com
e one.abc.com
durante o fluxo de redirecionamento. Em vez disso, as conexões HTTPS são encerradas e restabelecidas separadamente em cada terminal do servidor.
Por esse motivo, no SAML, o IDP assina o SAML assertion
e no OIDC, o Provedor OIDC assina id_token
.
Você não pode confiar em nenhum dado passado de um cliente (potencial invasor).
Essencialmente, um redirecionamento faz com que um cliente mude de servidor. Dependendo da aplicação, os dados podem ser transferidos pelo usuário .
Se não houver maneira de verificar esses dados, um invasor poderá falsificá-los. Da mesma forma, um referenciador que você pode usar para verificar o redirecionamento é outro dado que pode ser falsificado sem esforço.
Usar criptografia com HTTPS não muda isso. HTTPS criptografa dados entre um cliente e um servidor, mas não verifica a origem desses dados. Um invasor entre cliente e servidor não pode ler ou alterar os dados passados, mas se o invasor for o cliente, o SSL não ajudará em nada.
Métodos confiáveis exigem uma troca segura de dados entre servidores ou assinatura criptográfica dos dados transmitidos pelo cliente.