Como faço para evitar ataques de repetição?

Question

Isto está relacionado com a outra pergunta que eu fiz.Em resumo, eu tenho um caso especial de uma URL, e quando um formulário é Postado nele, eu não dependem de cookies para a autenticação ou para manter a sessão do usuário, mas de alguma forma eu preciso saber quem eles são, e eu preciso saber o que está conectado!

Eu acho que surgiu uma solução para o meu problema, mas ele precisa de explicitação.Aqui está o que eu estou pensando.Eu crie um campo de formulário oculto chamado "nome de usuário", e coloque dentro dele o nome do usuário encriptada.Em seguida, quando o formulário POSTs, apesar de eu não receber quaisquer cookies do navegador, eu sei que eles estão registrados no porque eu pode descriptografar o campo de formulário oculto e obter o nome de usuário.

A grande falha de segurança eu posso ver é a repetição de ataques.Como faço para impedir alguém de obter o ahold de que a cadeia de caracteres criptografada, e Postando como usuário?Eu sei que eu posso usar SSL para torná-lo mais difícil de roubar essa cadeia de caracteres, e talvez eu possa girar a chave de criptografia em uma base regular para limitar a quantidade de tempo que a cadeia é bom, mas eu realmente gostaria de encontrar uma solução à prova de balas.Alguém tem alguma idéia?O ASP.Net ViewState evitar a repetição?Se sim, como eles fazem isso?

Editar:Eu estou esperando por uma solução que não exige nada armazenados em um banco de dados.O estado do aplicativo ficaria bem, exceto que ele não vai sobreviver uma reiniciar o IIS ou o trabalho em um web farm ou para o jardim cenário.Estou aceitando Chris resposta, por agora, porque eu não estou convencido de que é mesmo possível para proteger esta sem um banco de dados.Mas se alguém vem com uma resposta que não envolvem o banco de dados, eu vou aceitar!

Answer 1

Se você hash do carimbo de data / hora, juntamente com o nome de usuário e senha, você pode fechar a janela para ataques de repetição para dentro de um par de segundos.Eu não sei se este atende às suas necessidades, mas é pelo menos uma solução parcial.

Answer 2

Se você realmente não quiser armazenar qualquer estado, eu acho que o melhor que você pode fazer é limitar ataques de repetição usando carimbos de data / hora e um curto tempo de expiração.Por exemplo, o servidor envia:

{Ts, U, HMAC({Ts, U}, Ks)}

Onde Ts é o carimbo de data / hora, U é o nome de usuário e Ks é o servidor de chave secreta.O usuário envia de volta para o servidor, e o servidor valida por recomputing o HMAC nos valores fornecidos.Se for válida, você sabe quando foi emitido, e pode optar por ignorá-lo se ele é mais velho do que, digamos, 5 minutos.

Um bom recurso para esse tipo de desenvolvimento é O que Fazer e o que Não fazer de Autenticação de Cliente na Web

Answer 3

Há várias boas respostas aqui e colocá-los todos juntos é onde a resposta finalmente, encontra-se:

1. De bloco de cifra de encriptação (AES-256+) e hash (com SHA-2+) de todos os estados/nonce relacionadas com a informação que é enviada a um cliente.Hackers com outra apenas manipular os dados, exibi-la e aprender os padrões e ignorar tudo o resto.Lembre-se ...ele só tem uma janela aberta.

2. Gerar um tempo aleatório e exclusivo nonce por que o pedido é enviado de volta com o pedido POST.Isto faz duas coisas:Ele garante que, após a resposta vai com esse pedido.Ele também permite o rastreamento de um tempo de uso de um determinado conjunto de get/POST pares (o que evita a repetição).

3. Use carimbos de data / hora para fazer o nonce piscina gerenciável.Loja de carimbo de data / hora em um cookie criptografado por #1 acima.Jogar fora todas as solicitações mais antigas do que o tempo máximo de resposta ou de sessão para a aplicação (por exemplo, uma hora).

4. Armazenar um "razoavelmente única" impressão digital " da máquina, fazendo o pedido com o encriptado carimbo de data / hora dados.Isto irá impedir outro truque em que o atacante rouba os clientes cookies para realizar a sessão de seqüestro.Isto irá assegurar que o pedido está voltando não só uma vez, mas da máquina (ou perto o suficiente de proximidade a tornar praticamente impossível para o atacante para copiar) o formulário foi enviado.

Há ASPNET e Java/J2EE filtro de segurança de aplicações baseado no que fazer todos os itens acima com zero de codificação.Gerenciando o nonce piscina para sistemas de grande porte (como a negociação de ações da empresa, banco ou de alto volume site seguro) não é um empreendimento trivial se o desempenho é crítico.Recomendo olhar os produtos versus tentando programa para cada aplicativo da web.

Answer 4

Você poderia usar algum tipo de tarefa aleatória de seqüência de caracteres que é usado juntamente com o nome de utilizador para criar o hash.Se você armazenar a seqüência de desafio no servidor em uma base de dados em seguida, você pode garantir que é usado apenas uma vez, e apenas para um usuário em particular.

Answer 5

Em um dos meus aplicativos para parar de 'replay' ataques de eu ter inserido informações de IP para o meu objeto de sessão.Toda vez que eu acesso o objeto de sessão no código de eu ter certeza de passar o Pedido.UserHostAddress com ele e, em seguida, compare para certificar-se de que o IPs correspondentes.Se não, então, obviamente, alguém mais que a pessoa que fez esse pedido, assim que eu retornar null.Não é a melhor solução, mas pelo menos é mais uma barreira para impedir ataques de repetição.

Answer 6

Você pode usar a memória ou um banco de dados para manter qualquer informações sobre o utilizador ou pedido?

Se é assim, então, a pedido, para a forma, eu gostaria de incluir um campo de formulário oculto, cujo conteúdo é um número gerado aleatoriamente.Salvar este token no contexto de aplicação ou algum tipo de armazenamento (um banco de dados, televisão de arquivo, etc.) quando a solicitação é processada.Quando o formulário é enviado, verifique o contexto de aplicação ou banco de dados para ver se esse número gerado aleatoriamente ainda é válida (no entanto, você definir válido - talvez ele pode expirar após X minutos).Se sim, remova esse token da lista de permitidos "tokens".

Assim, qualquer repetidos pedidos inclua esse mesmo token, que não é mais considerado válido no servidor.

Answer 7

Eu sou novo para alguns aspectos de programação web, mas eu estava lendo sobre isso outro dia.Eu acredito que você precisa para usar um Nonce.

Answer 8

(Ataques de repetição pode ser facilmente tudo sobre um IP/MAC spoofing, além de você está posta em causa com IPs dinâmicos )

Não é apenas a repetição do que você está aqui, no isolamento, é sem sentido.Basta usar SSL e evitar o trabalho manual qualquer coisa..

ASP.Net o ViewState é uma bagunça, evite-o.Enquanto PKI é pesado e inchado, pelo menos ele funciona sem inventar sua própria segurança 'esquemas'.Então, se eu pudesse, eu iria usá-lo e ir sempre para a mútua authent.Apenas para o servidor de autenticação é completamente inútil.

Answer 9

O ViewState inclui a funcionalidade de segurança.Ver este artigo sobre alguns dos build-in dos recursos de segurança ASP.NET .Ele faz a validação contra o servidor machineKey na máquina.configuração no servidor, o que garante que cada postback é válido.

Mais abaixo, no artigo, você também ver que, se você deseja armazenar valores em seus próprios campos ocultos, você pode usar o LosFormatter classe para codificar o valor da mesma forma que o ViewState usos para a criptografia.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Answer 10

Se você aceitar apenas uma vez cada tecla (por exemplo, a chave de um GUID e, em seguida, verifique quando ele volta), para evitar repetições.É claro que, se o atacante responde primeira, e , em seguida, você tem um novo problema...

Answer 11

É este WebForms ou MVC?Se é MVC você pode utilizar o AntiForgery token.Este parece que é semelhante à abordagem que você menciona, exceto que ele usa basicamente um GUID e define um cookie com o valor de guid para esse post.Para saber mais sobre o que ver Steve Sanderson blog: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Outra coisa, você já considerou a possibilidade de verificar o indicador sobre o postback?Este não é à prova de balas, mas pode ajudar.

Answer 12

Usar https...ele tem replay de protecção integrada.