No puedes. Es desafortunado, pero no puedes. Cualquier cosa que se esté ejecutando como cliente (salvo en algunas situaciones en las que es casi seguro que no involucra a TPM) puede, si alguien está suficientemente motivado, ser comprendido por completo. Alguien puede desmontarlo, emularlo, parchearlo, no hay prácticamente nada que puedas hacer al respecto.

Lo que debe hacer no es autenticar al cliente, sino autenticar al USUARIO. Mire OAuth2 / OpenID Connect / similar: haga que inicien sesión con gmail o facebook antes de usar su aplicación. Si se trata de un proceso en segundo plano, permítales registrarse en su sitio web (utilizando oauth2, etc.) para obtener un apikey. Ese apikey es único para ellos, te los identifica, así que si ves abuso, puedes vincularlo a su gmail / facebook / lo que sea.

Si no puedes hacer esto, bueno, entonces estás estancado con solo hacerlo más difícil. Puedes esperar que no estén lo suficientemente motivados para descompilar tu aplicación y obtener tu algoritmo hash, pero a la larga, eso no es un juego ganador.

HashCash

Podría incorporar una prueba de trabajo en el sistema: use algo como HashCash para requerir que el usuario dedique, por ejemplo, 1 segundo de tiempo de CPU a enviar un mensaje a su servidor. Este sistema podría ser tan simple como requerir que el usuario envíe un nonce con el mensaje, de modo que cuando el nonce y el mensaje se combinen, finalice con 5 0. Habrá una compensación: si la aplicación de su cliente utiliza un 1% de CPU, entonces su oponente podrá enviar 100 veces más mensajes que un usuario normal, lo que puede ser demasiado. Si su cliente utiliza 100% de CPU, su oponente solo podrá enviar la tasa normal de mensajes, pero sus usuarios reales se sentirán molestos.

Por lo tanto, el sistema completo tendría un aspecto similar al siguiente:

Cliente:

Genere la solicitud GET de la misma manera que la genera actualmente, pero con un campo adicional llamado Nonce. Hash la solicitud GET, y ver si termina en x número de ceros. Si no termina en x ceros, elija aleatoriamente un nuevo Nonce e intente nuevamente. Si lo hace, envíelo al servidor.

Servidor:

Solo acepte las solicitudes GET que, cuando se utiliza el hash, terminan en el número correcto de ceros. Además, solo acepte las solicitudes GET con marca de tiempo en los últimos cinco minutos, mantenga una tabla de las solicitudes GET recientemente aceptadas y verifique que cada solicitud solo se acepte una vez

Limitador de velocidad, simple y simple.

Debe determinar qué tan importante es el servicio. Si es un servicio del que depende su aplicación, debe tener implementada la seguridad. Podría tomar la forma de que el usuario inicie sesión a través de su navegador y luego guarde un archivo en su directorio de inicio. Su aplicación luego leerá la clave api del archivo y firmará todas sus solicitudes con él.

Si se trata más de un tipo de servicio analítico, entonces no tiene mucha opción. Incluso Google Analytics contendrá datos de spam en él. Primero enfócate en reducir la cantidad de spam antes de intentar eliminarlo por completo. Si alguien está enviando más de 5 solicitudes por minuto desde una IP, bloquéelas temporalmente. Primero instituye una prohibición de 5 minutos, luego 15, luego continúa. Cuando se elimine una IP, regístrela y marque las otras entradas que se hicieron justo antes de ella, y debería poder filtrar la mayor cantidad posible de datos de bots. Si fueras más lejos y mantuvieras tu sitio detrás de un servicio como Cloudflare, podrías usar su API para bloquear la dirección IP, asegurándote de que la solicitud ni siquiera llegue a tu servidor después de que esté prohibida.

Sin embargo, si el "usuario troll" tiene acceso a un bot-net lo suficientemente grande, incluso las las grandes empresas son susceptibles

Aceptar solo un envío por dirección IP no es una solución muy efectiva, ya que las direcciones IP no están vinculadas estáticamente a las personas. La toma de huellas dactilares del dispositivo (especialmente cuando se combina con otros enfoques como Evercookies y ASN) proporciona un mejor indicador de quién está detrás de la dirección IP. Hay una discusión de lo que parece para ser el mismo problema aquí . Sin embargo, la forma en que aplicaría la huella digital a una aplicación es bastante diferente de un navegador.

