Tenemos un servicio web que registra / registra los datos del usuario enviados a través de https por nuestra aplicación cliente. ¿Hay alguna forma de garantizar de forma segura que la aplicación cliente envíe los datos y no una herramienta falsa que se hace pasar por nuestra aplicación? Idealmente, no me gustaría tener que recurrir a cosas como esconder una clave confusa en el cliente u otras técnicas de "seguridad a través del secreto" ...
No puedes. Un servidor fundamentalmente no puede confiar en un cliente (hay algunas excepciones: si la máquina cliente está fortalecida (el hardware verifica el firmware, el firmware verifica el sistema operativo, el sistema operativo verifica cada aplicación que se ejecuta), es posible hacer eso (pero no realmente, alguien) con un soldador siempre se podría modificar la verificación del hardware), pero si no controla al 100% al cliente, no tiene suerte.
Debe preguntarse: ¿Cuáles son los riesgos de que el cliente cargue datos falsos? ¿Cuáles son las consecuencias de no autenticar que es la aplicación su que carga los datos? Una pregunta difícil que debe hacer: ¿Tiene el cliente un incentivo para cargar datos falsos? Si el usuario no tiene un incentivo para cargar datos falsos, probablemente no se molestarán.
Una cosa que puede hacer: puede autenticar al usuario que ejecuta la aplicación (a través de cualquiera de varios mecanismos de autenticación) y luego guardar los datos cargados junto con la ID del usuario autenticado (y Dirección IP). De esa manera, si el usuario carga datos falsos, puede rastrear quién realizó el cambio. Por supuesto, ahora ha creado la PII de datos que puede tener problemas de privacidad para su servicio.
Es necesario autenticar al cliente, y eso requiere que exista algún tipo de secreto. Si un usuario humano controla el cliente, es posible que solo pueda registrarse y autenticar al usuario, utilizando algún secreto que conozcan o tengan acceso.
Si el cliente está automatizado y usted no controla el entorno de hardware y software en el que se basa, no tendrá suerte ante un atacante determinado que tiene el control del cliente. Pero puedes hacerlo difícil.
Su problema parece estar relacionado con el problema general de las licencias de las aplicaciones cliente, y aquí encontrará una buena descripción general de un enfoque (para aplicaciones de Android, en Java):
Puede adaptar eso a su entorno o buscar otras bibliotecas de código abierto adecuadas a su situación.
Por cierto, la "seguridad a través del secreto" está bien, los secretos como las claves privadas son parte de la mayoría de los buenos esquemas. Es la "seguridad a través de la oscuridad" lo que las personas intentan evitar, es decir, simplemente complicar las cosas o pretender que los atacantes no entienden sus algoritmos.
Si echa un vistazo a las 10 leyes de seguridad inmutables , la ley # 3 explica El problema a nivel fundamental:
Ley # 3: si un malvado tiene acceso físico sin restricciones a tu computadora, ya no es tu computadora
Puede utilizar kerberos para realizar una autenticación mutua entre el cliente y el servidor. Preferiblemente, tendría algún método fuera de banda para identificar inicialmente al cliente, por ejemplo. Emisión al usuario con un identificador. por supuesto, ahora confías en que ese identificador no se vea comprometido ...
Como dijeron los demás, no puedes confiar en un cliente hasta que el cliente se autentique con un certificado que TÚ creaste. En este momento, todo el problema se reduce a un problema de distribución clave / certificado:
Hasta que se respondan estas preguntas (¡correctamente!), todos los demás eventos posteriores a la autenticación son discutibles.
Lea otras preguntas en las etiquetas authentication appsec client-side