Este es un problema de seguridad con el que me he encontrado un par de veces al crear pequeños proyectos basados en web que interactúan con un servicio API REST. Por ejemplo, supongamos que está creando un juego informal basado en JavaScript en el que desea una tabla de clasificación de puntajes más altos, por lo que debe publicar los puntajes de los usuarios en una base de datos.
La solución más sencilla sería construir un servicio web simple, por ejemplo, usando PHP, Node.js o Python, que acepte la solicitud GET y guarde los resultados en una base de datos. Imaginemos que la API se ve así:
GET https://www.example.com/api/highscore?name=SuperGoat31&score=500
La creación de una API de este tipo para publicar puntuaciones altas tiene algunos inconvenientes obvios. Un usuario malintencionado podría escribir un fragmento de código PHP de tres líneas para enviar spam a la base de datos llena de resultados falsos, por ejemplo:
for ($i = 0; $i < 100; i++) { file_get_contents("https://www.example.com/api/highscore?name=SuperGoat31&score=5000000"); }Entonces, estoy buscando una manera de prevenir eso. Esto se relaciona principalmente con pequeños proyectos de pasatiempos o hackatones que solo necesitan algún tipo de protección que prevenga los ataques más obvios, no aplicaciones de grandes empresas que necesitan una seguridad estricta. Un par de cosas que se me ocurren:
1. Alguna forma de autenticación
Una forma obvia de resolver esto sería tener cuentas de usuario y solo permitir solicitudes de usuarios registrados. Desafortunadamente, esto tiene el inconveniente de poner una gran barrera para los usuarios, que primero necesitan obtener una cuenta. También requeriría crear un flujo de trabajo de autenticación completo con recuperación de contraseña y encriptación adecuada de contraseñas y similares.
2. Protección basada en token de una sola vez
Genera un token en el lado del servidor y sírvelo al usuario en la primera carga, luego solo permite solicitudes que sirvan ese token específico. Bastante simple, pero también muy fácil de eludir encontrando las solicitudes en un inspector web del navegador y usándolo para el script PHP de tres líneas.
3. Registrar direcciones IP y prohibir cuando ocurra un uso malicioso
Esto podría funcionar, pero siento que no es muy amigable con la privacidad. Además, el registro de direcciones IP requeriría el consentimiento de GDPR de los usuarios en Europa. Tampoco evita el envío de spam en sí mismo, por lo que primero debe limpiar el desorden antes de comenzar a prohibir las direcciones IP.
4. Usa un servicio externo
Existen servicios que brindan soluciones a este problema. Por ejemplo, en el pasado usé reCAPTCHA de Google para evitar el uso malicioso. Pero eso también significa integrar un servicio externo, asegurarse de mantenerlo actualizado, preocupaciones sobre los aspectos de privacidad (especialmente con respecto a un servicio como reCAPTCHA), etc. Parece demasiado para un proyecto de fin de semana.
5. Solicitudes de aceleración
Siento que esta es probablemente la solución más fácil que realmente funciona por un tiempo. Esto requiere alguna forma de registro de direcciones IP (lo que podría generar los problemas mencionados en 3), pero al menos puede eliminar esas direcciones IP bastante rápido después.
Pero estoy seguro de que hay otros métodos que me he perdido, por lo que me gustaría ver otras formas de abordar este problema.
Teniendo en cuenta todas las limitaciones mencionadas, recomendaría usar una combinación de métodos:
Ejemplo:
let req_obj = { user: 'SuperGoat31', score: 123456, sessionId: '4d2NhIgMWDuzarfAY0qT3g8U2ax4HCo7', }; req_obj.hash = someCustomHashFunc(JSON.stringify(req_obj)); // now, req_obj.hash = "y0UXBY0rYkxMrJJPdoSgypd" let req_string = "https://www.example.com/api/cmd?name=" + req_obj.user + "&data=" + Buffer.from(JSON.stringify(req_obj)).toString('base64'); // now, your requests will look like that: "https://www.example.com/api/cmd?name=SuperGoat31&data=eyJ1c2VyIjoiU3VwZXJHb2F0MzEiLCJzY29yZSI6MTIzNDU2LCJzZXNzaW9uSWQiOiI0ZDJOaElnTVdEdXphcmZBWTBxVDNnOFUyYXg0SENvNyIsImhhc2giOiJ5MFVYQlkwcllreE1ySkpQZG9TZ3lwZCJ9"Para los jugadores ocasionales, esto les permite comenzar a jugar muy rápidamente, ya que no se requiere un registro explícito. Tras la generación, el token puede guardarse como cookie para uso repetitivo, pero esto no es necesario, también sería suficiente con un solo uso. No se recopila información personal.
Sin embargo, si el almacenamiento a corto plazo de cierta información del cliente es una opción, el token puede ser no solo algunos bytes aleatorios, sino una cadena cifrada que contiene algunos parámetros, como sal aleatoria + dirección IP + apodo + ID de agente + etc. En este caso, puede comenzar a ignorar silenciosamente ciertas solicitudes de clientes fraudulentos al detectarlo.
Obviamente, esto sería muy fácil de descifrar para un profesional, pero ese no es nuestro objetivo. Cuando métodos tan simples se mezclan con varios kilobytes de lógica del juego y se ofuscan, descubrir cómo manejarlo requeriría una cantidad significativa de conocimiento y tiempo, lo que podría servir como una barrera suficiente.
Como se trata de un equilibrio entre comodidad y protección, puede implementar una lógica de puntuación adicional para detectar intentos de trampa, como que la puntuación final no puede terminar en '0' o no puede ser par, etc. Esto le permitiría contar los intentos de trampa (en además de contar las solicitudes falsificadas) y luego estimar la eficiencia de la combinación de métodos implementada.
Su lista de soluciones son principalmente mitigaciones, y son buenas ideas si son sus únicas herramientas. La lista parece bastante exhaustiva.
2 formas principales de resolver este problema son:
Es posible que para su caso específico ninguna de las dos sea posible, pero si no puede adoptar ninguna de estas estrategias, está atrapado en mecanismos de detección imperfectos.
Sospecho que una solución perfecta será esquiva porque dos de sus deseos son, quizás, contradictorios:
"Necesitas publicar las puntuaciones de los usuarios en una base de datos", pero... "prevenir los ataques más obvios" sin "algún tipo de autenticación".
Los ataques más obvios son los de los usuarios sin algún tipo de autenticación.
Desea que este sistema funcione sin imponer una carga indebida a sus usuarios. Desea evitar la autenticación habitual de inicio de sesión y contraseña, que puede resultar engorrosa para los usuarios.
Creo que hay una manera de lograr lo que desea al crear una forma muy simple de autenticación mediante el uso de una protección basada en un token de una sola vez. Y también incorporaría el seguimiento de IP contra el abuso. En otras palabras, combinemos sus opciones 1, 2 y 3 de la siguiente manera.
Ya ha dado a entender que mantendrá una base de datos y que, dentro de la base de datos, los nombres de usuario serán únicos (de lo contrario, no podría registrar puntuaciones altas únicas). Permita que las personas se registren libremente enviando el nombre de usuario solicitado, que aceptará si alguien no lo usó anteriormente. Realice un seguimiento de las solicitudes de registro por dirección IP para detectar y evitar abusos: demasiados registros desde una dirección IP en un período de tiempo determinado. Hasta ahora, la carga recae en el servidor, no en el usuario.
Cuando procesa un registro válido (es decir, un nuevo nombre de usuario) en la base de datos, también generará, registrará en la base de datos y devolverá al usuario un secreto compartido (un token) que será utilizado por el basado en el tiempo. -algoritmo de contraseña de tiempo (TOTP).
No reinventes esto.
Ver:
Cuando devuelva un token al usuario, tendrá la forma de un "Código QR"
que el usuario escaneará y almacenará con su "Google Authenticator" o aplicación TOTP equivalente.
Cuando el usuario regrese a su sitio web para actualizar su puntuación más alta, se autenticará usando su Google Authenticator" o una aplicación TOTP equivalente. Estos se usan a menudo para la autenticación de "segundo factor", 2FA ( autenticación de múltiples factores ), pero debido a su necesidad de una seguridad menos estricta, utilizará la autenticación TOTP como la principal y única forma de autenticación.
Por lo tanto, hemos combinado una forma de autenticación que no representa una carga muy alta para el usuario (aplicaciones que ya están ampliamente disponibles y en uso), con protección basada en token de una sola vez (proporcionada por la aplicación TOTP) y un poco de IP protección contra abusos basada en la dirección para los registros iniciales.
Una de las debilidades de mi propuesta es que un usuario puede compartir su token TOTP con otra persona, que luego puede hacerse pasar por él. Pero esto no es diferente del riesgo de compartir contraseñas. Y no habrá opción de "recuperar mi contraseña perdida".