OWASP TOP10 - #10 Unvalidated Redirecionamentos e Encaminhamentos

Question

Eu li muitos artigos para este tópico, incluindo o OWASP PÁGINA e o Blog do Google artigo sobre redirecionamentos abertos...
Eu também achei essa pergunta em redirecionamentos abertos aqui no estouro de pilha mas é um diferente

Eu sei por que eu não deveria redirecionar ...isso faz totalmente sentido para mim.

Mas o que eu realmente não entendo:Onde é exatamente a diferença entre redirecionando e colocando isso em um normal <a href o link?
Talvez alguns usuários estão procurando na barra de status, mas acho que a maioria deles não estão realmente olhando para a barra de status, quando eles klick um link.
Esta é realmente a única razão?como este artigo eles escreveram:

<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a>

O usuário pode assumir que o link é seguro, uma vez que a URL começa com o seu banco de confiança, bank.example.com.No entanto, o usuário será redirecionado para o web site do intruso (attacker.example.net) o que o invasor pode parecer muito semelhante ao bank.example.com.O usuário pode, em seguida, que, involuntariamente, digite as credenciais para a página da web do invasor e comprometer sua conta bancária.Um servlet Java nunca deve redirecionar o usuário para uma URL, sem verificar que o endereço de redirecionamento é um site confiável.

Então, se você tem algo parecido com um livro de visitas, onde o usuário pode colocar o link para sua página inicial, em seguida, a única diferença é que o link não for redirecionado, mas ele ainda vai para o mal página web.

Eu estou vendo este problema, certo?

Answer 1

No meu entendimento, não é que o redirecionamento é o problema.O principal problema aqui é a de permitir um redirecionamento (onde o destino é potencialmente controlável pelo usuário) que contém uma url absoluta.

O fato de que a url é absoluta (o que significa que começa http://host/etc), significa que você está onu-intencionalmente permitindo cruz-domínio redirecionamentos.Isso é muito semelhante ao clássico vulnerabilidades de XSS qual o javascript pode ser refletida para fazer chamadas entre domínios (e fuga de seu domínio de informações).

Então, como eu entendo, de forma a corrigir a maioria destes tipos de problemas é certificar-se de que qualquer redirecionamento (no servidor) é feito em relação à raiz.Então não há nenhuma maneira para que o usuário controlado valor de cadeia de consulta ir para outro lugar.

Isso responde a sua pergunta ou apenas criar mais?

Answer 2

O principal problema é que o seu possível para um atacante para fazer o URL parecem ser dignos de confiança, como é, na verdade, uma URL para o web site a vítima confia, eu.e. bank.example.com.

A redirecionar o destino não precisa ser óbvio, como no exemplo.Na verdade, o atacante irá provavelmente utilizar outras técnicas para enganar o usuário e, possivelmente, até mesmo o aplicativo da web, se necessário, com especial codificações, parâmetro pollutioning, e outras técnicas para falsificar um URL legítimo.

Assim, mesmo se a vítima é tão preocupada com a segurança para verificar a URL antes de clicar em um link ou solicitando a sua recurso, caso contrário, todos eles se pode verificar é que o URL aponta para o confiável site bank.example.com.E só isso é o suficiente muitas vezes.