¿Riesgos y estrategias para implementar el almacenamiento anónimo de tokens de Google Cloud Messaging?

1

Estoy escribiendo una aplicación móvil que agrega datos del clima y genera una notificación de inserción cuando se cumplen ciertos criterios. El usuario tiene la opción de cambiar algunas de las variables (por ejemplo, si la temperatura actual supera los X grados) que se almacenan tanto en el dispositivo como en mi servidor.

Cuando mi aplicación se abre, solicita el token GCM (o APN) y las variables definidas por el usuario y las envía a mi servidor a través de POST. El punto final se vería así (si fuera un GET):

https://api.example.com/registerPush.php?key=gcm_key_here&maxtemp=80&type=android

(obviamente type sería apple si fuera un dispositivo iOS)

En el extremo del servidor, registerPush.php toma las variables y las almacena (a través de sentencias preparadas ) en una base de datos MySQL. Al solicitante se le permite 1 registro por 10 segundos (determinado a través de sesiones de PHP) y si exceden eso, se quedan bloqueados durante 2 minutos, para evitar que un usuario intente enviar correo basura a la base de datos con entradas falsas.

Cada hora, un trabajo cron se ejecuta y recorre todos los elementos. Si la temperatura excede maxtemp , el token se agrega a una matriz y se envía de forma masiva a esos usuarios a través del método de inserción correcto (por ejemplo, GCM o APN).

Me gustaría mantener este sistema "anónimo" (es decir, no requerir que un usuario se registre), porque crear una cuenta simplemente para almacenar notificaciones push es un poco excesivo por la naturaleza simplista de mi aplicación, y otras cosas. como "Iniciar sesión con Facebook" son los mismos, porque ¿por qué un usuario debe iniciar sesión con Facebook solo para recibir notificaciones?

Por lo tanto, mi pregunta es, a pesar de los intentos de registro de aceleración a través de $_SESSION s, y tal vez almacenar la última vez que el token se envió al servidor (y eliminar tokens antiguos después de X muchas unidades de tiempo), ¿qué puedo hacer? para hacer que este sistema sea más seguro, en lugar de pedirle a la gente que cree una cuenta (para una aplicación meteorológica simple)

    
pregunta DrFrankly 03.07.2016 - 14:37
fuente

1 respuesta

1

Sugeriría usar String m_androidId = Secure.getString(getContentResolver(), Secure.ANDROID_ID);

Esto le dará una identificación única, que no requiere permisos, que solo cambia durante el restablecimiento de fábrica, y se puede usar para rastrear, por lo que nadie envía correo basura a la base de datos. También sugeriría hash con una clave específica de la aplicación.

Sin embargo, aún debe tener una limitación para evitar que alguien cree entradas maliciosas. Una buena idea podría ser requerir la resolución de un captcha para enviar una "nueva" cadena ANDROID_ID que no existe en la base de datos. Esto se puede resolver con un WebView y utilizando Google Recaptcha, al primer lanzamiento de la aplicación, combinado con una limitación basada en IP.

Recuerde que hay muchos clientes del operador de telefonía celular NAT detrás de una IP, así que guarde los registros con cuidado y si ve que la aplicación es popular y esté preparado para aumentar los límites del acelerador en caso de que su aplicación sea más popular.

Esto podría implementarse automáticamente al tener un AI, que comparará la tasa de solicitud mediana para todas las IP a una tasa específica, y solo se bloqueará si la tasa se considera más alta. La tasa de solicitud mediana es, en otras palabras, la tasa de solicitud que es el promedio de la tasa de solicitud de todas las IP, pero con las "bolas bajas" y las "bolas altas" eliminadas.

    
respondido por el sebastian nielsen 03.07.2016 - 16:21
fuente

Lea otras preguntas en las etiquetas