Verificar los datos creados del lado del cliente

2

Tengo un applet de Java, que registra toda la pantalla del usuario y carga las imágenes al servidor.

Si alguien pudiera (y mucha gente podría, lo sé) falsificar la grabación de pantalla, podrían engañar a los usuarios legítimos del sistema con su dinero, por lo que hay incentivos.

He estado leyendo un poco sobre este tema y parece que cualquier intento de validación del lado del cliente es bastante inútil, es decir. Confiar en el cliente está fuera de discusión. La ofuscación y tal solo crean un inconveniente para los usuarios malintencionados, no un obstáculo.

Este problema se resuelve parcialmente con una función que se me ocurrió, que permite al sistema asegurarse de que la grabación sea auténtica hasta cierto punto. Después de ese punto en el tiempo, sin embargo, se vuelve ambiguo nuevamente. Después de ese punto, el pirata informático podría sobrescribir las funciones de mi applet y subir capturas de pantalla falsas. O podría cambiar los monitores de su computadora, donde el nuevo monitor tiene una pantalla falsa pero de aspecto idéntico, programas abiertos, etc.

De alguna manera, necesito estar 99.9% seguro de que la grabación es auténtica.

Hasta ahora he encontrado algo como esto: Registre todos los tiempos / tasas de carga de todas las capturas de pantalla de todos los usuarios y luego, si se sospecha que alguien está haciendo trampa, compare las tasas de carga con otros usuarios, especialmente antes y después del posible "cambio" / "sobrescritura". el código ralentiza ligeramente la aplicación o cambiar de monitor crea un retraso anormal.

** La pregunta es: ¿es válida mi teoría? **

    
pregunta Markus Pint 28.12.2014 - 13:25
fuente

3 respuestas

1

Parece que su aplicación se ejecuta principalmente en el lado del cliente porque el servidor solo recibe esas imágenes. Por lo tanto, tiene muy pocos datos en los que puede confiar. Esto hace que sea muy difícil tenerlo a prueba de manipulación, o poder detectar la manipulación de datos.

Supongamos que espera que un cliente no controlado cargue imágenes cada segundo en el servidor. Suponiendo que la manipulación tarda medio segundo, se espera que las imágenes manipuladas se carguen cada segundo y medio, pero el cliente manipulado puede comenzar a procesar antes y aún alcanzar la velocidad de carga de 1 segundo. No puede confiar en las marcas de tiempo proporcionadas por el cliente porque también pueden ser falsificadas.

Dijo que podía confiar en las tasas de carga de los otros usuarios para establecer un patrón de tasas de buenos conocimientos, pero ¿qué pasaría si un atacante o atacante superara a los usuarios legítimos? Hay un problema teórico difícil sobre esto. Un ingeniero de Google describió el difícil problema de la detección de correo no deseado basado en informes de usuarios y sistemas de construcción que podrían resistir ataques de sybil .

    
respondido por el Cristian Dobre 28.12.2014 - 16:13
fuente
0
  

De alguna manera, necesito estar 99.9% seguro de que la grabación es auténtica.

Necesitas expectativas más realistas.

Lo que estás tratando de hacer no funcionará:

  • los datos de temporización del lado del cliente son, para la mayoría de los estados, completamente dependientes de que el cliente no juegue con ellos, y pueden, pero también el O.S. no elegir ese punto en el tiempo para hacer las cosas; vastas porciones del tiempo del cliente pueden alterarse, o son lo suficientemente frágiles como para generar falsos positivos cuando son "legítimos". Keyloggers y puntos de referencia de rendimiento ... piense de esta manera. Sus márgenes de error de O.S. las tareas en segundo plano varían en el tiempo por márgenes mayores que los umbrales de lo que esperas detectar, no puedes esperar tener éxito en eso.

  • su código se ejecutará en el lado del cliente. Eso significa que puede ser revertido. Si hay suficiente dinero en él, puede llamar la atención de algunos de los grupos que son lo suficientemente buenos como para revertir el código complicado cualquiera en cuestión de horas: estas habilidades han sido un efecto secundario de las armas de malware. -ropa que hemos tenido durante décadas donde la industria del malware ha estado luchando batallas similares contra usted y ha tenido mucha práctica.

  • los paquetes que le envían la sincronización del lado del cliente pueden ser alterados, y si hay suficiente dinero, lo serán. Los trucos de cifrado / ingeniosos elevan un poco el listón, pero es solo más ofuscación que puede ser derrotado, y si hay dinero en juego, lo será.

Por otra parte, si logra superar los problemas anteriores, felicidades, ha superado uno de los mayores desafíos en informática moderna ... que valdría unos pocos miles de millones.

    
respondido por el pacifist 29.12.2014 - 04:22
fuente
0

¿Qué datos necesita que se envíen exclusivamente como una "imagen" del cliente al servidor?  Lo que necesitas es alguna señal de advertencia de que alguien está jugando con tus datos, así que envía más que solo un 'screengrab'. envíe los datos de más de una forma (y use conexiones TLS), por lo que una imagen se envía como un archivo de imagen binario y como un conjunto de valores en bruto que produce dicha imagen.

agregue algunas "marcas" a su captura de pantalla que no sean fáciles de ver. pero agregue una marca de "autenticación" a ella. (que incluye el HASH de la propia imagen).

Agregue un sistema de desafío / respuesta a su servicio de carga (por lo que CADA carga debe tener una respuesta a un desafío específico, que cambia para CADA solicitud)

de esa manera, al menos puedes asegurarte de saber algunas cosas de tu "cliente" y puedes comparar valores y evitar la repetición de

Sin embargo, su objetivo de + 90% no es alcanzable por estos medios. cualquier cosa por encima del 75% es una ilusión (y el 75% ya es alto) todo lo que puede asegurarse es que todas las solicitudes que se están realizando están registradas y acreditadas para que pueda corregirlas después de la acción si se trata de juego sucio.

    
respondido por el LvB 29.12.2014 - 11:23
fuente

Lea otras preguntas en las etiquetas