¿Hay alguna manera de evitar que alguien cree su propia aplicación de cliente para mi servicio web? [duplicar]

Esto sería imposible. Es fundamental que su aplicación contenga todas las instrucciones necesarias para utilizar su API. Cualquier persona con suficiente habilidad y tiempo podrá extraer estos secretos y crear su propio cliente.

Es bastante fácil y sencillo crear el propio cliente, independientemente de si se usa REST o SOAP, siempre que su Cliente existente esté disponible para todos en Play Store. Solo captura el tráfico HTTP desde un dispositivo Android usando Fiddler , e diseña tu propio cliente basado en el tráfico capturado.

Incluso el tráfico HTTPS puede fácilmente descifrado usando Fiddler . Los Métodos HTTP, URL, Encabezados, Cookies, Cuerpo y su Clave están todos visibles. No creo que esto sea seguro en absoluto. (Hay otros proxies inversos que pueden hacer lo mismo que Fiddler).

Desde una perspectiva de seguridad, no, no hay manera de hacer esto. No importa cuánta ofuscación le pongas al código y a los protocolos, el hecho es que el código para acceder a la API y el tráfico de red producido cuando se accede a la API está en manos de sus usuarios, y pueden usar cualquier herramienta de ingeniería inversa. quieren en él.

Desde una perspectiva empresarial, debe evaluar el costo para usted si alguien produce un cliente alternativo contra el costo adicional de implementar medidas para evitar que eso suceda. Por ejemplo, podría usar una API propietaria fuertemente ofuscada (evitando REST, SOAP y otros protocolos estandarizados) por completo, pero esto será más difícil de implementar y, por lo tanto, costará más. Por otro lado, sería mucho más difícil para alguien hacer ingeniería inversa. Debe calcular si tales medidas (u otras medidas apropiadas) valen la pena para su negocio.

Desde una perspectiva legal, muchos lugares tienen términos de servicio que prohíben la producción o el uso de clientes externos. Depende de usted hacer cumplir eso al monitorear el tráfico a su servidor para determinar si es probable que uno utilice un cliente de terceros, o al observar la aparición de clientes de terceros en las tiendas de aplicaciones. También depende de usted decidir si cuenta con los recursos para emprender acciones legales y si vale la pena que tome esas medidas.

Desde una perspectiva de relaciones con el usuario, es posible que desee reconsiderar la idea de prohibir a todos los clientes de terceros como una regla general. Obviamente, nadie quiere que un desarrollador produzca un cliente horrible con su propia publicidad, pero muchos servicios en estos días permiten a los desarrolladores externos registrar sus aplicaciones y recibir una clave de API. El proceso de registro puede ser tan simple o complejo como desee, desde los términos de uso simples (por ejemplo, "no ponga sus propios anuncios en la aplicación") hasta una evaluación de su interfaz o un examen completo de su fuente. código (por supuesto, cuanto más simple sea, más desarrolladores estarán dispuestos a inscribirse). Permitir que los desarrolladores de terceros utilicen su API tampoco es necesariamente malo, ya que es posible que deseen producir una aplicación que utilice su servicio como fuente de datos, pero que no esté relacionada con él de ninguna manera, y en ese caso podrían en realidad le ofrece más negocios si ponen la acreditación adecuada en su aplicación, o pueden querer llenar un mercado en el que su negocio no tiene intención de entrar, o pueden realmente tener una mejor idea para una aplicación de cliente para su servicio, que es algo de lo que puedes aprender para mejorar tu propia aplicación.

No puede hacer que el acceso no autorizado a la API sea imposible en el sentido de la seguridad, pero puede minimizarlo. No es realmente una pregunta de seguridad, pero el concepto del modelo de amenaza es bastante apropiado: ¿a quién quieres evitar que acceda a tu API y qué tipo de daño quieres evitar?

Muchos sitios web grandes prohíben medios alternativos de acceso a su servicio, generalmente para que puedan continuar publicando anuncios. Lo hacen a través de una combinación de medidas en muchos niveles:

• comprobar los encabezados de solicitud y el agente de usuario (lo que detiene a un gran número de usuarios normales ocasionales)
• complicando la API mediante la adición de estado dinámico, ofuscación y otras medidas (que detiene la ingeniería inversa ocasional, pero no la determinada)
• prohibirlo en sus Términos de servicio (que detiene a otras empresas legítimas y algunas personas conscientes)
• aplicar el ToS a través de la legislación (que puede ser necesario contra empresas no éticas, pero hará más daño que beneficio si se implementa contra usuarios individuales a pequeña escala).

Ninguno de estos es 100% efectivo, pero no es necesario que lo sea. Lo importante es que reducen la pérdida. Piense en lo que quiere lograr y elija sus contramedidas en consecuencia.

  

