Cómo llamar al servicio web de forma segura en Android

Es simple. Nunca confíes en el cliente.

Nunca confíe en su negocio en almacenar secretos en el cliente que el usuario no debe saber.

No importa si se trata de Android, escritorio o lo que sea. A menos que esté preparado para asegurar su dispositivo como un cajero automático (atornillado a una pared en una caja fuerte con peso y cámaras por todas partes), el cliente no es de confianza. E incluso si está en un cajero automático, no confíe en el dispositivo.

  

Cómo asegurar que cualquier atacante no pueda obtener de ninguna manera mi CLAVE WEB API que definí en el archivo strings.xml

No puedes. Usted no necesita

Autenticación por usuario y por dispositivo. Los usuarios no deben compartir la misma clave API con nadie más, la clave API debe autenticar al usuario o la decisión del usuario en lugar del cliente.

Si está llamando a una API extranjera (por ejemplo, Twitter) para la cual toda su aplicación tiene una única clave de API, puede:

• Comparta su clave de API en su aplicación, un "secreto no secreto". Es una situación de mierda, y puedes ofuscar la clave un poco. Pero si es del lado del cliente, entonces no hay protección. Fin de la historia.
• Mantenga su clave de API en su servidor y las llamadas a la API de proxy. Solo asegúrese de que sus clientes se autentiquen en su servidor, o su servidor será abusado.

Si, en cambio, proporciona una API a la que espera que sus clientes llamen desde sus propias aplicaciones móviles, entonces se le ocurre algo más seguro. Una solución ideal es proporcionar a los implementadores una clave clave de API, una clave para que generen claves para usuarios individuales, en lugar de un único secreto compartido no secreto.

• La forma mejor entendida de hacer esto es crear una PKI. Emite certificados de "raíz confiable" para los desarrolladores de su aplicación en lugar de las claves API. Luego, a su vez, utilizan sus claves privadas para firmar certificados de usuario, cada uno de los cuales es válido para un solo usuario en una sola instalación. Estos pueden ser certificados de sesión a corto plazo (creados cuando el usuario "inicia sesión" en el servicio del desarrollador y válidos solo por un corto tiempo) o pueden ser a largo plazo (creados cuando el usuario instala la aplicación y válidos por un tiempo razonable). largo tiempo). Pero siempre que lo haga entender que el desarrollador es responsable del abuso por parte de cualquiera de sus usuarios y le da las herramientas para protegerse, puede dejarle elegir cuál de estas opciones tiene más sentido.

• Un enfoque conceptualmente similar es tomar los componentes de una PKI y usarlos por separado. Le da al usuario una "clave de desarrollador", que luego utiliza para firmar "claves de usuario" usando cualquier mecanismo conocido, desde las firmas RSA tan complejas como las más simples como concatenar la clave de desarrollador con una "clave de usuario" aleatoria y el resultado. . Esto puede ser más fácil para trabajar en su flujo de trabajo, pero también es más fácil equivocarse. Pero en cualquier caso, es probablemente más seguro que simplemente compartir la clave de la API de los desarrolladores con todos sus usuarios.