On Mar 14, 1:53 am, Jarek Foksa <[email protected]> wrote:
> Almost any modern JavaScript book recommends using subscript notation
> (e.g. object[key]) instead of eval() because of the following three
> reasons:
> - evaled code execution is slow
> - evaled code is less readable than the same code written with
> subscript notation
> - evaled code is insecure
>
> While the first two arguments make perfect sense to me,
There was a time when the use of eval was a good sign of a clueless
programmer. They would write things like:
var x = eval('document.getElementById(' + id + ')');
So the mantra "eval is evil" was propigated to make anyone who was
about to use eval think again and hopefully find a better solution.
Fortunately those days are gone - clueless programers aren't. :-)
> I don't
> understand the last one.
The first two are about use of eval, not eval itself - distinctly
different issues. Using eval doesn't ncessarily affect security,
executing code of unknown origin might. But that is a general issue
that is not restricted to using eval.
> AFAIK any code returned by client-side scripts should be treated as a
> potential security risk.
I can't imagine any scenario where I'd allow script from a client to
run on a server, or be served to other clients, unless I was
*extremely* confident of the source or had warned users that they were
about to execute code from unknown sources.
> Thus it should be sanitized on the server
> side before any further processing.
I don't know how you "sanitise" script in a practical sense. It either
meets your criteria for further processing (e.g. trusted source) or
not.
> So, security-wise, why would it matter whether eval() or any other
> obscure code is used on the client side?
It probably makes little difference. ES5 might fix some of these
issues, no doubt clever hackers will find new attack vectors.
--
Rob
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
