Asegurar una API para el acceso móvil

Su pregunta es "¿Se puede detener esto?", pero tengo la sensación de que cualquier cosa importante sobre el sistema no se puede / no cambiar realmente.

Si entiendo correctamente, estás preguntando (simplificado):

  

Tengo muchos clientes que comparten el mismo nombre de usuario y contraseña. ¿Puedo detener el mal uso?

La respuesta es no . Debe decidir si puede permitirse ignorar el problema o implementar soluciones correctas.

Si realmente desea hacer esto correctamente, intente implementar algo como OAuth, para poder distribuir correctamente los tokens de autenticación separados para los usuarios finales, vincularlos a sus clientes para la facturación, revocar el acceso, etc.

-

Lo menos que debe hacer es permitir que sus clientes (las compañías) opten por usar un mejor esquema de autenticación. Así, por ejemplo, creas una API para que soliciten (y revoquen) tokens de acceso separados para sus usuarios finales.

• La compañía A solicita el token de sus servidores (esto se inicia cuando la aplicación les dice "dame un token")
• Usted devuelve el token N, registra a qué compañía está asociada
• Si la aplicación de la Compañía A-s se conecta a su servicio, envía el token N, y no el nombre de usuario / contraseña
• La Compañía A puede decirle a su servicio que "revoque el token N", y su servicio no atenderá a otras solicitudes con ese token. Pero, si se revoca un token, no se volverán inutilizables todas las aplicaciones cliente.

Si una empresa no desea hacer esto, aún pueden continuar conectándose con su nombre de usuario / contraseña, pero serían completamente responsables de todo el uso resultante.

El punto es que realmente no se puede responsabilizar a sus clientes por la pérdida de credenciales (algo que es imposible de hacer en un escenario de aplicación móvil) si no tienen otra forma de usar el servicio.

Así que espero tener esto correcto. ¿Desea una forma segura de confirmar la identidad de un cliente utilizando una clave API válida? Creo que el almacenamiento seguro de la clave API es en gran parte responsable de la compañía que desarrolló la aplicación y no de su compañía.

Necesitará cifrar y ofuscar la clave para protegerla del pirata informático informal, pero no creo que pueda evitar a un pirata informático determinado. Podría hacer un poco de piratería para hacer que el binario sea más difícil de depurar, lo que puede reducir las posibilidades de que su aplicación flote en Internet. Sin embargo, esto no es una seguridad absoluta y, a menos que su empresa esté desarrollando las aplicaciones de forma interna, ¿cómo puede aplicar tales medidas?

Entonces, como respuesta a su escenario, no, no creo que pueda detenerse de manera efectiva sin ser perjudicial para la experiencia de los usuarios. Puede educar a las empresas utilizando su API; reúna un pequeño manual para ellas y asegúrese de que quede claro que es su su responsabilidad mantener su su clave de api segura.

Por su parte, también podría implementar algunas funciones de mitigación. Por ejemplo:

1. Permitir que las empresas definan sus propios límites estrictos. Digamos que la compañía A sabe que el mes pasado tuvieron descargas de N aplicaciones y, por lo tanto, desean limitar su acceso a su API a X solicitudes por día u hora.
2. Supervise los picos en las solicitudes por compañía por período de tiempo.
3. Defina un paso de los procedimientos que se producirían en posibles actividades fraudulentas.
4. Vuelva a escribir, vuelva a escribir y vuelva a escribir.

El objetivo en caso de falla (le pasa a lo mejor) es minimizar el daño.

Buena suerte.

Tienes razón al ser escéptico acerca de que tus clientes incorporen su nombre de usuario / contraseña en una aplicación móvil que entregan a todos sus usuarios. Como lo ha identificado correctamente, sería fácil para un atacante desarmar esa aplicación móvil, extraer el nombre de usuario / contraseña de la aplicación móvil y usarla en su propia aplicación. Desafortunadamente, su cliente es el que decide si hacer eso, pero el costo se le impone. Entonces, esto es una externalidad, y necesitará alguna forma de hacer que los costos, riesgos e incentivos estén mejor alineados. Tengo algunas sugerencias a continuación sobre cómo hacer eso.

En general, veo dos soluciones plausibles para esto:

