Evitar la ingeniería inversa de la aplicación cliente

La ofuscación puede parecer el primer paso obvio, pero la ofuscación tiene que proteger algo en el código y que algo no puede ser una funcionalidad de servicio web porque se trata de ingeniería inversa al interceptar el tráfico, incluso si está cifrado SSL. La fijación de certificados puede evitar la simple intercepción de SSL confiando en un certificado predefinido.

Puede cifrar simétricamente los datos de comunicación y almacenar la clave en el cliente luego utilizar la ofuscación para dificultar el acceso a esa clave y al algoritmo de cifrado. Y también puedes proteger la ofuscación haciendo más difícil la descompilación. Un ejemplo de ofuscador flash y anti-decompilador es SWFencrypt y BISguard .

Las anteriores son protecciones de código fuente estático, pero no protegen contra ataques dinámicos / en vivo. Una forma de protegerse de estos ataques es que el cliente utilice verificaciones de integridad en la memoria y los recursos. También hay algunas técnicas de ingeniería inversa que pueden hacer que la depuración en vivo sea más difícil.

La otra forma de prevenir ataques en vivo es usar un software que busque cualquier manipulación del sistema que pueda usarse para la manipulación del software del cliente. Este es el reino de los motores anti-trampas similares a rootkits como Punkbuster, Warcraft's Warden y Valve's VAC.

Un tipo de protección diferente es la firma de código y la firma de memoria (hasta la página de memoria) en plataformas cerradas como iOS y Android. De esta manera, puede limitar las modificaciones estáticas a los binarios y dinámicos del cliente a su memoria y al sistema operativo.

Incluso el antiguo CAPTCHA puede usarse como protección contra la automatización, pero perjudica la facilidad de uso. También puede detectar la automatización en el servidor, a través del comportamiento del usuario y los patrones de uso y luego asociarlo con CAPTCHA para reducir los falsos positivos.

Además de las protecciones técnicas, puede utilizar con medios legales e incluso incentivos. Proporcione el mejor cliente para que los usuarios no se inclinen a piratear el suyo ni a escribir el suyo. O haga que un cliente personalizado o pirateado no le dé al hacker una ventaja mucho mayor. Los medios legales no son mi fortaleza y variarán según el país, pero he oído hablar de juicios sobre ingeniería inversa. La amenaza legal podría disuadir a las empresas y personas de vender o proporcionar clientes personalizados.

Finalmente, puede hacer que todo el problema se convierta en realidad y hacer que el servicio web sea fácilmente accesible a través de API flexibles y protegerlo contra el abuso en el servidor. También puede cobrar pequeñas tarifas por la funcionalidad superior que sus hackers están deseando. :)

Fundamentalmente no puedes asegurar a tu cliente. En el mejor de los casos, puede ocultarse y ofuscarse para dificultar la modificación del cliente por parte de un atacante.

Usted menciona que no es un problema de seguridad porque el servidor está bien protegido, sino simplemente una molestia. Puede ser más molesto tratar de ocultar a su cliente que dejar que algunos clientes modificados realicen solicitudes incorrectas que el servidor rechaza.

Realmente depende de tus modelos de amenaza. En la mayoría de los clientes en los que he trabajado, no me preocupé por ninguna confusión u ofuscación, ya que el servidor estaba completamente protegido y no se ganaría nada modificando el cliente.

Ahora, si estamos hablando de intentar proteger a un cliente en sí (es decir, debido a preocupaciones de IP, no quiere que alguien le robe al cliente), puede tener más sentido dedicar tiempo a hacer que esto sea difícil de lograr (aunque todavía teniendo en cuenta que nunca podrá asegurar por completo a un cliente (en el mejor de los casos, puede hacer que los atacantes desmotivados se rindan y retrasen a los atacantes motivados).

Ninguna. Si no descompilan su aplicación, simplemente la someterán a un proxy con su propio certificado SSL. Su cliente no puede proporcionar seguridad para su backend.

  

¿Qué medidas tomaría para limitar el riesgo de que las personas manipulen el software de su cliente?

Aquí hay un equilibrio que solo tú puedes medir. Suponiendo que su protección no moleste a los usuarios válidos, entonces solo tiene que equilibrar el valor, para usted, de proteger el software contra el valor para el atacante de romper la protección.

Si está hablando de software o servicio que no es muy costoso y los clientes no son del tipo que van más allá de los medios simples, entonces la ofuscación podría ser suficiente.

Si está hablando de un servicio o software que es muy costoso o de otro modo es valioso si se usa incorrectamente, y los clientes están determinados a usar el servicio con su propio software, entonces tendrá que usar mucho más. medios rigurosos.

En el primer caso, las herramientas ya existen.

en el segundo caso, la mejor opción es utilizar Adobe Air, que permite aplicaciones firmadas que no se ejecutan en el navegador. Puede verificar mediante la criptografía de clave pública que está 1) hablando con su aplicación y 2) que la aplicación no ha sido modificada. Es complicado si tiene que frustrar a los atacantes muy diligentes (y, honestamente, nada es absolutamente impenetrable) pero con un diseño cuidadoso y frecuentes actualizaciones forzadas, puede eliminar la mayoría de los ataques simplemente haciendo que sea mucho para atacar.