Codificación del lado del cliente: ¿Cómo prevenir el uso malicioso?

No puedes, y mientras más gente entienda esto, y cuanto más entiendan, mejor para el mundo.

El código que se ejecuta en un dispositivo bajo el control del usuario no se puede controlar. Los teléfonos inteligentes pueden ser jailbreak. Los decodificadores pueden romperse. Los navegadores normales ni siquiera intentan impedir el acceso al código JavaScript. Si tiene algo que valga la pena robar o abusar, un atacante determinado podrá hacerlo a menos que valide todo lo que aprecia del servidor.

La ofuscación es de muy poca ayuda; El tipo de oponente que atraerás tan pronto como se involucre algo remotamente financiero, lee el lenguaje ensamblador como anuncios clasificados. El cifrado no puede ayudarlo, porque el dispositivo que guardaría la clave es el mismo dispositivo que debe asumir que está dañado. Existen muchas otras contramedidas aparentemente obvias que no funcionan, por razones similares.

Lamentablemente, esta es una verdad muy inconveniente. El mundo está lleno de operadores de tiempo pequeño y grande que piensan que de alguna manera pueden sortear el quebrantamiento fundamental de la confianza remota, simplemente porque sería oh, muy bien si pudiéramos asumir que nuestro código Se ejecutará como asumimos. Y sí, haría todo mucho más fácil que ni siquiera sea divertido. Pero desearlo no lo hace así, y esperar contra la esperanza de que seas la única cookie inteligente que puede evitar el desagrado solo te quemará a ti ya tus clientes. Por lo tanto, ingrese a la idea de que Internet es un territorio enemigo, incluya ese costo adicional en sus estimaciones y estará bien.

Dicho esto, por supuesto que existe una defensa profunda. El ofuscar tu JavaScript no retrasa a un atacante determinado, pero puede retrasar a algunos atacantes menos decididos. Si sus activos valen lo suficiente como para proteger, pero no a cualquier costo, cualquiera de esas medidas puede agregar valor comercial a su sistema; simplemente no puede ser perfecto. Siempre y cuando sea plenamente consciente de la compensación que está realizando, esa puede ser una estrategia razonable.

La regla aquí es:

Haga todo lo que esté del lado del cliente que no afecte a nadie más si el usuario lo manipula. En particular, eso significa efectos gráficos.

Haga todo lo que sea del lado del servidor que necesita para estar seguro, y simplemente envíe eventos de IU desde el cliente (por ejemplo, el cliente simplemente dice "el usuario pulsó el botón Comprar" mientras el servidor realiza la transacción). En particular, eso significa transacciones financieras.

Este es exactamente el caso en el que convertirlo en una aplicación completamente del lado del cliente es no apropiado.

Puede hacer la validación lógica y básica de los formularios del lado del cliente (todavía tiene que volver a validar en el servidor, porque alguien puede intentar falsificar la solicitud) para mejorar la capacidad de respuesta, puede hacer solicitudes HTTP desde JavaScript que pasa los datos de un lado a otro. en JSON para evitar el reenvío de decoraciones de página y demás, pero si la transacción en sí necesita ser autenticada y autorizada, aún debe ocurrir en un servidor.

Su párrafo medio es el corazón del problema:

  

    

Ejecutar una aplicación del lado del cliente significa que esto ahora debe suceder en el navegador de un usuario. La API de terceros proporciona los archivos js necesarios para lograr esto.

  

¿Por qué una aplicación del lado del cliente significa que no puede tener trabajo del lado del servidor? El impulso hacia la programación del lado del cliente no consiste en eliminar servidores, sino en aprovechar las tecnologías más nuevas que los navegadores finalmente admiten para crear mejores interfaces de usuario.

En cuanto al archivo .js que recibió, ¿está seguro de que está destinado a un navegador? ¿Podría ser una biblioteca node.js?

Retrocedamos de esto y echemos un vistazo a un nivel superior. ¿Eudora o Outlook (una aplicación del lado del cliente, que ni siquiera necesita un navegador) alguna vez causó una pérdida financiera para alguna empresa? No. Cualquiera podría escribir en las API de POP / SMTP y ser el cliente. Pero no hay pérdida para el servidor. El servidor no limitó las acciones del cliente, los cálculos, el almacenamiento, la temperatura, el tamaño del disco, el tamaño de la RAM, el monitor DPI, la GPU, la FPU yada yada del cliente, sino que especificó exactamente a qué respondería y nada más. ¿Alguna vez escuchó sobre el uso de Quicken o MS-Money para ingresar a un banco?

