¿Cómo proteger los datos de su aplicación web contra un Javscript inyectado?

-1

Tengo una aplicación web que interactúa con dos servidores web. La respuesta del primero se almacena temporalmente en el navegador (window.xyz = response.xyz) y cuando el usuario realiza la solicitud del segundo servidor, enviamos estos datos como uno de los parámetros.

Ahora esto no es seguro ya que si alguien tiene una extensión de navegador maliciosa instalada en el navegador, puede inyectar el javascript y exponer las variables.

¿Cuál sería una buena manera de protegerse contra tales posibilidades? Tengo la sensación de que hay una solución bastante simple que los desarrolladores no han pensado. ¿Puede el uso de variables locales pasadas como parámetros a otras funciones funcionar en su lugar? No estoy familiarizado con Javascript.

Contexto adicional: estoy interesado principalmente en garantizar que el script malicioso no pueda exponer las variables y utilizarlas para solicitudes falsas

    
pregunta Limit 27.06.2017 - 18:34
fuente

3 respuestas

3

Si lo comprendo correctamente, desea transferir información desde el servidor A al servidor B a través del navegador de los usuarios, pero no desea confiar en el navegador, ya que puede haber una extensión maliciosa o similar que modifique los datos dentro del navegador. antes de enviarlo a B.

No creo que haya nada en el lado del cliente que haga que la modificación sea imposible, es decir, no se puede confiar en el navegador de ninguna manera. Por lo tanto, si realmente insiste en transferir los datos utilizando el navegador, debe tener alguna otra forma de asegurarse de que nadie haya manipulado los datos, es decir, algo en lo que realmente pueda confiar en lugar del navegador.

Mi elección sería que debería confiar en el servidor A, porque de todos modos ya debe confiar en A, ya que esta es la fuente de los datos. Por lo tanto, debe asegurarse de que los datos realmente se originaron en el servidor A. La forma típica de hacerlo es usar firmas digitales: el servidor A tiene un par de claves, el servidor B conoce la clave pública, el servidor A firma los datos con su privado La clave y el servidor B pueden validarlos con la clave pública. Otra opción sería tener un secreto compartido entre A y B y usarlo dentro de un HMAC.

De esta manera, se detectará cualquier manipulación de los datos, sin importar en qué punto del camino entre A y B ocurra esta manipulación.

    
respondido por el Steffen Ullrich 27.06.2017 - 19:27
fuente
1

Lo que realmente estás preguntando es cómo limitar el impacto de un ataque XSS. Desafortunadamente, dado su escenario, no hay mucho que pueda hacer, ya que se debe acceder al token en JavaScript para obtenerlo del Servidor A. Su mejor opción sería implementar una política de seguridad de contenido (CSP) sólida. CORS no se aplica a este escenario.

No estoy muy familiarizado con la forma en que CSP se aplica a los complementos, pero no creo que se pueda hacer nada para proteger contra un complemento malicioso.

    
respondido por el user52472 27.06.2017 - 20:10
fuente
1

JS usa un modelo de seguridad basado en referencias, por lo que si su extensión no puede obtener una referencia al secreto, no puede acceder al secreto. A menos que la extensión controle (y anule) la carga de los scripts de página, se puede construir un script para compartir secretos de una manera en que el código de ejecución previa o posterior no pueda interferir directamente.

La parte difícil es autenticar la parte necesitada porque un getSecret () ingenuo es poco más seguro que window.secret = blah. Presente las dos partes, permita que se refieran a sí mismas sin variables públicas y luego añada más referencias. Esto le permitirá conectar las dos piezas de tal manera que se puedan cortar, pero no se pueden golpear o falsificar.

// this part contains a secret only specific other code should see:
var hasSecret=(function(){ 
 var mySecretRef; // an object refrence, to be populated at run-time
 var mySecretData = ["I like anchovies"]; // in array so it can be updated later
 var out={};
 out.meet=function(obj){
    mySecretRef = obj;  // bake-in a specific object
    delete out.meet; // burn this bridge
    // define a method that can only use the non-replaceable baked-ins:
    out.reveal= mySecretRef.obtain.bind(mySecretRef, mySecretData); 
    Object.freeze(out); // just for easier debugging on attempts under global "use strict"
 };

 return out;
}());


// this code needs a secret that no other code should see and only one part has (the above)
var getSecret={ 
 obtain: function(secret){
   prompt("The Secret Is", secret || "N/A"); // (instead of demo prompt(), custom app-logic goes here)
 }
};


// kick the tires a little bit:
hasSecret.meet(getSecret); // bake-in object relationship, the prime "feature" of this pattern
hasSecret.reveal = Boolean; // attack:  try to over-ride reveal()
getSecret.obtain(); // attack: obtain() can be manually called, but has no secret data
hasSecret.reveal() // legit: shows "I like anchovies" (the secret) by calling getSecret.obtain() callback
getSecret.obtain = function(secret){ return "This is a fake secret";}; // attack: try to over-ride obtain()
hasSecret.reveal() // legit: shows "I like anchovies" still, as desired
hasSecret.meet({}); // attack: remeet (throws error since meet() is gone

Por supuesto, esto podría ser poner una puerta de bóveda de banco en una tienda de campaña si el objeto XMLHttpRequest se manipula, los scripts de la página se reemplazan directamente con una extensión, o si alguno de los servidores no es HTTPS. En resumen, aunque el patrón del módulo revelador en sí debería ser a prueba de balas, la aplicación del patrón podría no serlo.

EDITAR: asegúrese de no codificar los datos secretos en el código fuente, sino de buscar los datos, establecer mySecretData e inmediatamente llamar a meet() .

    
respondido por el dandavis 27.06.2017 - 22:23
fuente

Lea otras preguntas en las etiquetas