Eval Evil???

[buzu]

Es muy conocida la advertencia en cuanto al eval en JS, y por si alguien no la conoce, es algo así:

No uses eval por que puede ser explotado para lograr XSS (Cross Site Scripting).

La razón de esa paranoia es simple, eval va a interpretar cualquier cosa que le pases como parámetro como si fuera javascript, es decir que le puedes pasar código en forma de string y eval te va a interpretar ese string como si fuera JS.

Ahora, la pregunta es:

Con extensiones como firebug y grasemonkey, que tan valido sigue siendo el argumento en contra de eval?

Yo, aun que nunca me he visto en la necesidad de usar eval debido a las innumerables "técnicas" de prescindir de dicha función, creo que ya no es muy valido dicho argumento. Que opinan ustedes?

[David]

No entendí la relación Firebug/GreaseMonkey con XSS.

Efectivamente, dependiendo del contexto, sigue siendo peligroso usar eval, porque realmente se puede hacer un ataque XSS.

Pero depende mucho de dónde se use y los filtros que se apliquen.

P.S.: Yo tampoco he encontrado una situación real en la que el uso de eval sea indispensable.

[Panino5001]

El problema de eval (desde mi punto de vista, ya que con el simple protocolo javascript: ya podemos hacer casi de todo y los ataques xss tienen más que ver con fallas en las validaciones del lado del servidor) viene más por el lado de la penalización que implica a nivel rendimiento que con un tema de seguridad. Un buen blindaje del lado del servidor es lo que evita problemas.

[jseros]

Hola buzu. Pues la verdad yo poco uso eval. El uso más común para eval es la carga de datos mediante JSON pero con JSONP las cosas cambiaron y hace que el uso de EVAL sea innecesario. Además eval es muy lento en procesamiento lo que genera en aplicaciones a gran escala un consumo de CPU innecesario.

Las herramientas que mencionas son muy utiles, las uso todo el tiempo y creo que es hora de olvidar que nuestra aplicación es invencible si no usamos eval. Con Greasymonkey ya pudieron hacer cracking en los captchas, que más podemos esperar?....

[venkman]

Yo comparto lo dicho por Panino5001. El problema de eval no es tanto el riesgo de inyección de código sino:
a. El rendimiento
b. Siempre (por lo menos el 99.9% de las veces) hay otro modo de hacerlo que no necesita usar eval.


Ahora yo pregunto... ¿cuántos huyen del uso de eval pero siguen usando el constructor Function y pasando cadenas a setTimeout/setInterval?

[buzu]

Si, si yo no digo que ahora se haya vuelto recomendable usar eval, simplemente que desde mi punto de vista el hecho de la seguridad ya no es argumento y por lo que veo hasta ahora coincidimos en eso. De ahí a que haya otras razones por las cueles no seguir usándolo, es otra cosa.

No entendí la relación Firebug/GreaseMonkey con XSS.

Simple, por ejemplo, con firebug puedes inyectar Js en un sitio sin restricción alguna, aun que como bien apuntó paninio:

con el simple protocolo javascript: ya podemos hacer casi de todo y los ataques xss

Yo comparto lo dicho por Panino5001. El problema de eval no es tanto el riesgo de inyección de código sino:
a. El rendimiento
b. Siempre (por lo menos el 99.9% de las veces) hay otro modo de hacerlo que no necesita usar eval.

También comparto el punto de vista.

Ahora yo pregunto... ¿cuántos huyen del uso de eval pero siguen usando el constructor Function y pasando cadenas a setTimeout/setInterval?

El constructor Function? esa es otra bestia peluda que también conviene evadir, especialmente por que su aplicación práctica es casi siempre posible de lograr mediante otras maneras, al igual que pasa con eval. En cuanto a setTimeout/Interval, yo siempre que las uso (que es casi igual a nunca) paso funciones.

PD. Que bueno ver que 4 de los Grandes se han apuntado a la plática.

[stock]

Para evitar ataques XSS es necesario tener una rigurosa validación en el servidor, y sobre todo no mandar a imprimir al explorador lo que el usuario esta introduciendo sin ser validado correctamente.

Yo puedo utilizar firebug o greasemonkey para hacer lo que quiera con la página pero esto sólo se verá reflejado en mi máquina no para a otros usuarios a menos que logre guardarlo en una base de datos o semejante (esto sucede por no validar las entradas), lo cual se convertiría en un ataque XSS.