La aplicación de su navegador (es decir, del lado del cliente) puede usar la misma arquitectura.

1. Construyes tu servidor con una API (que por cierto, siempre se reduce a derivados de GET POST HEAD, etc.).
2. En el servidor, asegúrese de que la API solo hable con un cliente autenticado y con identidad verificada para todas y cada una de las llamadas.
3. Entonces no te importa quién es el cliente.
4. Y luego no te importa si se trata de un navegador, dispositivo con jailbreak, Google Glass, DOS 3.1 o un nuevo Nexus en manos de un gran abuelo tecnofóbico que ha viajado al 2014. y perdimos toda la tecnología que ha estado inundando nuestras vidas en las últimas 15 décadas.
5. Ahora puede comenzar a descargar todo lo demás en el lado del cliente.

  

SoapBoxBegin

@KilianFoth plantea un importante punto de atención para los ingenuos y los imprudentes, principalmente aquellos que leen los titulares todo el tiempo, pero nunca piensan que esto sucederá con su aplicación, su código, su empleador, su cliente, su propia cuenta bancaria. Aún más imprudentes son sus empleadores (especialmente los CTO) que permitirían que salgan las aplicaciones que exponen cualquier sistema a la exposición no controlada / no controlada. Sin embargo, siempre me sorprende lo que parece "nunca aprendemos".

  

SoapBoxEnd

Así que para resumir. Haga una API del lado del servidor sólido y apretado. Descargue todo lo demás al cliente según lo que el cliente pueda manejar.

Yo diría que realmente no puedes. Si está dispuesto a enviar los datos al cliente, debe esperar que se abusará de ellos, siempre que sea posible. Su ejemplo con respecto a la clave API es ilustrativo del punto, y no lo incluiría en el lado del cliente JS; será robado y abusado.

Definitivamente todavía necesitarás cierta cantidad de código de servidor para mantener las cosas seguras. Incluso algo tan simple como recuperar solo los datos relacionados con el usuario que ha iniciado sesión. Esa autenticación no se puede hacer del lado del cliente o, de nuevo, se aprovechará de usted y sus datos no están seguros.

Siempre vería la experiencia del lado del cliente JS como una adición al código del servidor. La validación en el cliente proporciona una buena experiencia de usuario, pero si no verifica también los datos de la POST en el servidor receptor, se está abriendo para atacar. Cualquier cosa del cliente debe ser considerada sospechosa.

Es bastante simple, de verdad. Supongamos que el equipo cliente y todo el software que se ejecuta en él están bajo el control completo de un pirata informático malicioso inteligente.

Eso significa que el pirata informático malicioso sabrá cualquier información que envíe desde el servidor al cliente, por lo que debe asegurarse de no enviar ninguna información al cliente que pueda usarse para atacar su servidor o su empresa.

También significa que cualquier cosa enviada desde el cliente al servidor ha sido producida por un pirata informático malintencionado, por lo que el código del servidor debe asegurarse de que nada de lo que el cliente pueda enviar sea capaz de atacar con éxito su servidor.

Es cierto que la implementación es un problema, pero lo importante es la actitud mental, el supuesto de que el "cliente" con el que piensa que su servidor está hablando no es un cliente sino un atacante activo.

(También debe asumir que el usuario es un estafador inteligente que intentará atacar sus métodos comerciales, pero eso no tiene nada que ver con la programación del lado del cliente).

La aplicación del lado del cliente, en mi opinión, es principalmente sobre la interfaz de usuario. Por ejemplo, todo su sistema de UI se enviará una vez al cliente, y luego el cliente hará lo que quiera con él.

  

Normalmente, mi aplicación se ejecuta en un servidor. Llamaría a la API de terceros desde el código de mi servidor.

     

Ejecutar una aplicación del lado del cliente significa que esto ahora debe suceder en el navegador de un usuario. La API de terceros proporciona los archivos JavaScript necesarios para lograr esto.

Si tiene una clave API, no está pensada para funcionar en el lado del cliente. Si proporciona la Clave de la API en el lado del cliente, entonces cualquiera tiene acceso a ella, y luego puede usarla para su propio propósito. Guárdelo y utilícelo del lado del servidor cuando el cliente lo necesite, luego envíe el resultado utilizando Ajax / WebSockets.

Es como si su banco dijera: "Bueno, voy a poner la contraseña del lado del cliente de la base de datos principal para que el cliente pueda solicitarlo él mismo y no moleste más a nuestros servidores".