• Transferencia de riesgo. Para cada cliente, imponga un límite a la cantidad de solicitudes que aceptará de ese cliente. Indique a los clientes que es su responsabilidad mantener seguro su nombre de usuario / contraseña, que todas las solicitudes que lleguen con este nombre de usuario / contraseña se contabilizarán en función de su límite, y si llegan demasiadas solicitudes, su cuenta puede estar deshabilitada. Dígales que si incrustan su nombre de usuario / contraseña en una aplicación móvil, existe el riesgo de que alguien nefasto pueda robar el nombre de usuario / contraseña y usarlo para realizar muchas solicitudes, lo que provocará que su cuenta se desactive y que su aplicación móvil deje de funcionar . Déjelos decidir si quieren o no correr el riesgo.

• Requisitos contractuales. Dígales a sus clientes que tienen prohibido compartir su nombre de usuario / contraseña con otros, y no está permitido que incrusten su nombre de usuario / contraseña en aplicaciones que puedan ser descargadas por otros. Dígales que si detecta alguna violación de esta política, su cuenta puede estar deshabilitada y se les puede facturar los costos que esto impone a sus servidores.

  Si sus clientes desean crear una aplicación móvil, dígales que, en lugar de insertar su propio nombre de usuario / contraseña en la aplicación móvil, deben enviar un proxy de tales solicitudes a su propio servidor. En otras palabras, el cliente debe configurar un servidor que sepa el nombre de usuario / contraseña del cliente, pero este nombre de usuario / contraseña no debe estar incrustado en la aplicación móvil. La aplicación móvil del cliente debe autenticarse en el servidor del cliente, enviar una solicitud al servidor, y luego el servidor debe reenviar la solicitud y reenviar la respuesta a la aplicación móvil. Su servidor debe autenticar al usuario final (por ejemplo, requiere que cada usuario final de la aplicación móvil cree una cuenta en su servidor, con su propio nombre de usuario / contraseña). Su servidor debe imponer límites de ancho de banda para cada usuario y deshabilitar la cuenta de cualquier usuario final que exceda esos límites.

También puede permitir que los clientes elijan entre estas dos opciones: por ejemplo, entre una cuenta de ancho de banda limitado (con transferencia de riesgo) o una cuenta de ancho de banda ilimitado (con el requisito de no incrustar el nombre de usuario / contraseña en las aplicaciones que son accesible a otros).

Espero que esto tenga sentido. Esto puede ser un poco confuso, porque hay tres partes: usted, su cliente y el usuario final de su cliente, cada uno con sus propios intereses e inquietudes. Espero haber distinguido adecuadamente entre los tres.

Uno de los problemas que creo que enfrentará en el frente móvil es la validación de la dirección IP. Por lo general, las direcciones IP móviles asignadas por la empresa de telecomunicaciones serán neteadas. La IP en la red hará que el mecanismo de validación de IP adoptado en el lado del servidor no tenga uso.

Para implementar la solución en Android y Iphone; Creo que el enfoque debería ser:

1. Haga que la autenticación del servidor del cliente en modo SSL se extienda también a la validación del certificado del cliente. Me refiero a dejar que el cliente y el servidor utilicen certificados para establecer una sesión segura de SSL.
2. Entregue el PFX / P12 que contiene el certificado del cliente (móvil) de tal manera que requiera un PIN y una combinación de números IMEI e IMSI. De esta manera será difícil para un atacante repudiar la misma sesión.
3. Pida que se implemente algo de inteligencia artificial en el servidor que detecte dos o más sesiones simultáneas iniciadas utilizando el mismo certificado de cliente, lo que le permitirá saber que ha ocurrido algún compromiso y que el servidor puede incluir o revocar inmediatamente el certificado para su uso posterior.

Creo que aunque estábamos discutiendo sobre el entorno móvil; Además de la validación de IP, los riesgos también están presentes en el entorno de PC. En el futuro, también puede adoptar o migrar a la implementación basada en la firma y en el certificado del cliente en el entorno de PC, si tiene problemas de facturación incorrectos planteados por los clientes.

El fraude es muy importante y no se puede solucionar solo con una implementación técnica, pero si ha implementado una validación y bloqueo de IP escalados, no hay nada de qué preocuparse. Tampoco debe dar las credenciales reales a sus clientes (B2B). Déjame explicarte por qué y cómo.

