¿Has notado visitas perdidas a tus páginas web que no tienen parámetros?

Question

Tenemos una aplicación web que pasa parámetros en la URL a lo largo de estas líneas:

www.example.com/ViewCustomer?customer=3945

Razonablemente a menudo, veremos intentos de acceso solo:

www.example.com/ViewCustomer

O el sistema registra esto como no válido y devuelve un " Se ha producido un error, póngase en contacto con el servicio de asistencia técnica con el número de seguimiento XXX " escriba la página.

Nuestros registros incluyen la información de la sesión, por lo que en realidad es alguien que inició sesión con una sesión válida, lo que significa que ha iniciado sesión correctamente con un nombre de usuario y contraseña.

Podría ser que simplemente escribieron eso en la barra de direcciones, pero parece ocurrir con demasiada frecuencia para eso. Otra alternativa es que tenemos un error en nuestro código, pero lo hemos investigado y, a veces, solo hay un lugar y está claramente bien. Nunca hemos tenido un usuario quejándose de algo que no funciona y que resulta en esto. Todo está bajo SSL.

¿Alguien más ha experimentado esto? ¿Algunos navegadores envían este tipo de solicitudes poco fiables ocasionalmente?

Editar: nuestros registros muestran esto:

 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

Ahora creo que esto fue realmente un error de Tomcat getParameter () falla en POST con codificación de transferencia: fragmentada .

Answer 2

¿Sus registros incluyen la información de referencia? Si hay alguna información presente, entonces podría ayudar a identificar el error. Si no lo hay, eso podría indicar una " edición de la URL " intento. (No sé cuánto SSL cambiaría nada de esto, ciertamente).

Los navegadores a veces prefetch links pero no sé si se eliminarían del parámetro, y parece poco probable que hagan esto para HTTPS.

¿Tiene un patrón sobre qué navegadores se utilizan para estas solicitudes?

Answer 3

He visto esto con la aplicación web que estamos respaldando: una solicitud GET perdida de la nada para un usuario que ya inició sesión, que destruye el estado del lado del servidor y da como resultado un error en la solicitud POST legítima posterior.

Dado que en nuestro caso las URL usan la reescritura de URL adjuntando sessionid a la URL, tales GET a veces también tienen una sesiónid anterior.

En el archivo de registro específico que condujo a resolver este problema, estas solicitudes extraviadas tenían la cadena del agente diferente (aunque válida) del resto en la misma sesión.

Estoy convencido de que, en lugar del navegador en sí, es algún complemento / extensión. Existe la posibilidad de que un proxy lo haga o incluso de malware.

Superamos este problema particular al prohibir las solicitudes GET al URI en cuestión.

Sin embargo, ahora estoy lidiando con un problema similar en el que una solicitud POST aparece de la nada donde no debería y la única diferencia está en el " aceptar " encabezado.

Answer 4

Verifique en sus registros la cadena del agente y vea si estas solicitudes las realiza una araña del motor de búsqueda.

Answer 5

Sé que a veces elimino el parámetro solo para verificar qué hay allí. Estoy seguro de que no soy el único.

Answer 6

Algunos rastreadores corruptos cambian el agente de usuario al agente de usuario de un navegador y rastrean páginas. Esto también puede ser un caso así.

Además, la mayoría de los rastreadores intentan sustituir algunos otros valores a los parámetros de consulta para obtener páginas que no estaban vinculadas.