saludos buzu!

[buzu]

Si, stock, de eso no hay duda, el punto es que ahora es hasta cierto punto más sencillo hacer ese tipo de ataques si no hay, como bien mencionas y como se mencionó antes, una buena validación del lado del servidor.

Yo puedo utilizar firebug o greasemonkey para hacer lo que quiera con la página pero esto sólo se verá reflejado en mi máquina no para a otros usuarios a menos que logre guardarlo en una base de datos o semejante

Lo mismo pasa con eval. No estoy seguro de que es lo que quisiste demostrar con ese punto, pero de lo que si estoy seguro es de que ese aspecto no le da ventaja o desventaja tanto a eval como a FB o GM.

[David]

No es lo mismo con eval que con Firebug y GreaseMonkey.

Claro, un programador ya tiene que ser irresponsable para que suceda, pero que es posible, es posible.

Supongamos que un programador despistado toma un valor de la URL y lo inserta en medio de un String que después pasa por eval. Ahí sí se puede hablar de un ataque XSS.

Por eso hablé en principio del contexto en que se usa, y que dependiendo de éste, aún sigue válido el argumento de la seguridad (convengamos, aún hay gente que hace esas cosas que podrían parecernos descabelladas).

Pero con Firebug y GreaseMonkey no, por lo menos lo que yo entiendo por XSS no se puede hacer con esas herramientas.

[buzu]

No específicamente XSS, pero si se puede inyectar el JS en la pagina, lo que pudiera causar incluso más daños que un eval.

[jseros]

Quisiera agregar que los desarrolladores despistados no son los unicos que pueden recibir ataques XSS.

He visto en varios bugtracker de aplicaciones muy conocidas(Joomla!, Drupal, vBulletin) que es más común de los pensamos incluso para desarrolladores con mucha experiencia. Si bien con eval se pueden producir ataques, con GreaseMonkey es mucho más sencillo y practico que usar por ejemplo el protocolo Javascript:.

Pienso que poco a poco Javascript se está perfilando como un lenguaje al que hay que respetar y documentarse muy bien para evitar este tipo de ataques y los que lleguen en el futuro. Alguna vez un colega desarrollo una red social y bastó solo un alert() en una caja de texto para dejar loca su aplicación.

Saludos.

[buzu]

Alguna vez un colega desarrollo una red social y bastó solo un alert() en una caja de texto para dejar loca su aplicación.

Hummm,.... interesante.

Y si, tienes razón cuando dices:

Pienso que poco a poco Javascript se está perfilando como un lenguaje al que hay que respetar y documentarse muy bien para evitar este tipo de ataques y los que lleguen en el futuro.

Eso me hace pensar en que tan responsable se debe hacer nuestro JS. Esdecir, ya no es solo la cuestión de accesibilidad que siempre se ha planteado, sino una creciente necesidad por seguridad y mejores sistemas de validación del lado del servidor.

Muy interesante cada aporte, sin duda.

[David]

Sí, es serio el asunto.

He visto sitios Web de empresas importantes (no necesariamente en el ámbito Web, pero en fin, importantes) con validaciones de formularios sin ninguna validación del lado del servidor.

Hace poco hubo un caso de un usuario (en el foro de PHP) de un usuario que usó un pre-fabricado (no sé de dónde) para comentarios en un foro, que simplemente guardaba en un campo hidden el ID del usuario (que es fácilmente modificable con las herramientas que hemos venido comentando para escribir comentarios con el ID de otro usuario). Igual sucede con algunos sistemas de captcha que dejan indicios en el código HTML que pueden ser usados para saltarse la validación.

P.S.: Sólo quería recalcar nuevamente la cuestión simplemente técnica de nomenclatura:
Los ataques que se pueden hacer con GreaseMonkey/Firebug NO son del tipo XSS; que es peligroso lo que se puede hacer, lo es, pero no es XSS .

[buzu]

Los ataques que se pueden hacer con GreaseMonkey/Firebug NO son del tipo XSS; que es peligroso lo que se puede hacer, lo es, pero no es XSS .

Si, en eso tienes razón, creo que fue un error tratar ese tipo de ataques como XSS.

En cuanto a que es serio, es serio. Y con el ejemplo que muestras, demuestras que es necesario dejar los sistemas de seguridad para uno mismo, hacerlo a mano o encontrar uno que se haya provado ser confiable, pero no aplicar simplemente el primero que se encuentra.