Desde mi comprensión de lo que ha escrito, ya se han aplicado los conceptos y las implementaciones de seguridad básica a media en relación con el lado B2B (YOURCOMPANY - YOURCLIENT). Eso es bueno. Validación de IP, SSL / TLS, Usuario / Pase, etc. Ahora, le preocupa que las credenciales de API utilizadas por sus clientes para entregar aplicaciones móviles a los usuarios finales puedan ser defectuosas de una manera que un usuario final de terceros podría aprovechar estas credenciales si la aplicación móvil de su cliente ha sido explotada de alguna manera.

Básicamente se reduce a una serie de capas de seguridad. La pregunta es cómo su empresa ha diseñado e implementado estas capas.

1. Su SERVIDOR JSON / REST API debe contener sus credenciales reales. Si está prestando un servicio y requiere una conexión con un proveedor / operador de red, también puede encontrar esas credenciales aquí. Sabes a lo que me refiero.

2. No le dé a YOURCLIENT acceso directo al JSON / REST API SERVER. En su lugar, necesita un host de salto que sirva como host para el entorno de confianza, el servidor API desde donde reside su aplicación JSON / REST debería autentificarse SOLAMENTE con este servidor mediante la validación / bloqueo de la dirección IP. Autenticación de servidor a servidor mediante IP o pares de claves públicas / privadas. Es su discreción qué usar.

Este servidor también debe actuar como un servicio web que contiene un conjunto de nombre de usuario / contraseñas que luego se asigna a sí mismo a un archivo de configuración y pasa la solicitud al JSON / REST API SERVER. Ahora, YOURCLIENTS debería tener acceso a este servidor sobre la base de la validación / bloqueo de IP también y protegido mediante HTTPS. El concepto es que no se pueden encontrar credenciales de usuario / pase reales aquí, excepto por la clave / secreto que se asigna al API SERVER.

1. YOURCLIENT puede tener una implementación de seguridad desde su lado hasta los usuarios finales. Puede ser en forma de par de clave pública / privada PKI para desarrolladores o 2FA para usuarios normales. YOURCLIENT debe implementar estos pasos, no su empresa.

Ahora, por ejemplo, un desarrollador externo (usuario final) explotó una falla en una aplicación móvil creada por uno de YOURCLIENT y obtuvo sus credenciales:

1. inútil. En cuanto a que para utilizar las credenciales, se validará su IP.
2. No válido. En cuanto a que debe haber sido autenticado mediante un par de claves pública / privada.
3. La técnica de escalamiento de privilegios requerirá que él explote el servidor real para poder confiar.
4. La explotación del servidor real requiere técnicas elaboradas que ralentizarán la motivación del atacante.
5. No hay un ataque exitoso que haya terminado la motivación.

La ofuscación es buena y ralentiza un ataque, pero es la menor forma de seguridad. Deberías confiar mejor en crypto que usa claves.

Recuerde, no existe una solución de seguridad absoluta aparte de su esfuerzo continuo por combatir el fraude desde una perspectiva de seguridad técnica y operativa.

La protección de sus datos en transmisión con SSL ya ha cubierto el ataque de intermediario. Las contraseñas codificadas en el código fuente no son de ninguna manera una práctica segura. No debe preocuparse por la dirección IP de los usuarios o IMEI. No hablemos de seguimiento e intentemos arreglar las cosas en primer lugar.

Como dijiste, estás usando REST. Pocas cosas deberían ayudarte, espero.

1. Autentica a los usuarios desde el lado del servidor. Mantener gestiones de sesión estrictas para que no pueda ser falsificada. Echa un vistazo a OWASP para esto.
2. Haz una prueba fuzz para tu API. ReST es conocido por pocas vulnerabilidades. Por favor, explore en Internet y conozca la mayoría de los errores conocidos en ReST. Parche esos problemas para su API.
3. Su SSL es bueno porque protege sus datos en el medio.

No te preocupes por tu código fuente. Se puede arrancar de todas formas pero está bien. Sus funciones principales se ejecutarán en el servidor y solo pasarán las respuestas a los clientes. Mantenga todas las cosas buenas en el lado del servidor.