API - Problemas de diseño de seguridad

1

Estoy creando una aplicación de escritorio GUI que se comunicará con una API (http) en un servidor web.

En el lado del cliente tengo una aplicación de escritorio GUI y un módem GSM (hardware). La aplicación GUI Desktop realizará solicitudes a la API en el servidor web y obtendrá los SMS para enviar.

Mi pregunta aquí va sobre cómo puedo diseñar la aplicación para que los Clientes no hagan trampa al enviar solicitudes a la API en el servidor web, indicando que se envía el mensaje. ¿Alguien tiene alguna idea sobre cómo resolver este problema? El módem GSM que envía SMS está en un cliente que no es de confianza. ¿Ideas sobre cómo proteger una API que trata con este tipo de entorno? He estado leyendo sobre la prueba de trabajo, ¿este enfoque puede ayudar a resolver mi problema?

Saludos cordiales

    
pregunta André 31.10.2013 - 14:26
fuente

2 respuestas

2

Parece que desea proporcionar una aplicación que pagará a sus suscriptores para enviar mensajes SMS en su nombre. Pero como el envío de mensajes puede costarle a los clientes, cree que sus clientes pueden engañarle al afirmar que ha enviado el mensaje sin haberlo enviado realmente.

A menos que haya un componente criptográficamente confiable integrado en los módems GSM que pueda proporcionarle un informe firmado del estado, es probable que no haya forma de aplicarlo por medios criptográficos. Los clientes siempre pueden proporcionar sus propias implementaciones.

Por lo tanto, en lugar de eso, lo abordaría con una metodología de prueba aleatoria. Para cada cliente, su servidor podría decidir aleatoriamente cuándo enviar un mensaje a un receptor de confianza. Tal vez el mensaje de prueba se envía una vez de cada diez mensajes ordinarios, o un mensaje de cada 50, algo así. Tal vez usted construye las pruebas en una escala móvil. Para comenzar, uno de los primeros tres o cuatro es un mensaje de prueba, luego, a medida que continúan pasando las pruebas, usted reduce los requisitos de las pruebas. Si alguien está haciendo trampa, no recibirás el SMS y podrás investigar.

Tienes que ser cuidadoso en el diseño, por supuesto. Puede escribirlo en el acuerdo de EULA indicando a los clientes que el sistema enviará periódicamente mensajes de prueba y que puede cancelar su suscripción a su discreción. Pero no debes darles detalles de la metodología de prueba. Si sus clientes pueden saber exactamente qué mensajes son mensajes de prueba, aún pueden hacer trampa y solo responder a las pruebas. Por lo tanto, sus mensajes de prueba deben parecerse a los mensajes normales y deben ir a destinos de aspecto común. Y si un mensaje no llega, no debes decidir de inmediato que te han engañado, ya que hay muchos otros componentes que podrían haberse roto. Tendrías que investigar.

Una opción diferente sería requerir que los clientes presenten una prueba de envío en forma de una copia de su estado de cuenta. Los sistemas GSM registran cada destino de mensajes SMS. Tal vez usted podría hacer arreglos con los proveedores de GSM para auditar sus registros? Relacionado, quizás podría arrendarles los módems GSM y proporcionar las cuentas usted mismo, haciendo que los clientes le paguen por el servicio GSM.

    
respondido por el John Deters 31.10.2013 - 15:07
fuente
2

No puedes confiar en dispositivos que no son de confianza. Esta afirmación tautológica significa que el software que se ejecuta en el hardware controlado por el atacante puede ser inspeccionado y alterado por el atacante a voluntad; No existe ningún secreto que pueda ocultarse en dicho código, que el atacante no podrá aprender. No hay forma de garantizar que el código que llama a un servidor dado sea realmente "su" código, y no una versión modificada.

Una prueba de trabajo no ayuda. Las pruebas de trabajo están destinadas a resolver otro problema, es decir, el envío masivo de solicitudes: en esta configuración, reconocemos que la persona que llama puede haber sido alterada arbitrariamente por el atacante; pero la prueba de trabajo le permite al servidor garantizar que, al menos , el código del atacante tuvo que invertir una cantidad sustancial de potencia de cálculo para cada solicitud.

En su caso, su problema no es una cuestión de envío masivo de solicitudes, por lo que no se aplican las pruebas de trabajo. Su problema es que se supone que un componente que no es de confianza envía un SMS (con contenido definido) y luego le dice que lo hizo, y puede que se encuentre. Veo algunas soluciones posibles, ninguna de ellas realmente satisfactoria:

  • Podría usar para el cliente no confiable algún hardware dedicado a prueba de manipulaciones. Eso es lo que sucede con algunos terminales de pago : el terminal está protegido y se suicida cuando se abre su caso; por lo tanto, cualquier código que se ejecute en él puede ahora ser "confiable".

  • Reemplace el SMS con MMS . No estoy seguro de los detalles, pero aparentemente puede etiquetar un MMS para enviar a múltiples destinatarios, por lo que el código puede enviar el MMS tanto al destinatario deseado como a su servidor web; su servidor web luego verificará que el MMS recibido fue etiquetado como "para ser enviado" al destinatario deseado también. Por supuesto, esto genera muchas preguntas sobre la seguridad de esta característica de envío múltiple.

  • Haga que el usuario firme digitalmente su mensaje al servidor web donde se indica que se envió el SMS . De modo que si se descubre que el usuario no envió realmente el SMS, habrá pruebas de la deslealtad del usuario, para que pueda demandarlo. Esta "solución" consiste en evitar que los atacantes ataquen amenazándolos con fuertes represalias legales.

respondido por el Tom Leek 31.10.2013 - 15:10
fuente

Lea otras preguntas en las etiquetas