Sin embargo, lo que falta en la discusión allí y también en esta pregunta es cualquier descripción del valor en el servicio, ni el impacto de las personas que envían solicitudes múltiples cuando solo se espera que realicen una. Considere este sitio. Cualquiera puede registrarse para obtener una cuenta, pero no tenemos el derecho de cambiar los envíos de otras personas sin probar que podemos agregar valor al servicio en su totalidad. Las acciones se atribuyen y todos tienen la oportunidad de mostrar su [des] aprobación y comentarios. Wikipedia tiene un enfoque similar, pero más formal para la gestión de contenidos. Una forma muy efectiva de lidiar con los ataques de amplificación sloloris y dns es simplemente tener la capacidad de manejar la carga adicional sin que esto afecte a los demás usuarios. Hay límites para lo que es capaz con este enfoque, pero si el único impacto aquí es el almacenamiento adicional, agregar más capacidad no es tan costoso (pero está limitado por su elección de un servidor de SQL).

Si la característica definitoria de un ataque es una alta tasa de envíos desde la misma dirección IP o en relación con la misma cuenta, entonces tiene una base para detectar el comportamiento automáticamente y reducir el impacto en su sitio al tratarlos de manera diferente - p.ej simplemente respondiendo con un valor aleatorio en lugar de hash y almacenamiento.

Si proporcionó más información sobre cómo la actividad de esta persona afecta su sitio y la naturaleza del servicio, tal vez podamos ofrecerle consejos más específicos sobre una estrategia más amplia.

Noté que mencionaste en un comentario que las IP son similares. Si este es el caso, puede prohibir el rango de IP que parece estar usando.

Si está dedicado, puede usar IP fuera de ese rango. Como dijeron los expertos, la mejor solución es autenticar al usuario, usando algo como gmail, facebook o SMS.

Puede requerir que el cliente haga un trabajo, como lo sugiere QuadmasterXLII con HashCash. Solo asegúrese de que el cliente está haciendo mucho más trabajo que el servidor y que el trabajo solicitado por usuarios no malintencionados es aceptable.

O puedes pelear una batalla continua de parches para estar un paso adelante. Estas son las opciones que veo en el orden en que las probaría.

Sugerencia general: cualquier cosa que ponga en el cliente, puede simular.

  

Usaría algo así como un captcha, pero es solo un hilo de fondo que habitualmente envía la solicitud de obtención, no hay interacción del usuario con ella.

Pero a menos que esté creando un virus, alguien lo configura intencionalmente. En ese momento, puede hacer que registren al cliente e ingresen un CAPTCHA como parte del proceso. (Por ejemplo, cada cliente obtiene un token de sesión del servidor, que solo almacena si el CAPTCHA se completó correctamente).

No hay un número infinito de direcciones IP que se puedan usar. En IPv4, querrá prohibir las direcciones IP utilizadas por un spammer y marcar su subred. En IPv6 querrá prohibir /64 s y marcar su subred.

Por ejemplo, si 80.100.131.150 te enviaba correo no deseado, prohibirás esa dirección y marcarás 80.100.0.0/15 (en Linux whois 80.100.131.150 | grep ^route te mostrará). A menudo, las direcciones IP de los hogares se rotan todas las noches y los propietarios de VPS pueden asignar una nueva (ya sea seleccionando una o al azar), pero el ISP posee un número finito de subredes. De esta manera, obliga al spammer a tomar medidas para actualizar la dirección IP, y una vez que lo hagan, probablemente aún estarán en una subred marcada.

Las subredes con indicadores obtienen CAPTCHA adicionales. No uno sino cinco CAPTCHAs al registrarse (o algo así). Una vez que una subred colecciona dos o tres banderas, prohíbelas por completo. Puntos de bonificación si envía por correo electrónico la dirección de abuso de la subred.

Hay más recursos finitos con los que puedes hacer esto, como las direcciones de correo electrónico. Un pequeño esfuerzo para que los usuarios activen su dirección de correo electrónico, pero un spammer se cansará cuando tenga que ingresar veinte CAPTCHAs porque tanto su subred como su dominio de correo electrónico (por ejemplo, mail.ru) tienen marcas.

Tenga en cuenta que habrá bajas. Cualquier persona que use el mismo ISP como spammer también será expulsado (una vez que haya recopilado suficientes banderas).