¿Cómo puedo prevenir una forma de ser presentado más de una vez en 5 minutos?

Question

Hace poco encontré un enorme problema de seguridad con mi sistema de PM que permite a los usuarios enviar un mensaje como todo lo que quieran con un bucle for en la barra de direcciones. Alguien puso esto en la barra de direcciones:

javascript:for(x=0;x<10000;x++){ $('#compose form').submit(); }

Y el mensaje fue enviado 1000 veces para mí y mi bandeja de entrada estaba lleno del mismo mensaje y mi base de datos era tan lleno que phpMyAdmin estaba siendo muy perezoso.

Mi pregunta es, ¿cómo puedo evitar esto? Se trata de un importante tema.

Además, se envía el formulario con AJAX.

Editar

Yo uso PHP, así que ¿cómo puedo evitar esto? Al igual que cómo podía llegar a donde un mensaje sólo se puede enviar cada 5 minutos o así, y si presentan más de un plazo de 5 minutos, se mostrará un error (o no mostrar ninguna respuesta de los usuarios en todo y simplemente dejar que se presenten )?

Answer 1

Hay una manera obvia para solucionarlo y el problema no se encuentra en el lado del cliente -. que se encuentra en el lado del servidor

El script servidor no debe permitir el envío de mensajes con demasiada frecuencia - por ejemplo. menudo que, por ejemplo, una vez cada 10 minutos. Para ello se puede utilizar sesión del mecanismo en el lado del servidor y guardar la información cuando el usuario envía el correo electrónico. Si el usuario no ha enviado un correo electrónico, también debe guardar esa información en la sesión -. Para distinguir las personas con sesión habilitadas de las personas con sesión con discapacidad (y se debe bloquear este último de envío de correos electrónicos en absoluto)

La sesión forma debe aplicarse (el código específico) depende del idioma que usa para scripts del lado del servidor (PHP, Python, JSP, etc.).

Answer 2

Si alguien tiene el conocimiento para hacer esto, es probable que no puede hacer nada en el lado del cliente por lo que la única opción que yo diría es que inicie sesión o mantener una cuenta, etc., de la cantidad de solicitudes (tal vez a un particular, de recursos) y negar la solicitud (o enviar un "ocupado" http código, etc.) para el usuario particular.

Creo que la forma más sencilla sería la de contar las peticiones de una dirección IP específica (esto obviamente tiene inconvenientes tales como múltiples usuarios detrás de un proxy o NAT, etc).

La solución real dependerá de su lenguaje del lado del servidor y del servidor web, pero que quizá podría enmarcar una regla y ver cómo funciona. Algo así como 5 solicitudes por minuto (o lo que sea apropiado para su uso) por dirección IP.

Answer 3

As others have said, you have to implement protection on the server. No amount of client-side coding will provide protection.

The common way of protecting a server against this type of abuse is called rate limiting. You decide how often you want a given client to be able to submit a message and you code the server to ignore any messages that fall outside that limit.

For example, you could decide that you will allow no more than one message a minute and no more than two messages every 10 minutes and no more than four messages an hour. You pick whatever you think seems reasonable and you code to that algorithm.

In your server, you'd have to be able to identify which user the message was coming from (most likely via an authentication cookie) and in your database, you'd have to be able to find out when the last message was sent by that user. You may even be able to cache that information in RAM in your server (depending upon how your server works) to avoid a database lookup on every request since you only have to keep recent info and you only need to performance optimize on the repeat offenders (the ones that are trying to abuse your server and thus just recently sent a request).

Answer 4

I agree with what everyone is posting about rate-limiting.

However, this can be very complicated to implement on the server side. Especially when you start scaling out. And, honestly, if 1000 messages hurt you that bad - my suggestion may apply to you even more so.

Instead of implementing this yourself, you may want to look into a third party service to do it for you, such as this super cool web services proxy Apigee

One of their features is, specifically, API rate throttling. (see link)