Saltar al contenido

¿Cuáles son los problemas de seguridad con “eval ()” en JavaScript?

Solución:

eval() ejecuta una cadena de caracteres como código. Tu usas eval() precisamente porque el contenido de la cadena no se conoce de antemano, o incluso se genera en el lado del servidor; básicamente, necesitas eval() porque el propio JavaScript generará la cadena a partir de datos que solo están disponibles dinámicamente en el cliente.

Por lo tanto, eval() tiene sentido en situaciones en las que el código JavaScript generará código. Esto no es intrínsecamente maldad, pero es difícil hacerlo de forma segura. Los lenguajes de programación están diseñados para permitir que un ser humano escriba instrucciones que comprenda una computadora; a tal efecto, cualquier lenguaje está lleno de pequeñas peculiaridades y comportamientos especiales que se supone que ayudan al programador humano (por ejemplo, la adición automática de ‘;’ al final de algunas declaraciones en JavaScript). Todo esto es bueno y elegante para la programación “normal”; pero cuando tu generar código de otro programa, basado en datos que pueden ser potencialmente hostiles (por ejemplo, un extracto de cadena de otros usuarios del sitio), entonces usted debe, como desarrollador del generador de código, conocer todos estas peculiaridades y evitar que los datos hostiles los exploten de manera dañina.

En ese sentido, los generadores de código (y por lo tanto eval()) incurren en los mismos problemas conceptuales que el SQL sin formato y, como consecuencia, los ataques de inyección de SQL. El ensamblaje en tiempo de ejecución de una solicitud SQL a partir de parámetros proporcionados externamente se puede hacer de forma segura, pero esto requiere tener en cuenta una gran cantidad de detalles, por lo que el consejo habitual es no hacerlo. Esto se relaciona con el acertijo habitual de la seguridad, es decir, que no es comprobable: puede probar si algún fragmento de código funciona correctamente con datos correctos, pero no que nunca funcione incorrectamente con datos incorrectos. Del mismo modo, usando eval() con seguridad es posible, pero es tan difícil en la práctica que se desalienta.

Todo esto se dice en general. En su contexto específico, eval() podría ser seguro. Sin embargo, se necesita algo de esfuerzo para tener un contexto seguro para el uso de eval(), eso realmente necesita eval().

eval () es un posible vector para secuencias de comandos entre sitios.

En circunstancias normales, un atacante que intente XSS podría querer obtener un script <script></script> etiquetas más allá de cualquier codificación, filtros o cortafuegos que puedan existir. Si eval () está operando en la entrada del usuario, elimina la necesidad de etiquetas de script.

Eval está presente en muchos scripts maliciosos porque ayuda a ofuscar el código y / o filtrar caracteres prohibidos más allá de los filtros. Por esta razón, eval () a menudo se comprueba en la entrada del usuario. Entonces, cuando usa eval (), potencialmente está proporcionando al atacante una de sus herramientas necesarias. Estoy robando un banco y sé que no tengo que pasar un arma por los detectores de metales porque hay un montón en el paragüero dentro del edificio.

Como explicaron otros, se puede usar eval para crear código dinámicamente, lo que dificulta la comprensión del flujo de control del programa. Pero, no considero a eval mucho más malvado que todas las otras formas de generar código en tiempo de ejecución, como document.write(...), object.innerHTML(...) y otros. Si bien estos se usan principalmente para cambiar el DOM del programa, también se usan para insertar código nuevo (es decir, agregar una declaración de script al código, o un nuevo elemento con algún controlador onXXXX, etc.).

Y aunque eval se usa a menudo en ataques (XSS, publicidad maliciosa …) para eludir filtros u ocultar el propósito real del código, a menudo se usa en una forma ofuscada allí, es decir, código como z='ev'; z+='al'; v=window; v[z]("alert(1)"). Esto significa que no está en el lado seguro si simplemente intenta filtrar el código con llamadas explícitas de eval, porque o la llamada está ofuscada o las funciones “buenas” como innerHTML se utilizan para malos propósitos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *