Você já reparou sucessos vadios para suas páginas web que não têm parâmetros?

Question

Nós temos uma aplicação web que transmite parâmetros na URL ao longo das linhas deste:

www.example.com/ViewCustomer?customer=3945

Razoavelmente, muitas vezes, veremos tentativas de acesso apenas:

www.example.com/ViewCustomer

Ou sistema registra este como inválido e envia de volta um "Ocorreu um erro, contate o suporte com o número de rastreamento XXX" tipo de página.

Nossos registros incluem as informações da sessão para que ele realmente é alguém logado com uma sessão válida que significa que eles assinaram com sucesso com um nome de usuário e senha.

Pode ser que acabou de digitar isso na barra de endereços, mas parece ocorrer com muita freqüência para isso. Outra alternativa é que temos um bug no nosso código, mas nós investigamos e às vezes há apenas um ponto e é claramente ok. Nós nunca tivemos um usuário reclamar sobre algo não trabalhar e resultando em isso. Tudo está sob SSL.

Tem mais alguém experimentou este? Faça alguns navegadores enviar esses tipos de pedidos desonestos ocasionalmente?

Editar: Nossos registros mostram o seguinte:

 user-agent = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)

Answer 1

Agora eu acho que isso foi realmente um bug tomcat getParameter () falhar no POST com transfer-Encoding:. fragmentada

Answer 2

fazer seus registros incluem as informações de referência? Se há qualquer informação presente, então ele poderia ajudar a identificar o erro. Se não houver, que poderiam indicar uma "edição do URL" tentativa. (Eu não sei o quanto SSL mudaria nada disso, na verdade.)

Navegadores fazer às vezes prefetch ligações mas eu não sei se eles se livrar do parâmetro - e parece improvável que eles fariam isso por HTTPS

.

Você tem um padrão a respeito de que os navegadores estão sendo usados ??para esses pedidos?

Answer 3

Eu já vi isso com a aplicação web estamos apoiando - um pedido GET de rua fora do azul para um já registrado no usuário, destruindo o estado do lado do servidor e resultando em um erro na posterior solicitação POST legítimo.

Uma vez que no nosso caso, os URLs usar URL-reescrever anexando idsessão à URL como GETs também às vezes têm idsessão de idade.

No arquivo de log específico que levam a pregar esta questão estes pedidos vadios teve a diferente seqüência do agente (embora válido) do resto na mesma sessão.

Estou convencido de que em vez do próprio navegador é algum plugin / extensão. Há uma possibilidade de que um proxy faz isso ou até mesmo malware.

Nós superamos esse problema específico proibindo solicitações GET para a URI em questão.

No entanto, agora estou lidando com um problema semelhante em que um pedido POST aparece do nada onde não deve e que a única diferença é a "aceitar" cabeçalho.

Answer 4

Verifique os seus registos para a seqüência do agente e ver se estes pedidos são feitos por uma aranha motor de pesquisa.

Answer 5

Eu sei que às vezes eu remover o parâmetro apenas para verificar o que está lá. Eu tenho certeza que não sou o único.

Answer 6

Alguns rastreadores desonestos mudar o user-agent para páginas agente de usuário e de rastreamento de um navegador. Isso também pode ser um caso tal.

Também a maioria dos rastreadores tente substituir alguns outros valores aos parâmetros de consulta para buscar páginas que não foram vinculados.