2010-07-07 8 views
7

¿Hay formas de prevenir, o dificultar lo suficiente, que alguien se inyecte Javascript y manipule las variables o funciones de acceso? Un pensamiento que tuve fue cambiar todos los nombres de las var aleatoriamente en cada recarga para que el script del malware tuviera que ser reescrito todo el tiempo. ¿O hay otras maneras menos dolorosas?Formas de dificultar la piratería/inyección/manipulación de código Javascript

Entiendo que, finalmente, alguien pirateará su camino, pero me gustaría saber cómo hacer que sea difícil reproducir la acción, para que la gente no publique un bookmarklet o algo similar para que todos lo utilicen. No me importa si los expertos encuentran su camino en el código, pero me gustaría que fuera un poco más complejo que javascript:d=0;

Si sabes cómo hacer que hackear Javascript sea un poco más difícil, por favor escribe esos.

+2

La ofuscación es parte del camino. – Artelius

+2

Difícil? Sí. ¿Difícil? Nunca por seguridad real (pero puede ser suficiente para evitar trampas fáciles en juegos o lo que sea). –

+1

Supongo que la pregunta es "¿por qué es importante?" Si hay un estado enviado al servidor, confiar en guardias en el extremo JS es una mala práctica, si no se envían datos, ¿quién pierde? – spender

Respuesta

14

Puede escribir su JS para usar solo métodos y variables privados en una función autoejecutable. Por ejemplo, el siguiente código no deja ninguna señal de sí mismo en el espacio de nombres global para que cualquiera pueda simularlo.

(function(){ 
    var x = 1; 
    var y = 2; 
    var z = "A am z"; 
    var clickHandler = function() { 
     alert('You clicked the body'); 
    }; 
    document.getElementsByTagName('body')[0].addEventListener('click',clickHandler,true); 
}()); 

[EDIT] El código anterior es susceptible a un usuario sobrescribiendo los objetos, métodos, eventos disponibles a nivel mundial o propiedades que está utilizando (en este caso, document, getElementsByTagName y addEventListener), así que si usted es verdaderamente paranoico, puede copiarlos en el alcance de su función antes de que la página se haya cargado y el usuario tenga la posibilidad de sobrescribirlos. Usar addEventListener es una buena idea porque, a diferencia del evento body.onclick, no se puede quitar ni sobreescribir desde fuera de la función.

+0

Eso es útil gracias. – stagas

+2

Tiene un error en la última línea que debería ser '})();' Creo que – stagas

+0

Lo escribí de esa manera hasta que Crockford se me ocurrió. A excepción de un punto y coma que falta (que añadiré), el código anterior valida según JSLint; – Andrew

24

Acepte que su javascript será "manipulado" y prever desde el lado del servidor. No hay nada que puedas hacer para evitar que la gente juegue con el cliente.

+0

Gracias, estaba pensando en una forma de hacerlo difícil, no es realmente vital para evitar la manipulación, pero me gustaría evitar que al menos alguien publique un bookmarklet para 'hacer algo genial' para que todos puedan piratear. Realmente no me importa si un experto finalmente encuentra una manera, pero me gustaría que sea lo suficientemente difícil para noobs, y tal vez sea difícil reproducir la acción sin usar herramientas si eso es posible. – stagas

+3

Estoy de acuerdo con @spender. El problema con su escenario es que lo mejor que puede hacer es la seguridad a través de la oscuridad. Le costará mucho tiempo y esfuerzo y nunca resolverá completamente el problema, por lo que siempre tendrá que hacerlo en el lado del servidor. – flpmor

+0

No puedo estar de acuerdo. La seguridad a través de la oscuridad es una mala idea. Necesitas hacer una verificación del lado del servidor. Período. –

-1

La ofuscación y la minificación deberían hacer que sea un poco más difícil de hackear, pero estoy de acuerdo con el derrochador.

0

Cualquier usuario que realmente desee manipular al cliente podrá hacerlo. El código está en su máquina. Incluso si ofusca el código del lado del cliente, hay herramientas que ayudarán a alguien a desutilizar el código en un segundo.

Lo que debes tener en cuenta es que el sitio está seguro en el servidor y es seguro para otros usuarios también. Esto significa (como mínimo):

  1. Comprobación/validación de todas las solicitudes de entrada y parámetros en el servidor para que los usuarios no podrán alterar los datos del lado del servidor de activación 'hackeados' funciones del lado del cliente que ha escrito .

  2. Verifica todos los datos que generes en la pantalla que se originó a partir de la entrada del usuario. Es posible que otros usuarios hayan insertado scripts del lado del cliente que son peligrosos para su sitio y especialmente peligrosos para los otros usuarios de su sitio. (Si está utilizando .net, consulte la biblioteca AntiXSS)

Cuestiones relacionadas