Supongamos que tengo un servicio web RESTful y una aplicación comercial de Android en la parte delantera que se utiliza para interactuar con él. Puedo usar SSL para que los puntos finales no sean visibles, pero alguien podría hacer ingeniería inversa para encontrarlos.

SSL no oculta la dirección IP de destino, por lo que ni siquiera necesitan realizar ingeniería inversa. Todo lo demás se puede obtener a través del certificado Fiddler + MITM.

  

También podría usar SOAP en su lugar, por lo que la llamada al servicio web es un poco más complicada. Pero, todavía no sé si esto me da una ventaja real sobre el servicio basado en RESTful.

Bueno, cuanto más esfuerzo hagas, más esfuerzo tendrá que poner un hacker, supongo.

Dicho esto, los hackers tienen mucho más tiempo libre que tú, y hay muchos de ellos, y solo uno de ellos tiene que publicar la solución en un tablón de anuncios y se acabó el juego.

Por lo tanto, probablemente no valga la pena el esfuerzo.

  

Estaba pensando en codificar la clave en mi aplicación cliente, de modo que solo mi aplicación cliente podría usar el servicio. Además, tal vez algún ofuscación de código puede ayudar. Pero, ¿cuánto ayuda esto realmente?

Los piratas informáticos ahora tienen herramientas de desobstrucción a su alcance, por lo que no ayuda tanto como antes.

Probablemente no valga la pena el esfuerzo.

  

Fiddler podría usarse para descifrar https y ver la solicitud completa. Sin embargo, si solo uso la aplicación de Android, esto se puede resolver con un certificado de servidor de codificación en la aplicación de cliente de Android. Y también, hay SOAP WS-Security, pero supongo que se puede hacer que una herramienta funcione de manera similar a como lo hace Fidler para evitarlo.

El pirata informático podría realizar ingeniería inversa mucho más rápido de lo que tú podrías construirlo.

Por lo tanto, probablemente no valga la pena el esfuerzo.

  

No puede detener a un pirata informático de ingeniería inversa ningún código que se ejecute en el cliente. Así que, independientemente de las medidas de seguridad que pongas, el pirata informático puede imitarlas.

Exactamente. No gastes tiempo en esto.

En su lugar, intente diseñar su aplicación para que se ejecuten funciones confidenciales en el servidor, donde puede protegerla.

Pase el resto de su tiempo mejorando las características de su aplicación para que los clientes no quieran nada más.

Quieres:

  

impide que alguien cree su propia aplicación de cliente para mi servicio web

Desea que su servicio web identifique su aplicación en dispositivos de usuario antes de nuevas interacciones, esto parece imposible ya que no tiene ninguna garantía sobre la integridad de la aplicación que podría modificarse con ingeniería inversa.

Es posible que desee considerar revisar la arquitectura de su solución.

Sí, esto se puede hacer, aunque, por supuesto, no hay una solución perfecta.

Necesitaría agregar cifrado y autenticación de mensajes tanto al cliente como al servidor. Ambos negocian una clave de sesión basada en un secreto compartido, posiblemente con la adición de un ID de cliente único. Hay mucha documentación sobre cómo hacerlo (palabras clave: clave de sesión, intercambio de claves, clave de API). La clave de este sistema es que la comunicación está cifrada y firmada con las claves de la sesión, no con la clave real (también conocida como secreto compartido). De esta manera, la llave real nunca viaja por el cable y no puede ser interceptada.

Un atacante aún podría aplicar ingeniería inversa a su cliente para extraer el secreto compartido y el mecanismo para derivar la clave de sesión a partir de él. Pero esto requiere habilidades más altas que simplemente escuchar una charla REST.

La única razón por la que se evita el uso no deseado es realizar algún tipo de autenticación de usuario. Como exigir al usuario de su aplicación que proporcione un nombre de usuario y una contraseña cada vez que inicien la aplicación y se la pasen al servidor. Si el servidor valida al usuario, devolverá un token de sesión que debe usarse en todas las llamadas API subsiguientes. Sin embargo, es posible que su aplicación no sea adecuada para que los usuarios inicien sesión.

Sin el inicio de sesión, siempre será posible que alguien con acceso a su API, ya que puede aplicar ingeniería inversa a su código y / o fisgonear los datos para que pasen de un lado a otro. Por lo tanto, su objetivo es hacer que sea lo más difícil posible para alguien que realice ingeniería inversa de su código y API. Asegúrese de no proporcionar un valor fijo del cliente al servidor. Es fácil de encontrar y luego usar en un cliente alternativo.

En su lugar, desea generar un nuevo código cada vez que inicie sesión en su servidor para que cada vez que alguien detecte el tráfico vea un valor diferente y no pueda simplemente repetir ese valor. Esto los obliga a aplicar ingeniería inversa a su código para descubrir el algoritmo utilizado para generar la clave. Haga un poco de esfuerzo para hacer que el código sea difícil de entender y, por lo tanto, replicar.