Solicitudes HTTP "duplicadas" impares

2

Una operación GET de HTTP duplicada inesperada activó un informe de "evento inusual" en mi sitio web. El duplicado provino del sitio web "Trendmicro.com" que parece estar en el negocio de la seguridad en Internet. Es solo mi suposición, pero sospecho que recopilan consultas de muestra en nombre de sus clientes, luego las envían ellas mismas y realizan algún tipo de análisis sobre los resultados.

Esto generalmente es inocuo, pero me pregunto cuáles serían las implicaciones para cualquier tráfico que tenga efectos secundarios, si el servidor no es consciente de que puede aparecer otra solicitud similar.

Por ejemplo, en mi caso, la solicitud estaba destinada a actualizar una base de datos de clasificación de usuarios y el duplicado activó una alerta de piratería. Sin la verificación, la actualización se habría producido dos veces.

editar: También es relevante que la solicitud "original" se originó a partir de una IP en Australia, y que el "Duplicado" llegó unos segundos más tarde, desde una IP localizada en San Francisco. Hubo un centenar de solicitudes HTTP en la sesión, pero solo 2 o 3 fueron duplicadas.

    
pregunta ddyer 26.07.2013 - 20:23
fuente

3 respuestas

4

Trend Micro es un jugador bastante grande en seguridad (bueno, al menos he oído hablar de ellos).

Uno de sus productos es una barra de herramientas del navegador para advertir a los usuarios de sitios web maliciosos. Estoy de acuerdo con tu conjetura, que están obteniendo páginas que su barra de herramientas ha visto que sus usuarios obtienen, por lo que pueden decidir si es malicioso.

Aquí hay una pequeña información sobre la araña de Trend Micro: enlace

Lo ideal sería que solo reprodujeran las solicitudes GET, y Las solicitudes GET deberían ser idempotentes (no tienen efectos secundarios). Si sus datos de usuario se modifican como resultado de una solicitud GET, entonces recomendaría cambiarlos a un POST. No solo el robot Trend Micro, sino que cualquier robot o motor de búsqueda podría aparecer y hacer un GET en cualquier enlace y provocar un resultado no deseado para usted.

    
respondido por el davidwebster48 28.07.2013 - 14:08
fuente
3

El problema depende totalmente de lo que se pretende que haga el servidor. Un "ataque de repetición" es un enfoque antiguo y bastante válido para atacar casi cualquier sistema o protocolo. Subir el rango de un usuario es un uso bastante bueno, ya que sin duda cambiaría el estado del sistema y beneficiaría a alguien. ¡Comprar dos pedidos con la tarjeta de crédito de alguien sería aún peor!

Es algo que debe tenerse en cuenta en el diseño de un sistema. Cosas que he visto usadas como preventivas:

  • tiempo de espera antes de repetir: el sistema hace que una cuenta determinada espere un cierto tiempo antes de repetir una acción (Stack Exchange lo ha hecho en algunos lugares)
  • que requiere un nonce, cuando se utilizan firmas digitales. - si solicita realizar una actualización, mi servidor le brinda una parte única de datos sin sentido, usted envía su solicitud y los datos y los firma todos. No te permitiré enviar el mismo fragmento de datos sin sentido dos veces: tienes que preguntar, firmar, enviar una y otra vez, lo que requiere que las credenciales del usuario estén disponibles.
  • privacidad punto a punto: mantiene al hombre en el medio afuera
respondido por el bethlakshmi 26.07.2013 - 21:13
fuente
3

La pista aquí es donde dices que recibiste una solicitud GET duplicada. El resto de su pregunta casi me desvió del camino, pensando que algún cliente (u otro servidor en su nombre por cualquier motivo) duplicó las solicitudes de POST , o incluso duplicó los encabezados de solicitud completos (cookies, e.t.c.). Pero lo que describe también puede leerse como "se solicitó la misma URL" .

De todos modos, la razón más común para duplicar las solicitudes GET proviene de lo que se conoce como servidores proxy de almacenamiento en caché . Algunos de estos productos pueden detectarse aparentemente sin compatibilidad con la compresión ( gzip , deflate , ...) que se muestra en sus registros como solicitudes duplicadas, pero el tamaño de la respuesta será mayor, como ProxySG de Blue Coat System (al parecer uno de los principales actores en el negocio de dispositivos proxy). Otros pueden cambiar la cadena User Agent en consecuencia para identificarse ante los administradores web que leen los registros de acceso, los firewalls de aplicaciones web, etc., y algunas solicitudes repetidas completamente sinónimo a las solicitudes originales, y solo el IP address puede diferir, incluso si (si el cliente lo usa el proxy también como puerta de enlace, entonces el IP address permanecerá exactamente igual, y las solicitudes repetidas seguirán los encabezados de caducidad de la memoria caché de los contenidos solicitados).

Estos caching proxies pueden ser un poco molestos a veces (vea, por ejemplo, este despojo en Las soluciones de Blue Coat System ), pero no se consideran como una amenaza de seguridad en particular. Bueno, al menos no de manera diferente que con todos los demás servidores proxy: al final del día, son Men in El medio y los hosts no confiables pueden considerarse extremadamente riesgosos para los usuarios finales. Sin embargo, muchas redes las utilizan por varios motivos, como el almacenamiento en caché local para reducir las necesidades de ancho de banda de los hosts remotos, acelerar los tiempos de respuesta e incluso almacenar en caché múltiples copias antiguas de los documentos a los que se accede. Y, en cierto sentido, Google es el mayor proxy que conocemos. Lo que estoy diciendo es que no hay ninguna indicación de que la solicitud que describió se haya duplicado con intenciones maliciosas, y tales duplicaciones de solicitudes no deberían causar ningún problema en el extremo de su servidor (además de un acaparamiento de ancho de banda innecesario ocasional), si sus aplicaciones web están escritas correctamente, para volver a autorizar a los usuarios cuando sea necesario y utilizar otros medios para identificar usuarios individuales que los parámetros GET request URI (como cookies , que los proxies de almacenamiento en caché no malintencionados no deben adjuntarse a sus solicitudes duplicadas de almacenamiento en caché) propósitos).

No estoy diciendo que lo que sucedió no fue un intento malicioso, lo que digo es que lo que usted describe no lo prueba de ninguna manera, y también podría haber sido un visitante benigno de la variedad de proxy de almacenamiento en caché.

    
respondido por el TildalWave 26.07.2013 - 21:16
fuente

Lea otras preguntas en las etiquetas