Joose3: JXND: Eval is being used quite a lot
Tom
I am quite happy with JXND and how easy it has been for me to change its
loading behavior from using Eval to using script tag execution.
However, I just noticed that my debugger is still not able to fully show
all errors correctly due to Eval still being used.
I traced for a bit and noticed that Eval is used in Auto.js after
initialize:
after: {
initialize: function () {
var me = this
if (this.type == 'nonjoose') this.type = 'javascript'
var presence = this.presence
if (typeof presence == 'string') this.presence = function ()
{
return eval(presence)
}
if (!presence) this.presence = function () {
return eval(me.token)
}
if (!this.readyness) this.readyness = this.presence
}
}
It is also used in JooseX.Namespace.Depended.Resource.JooseClass after
initialize and in JooseX.Namespace.Depended role's method inlineDeps.
There are a lot of downsides to using Eval and this should not be
necessary.
Would it be very difficult to stop using Eval here?
- Tom
Nickolay Platonov
It only can debug the code which has been *loaded* with <script>. I'll recommend to use Chrome's debugger
in this case - it can deal even with "eval".
The "eval" is being used only for evaluting the tokens and don't affect your code.
Nickolay
--
You received this message because you are subscribed to the Google Groups "Joose" group.
To post to this group, send email to joos...@googlegroups.com.
To unsubscribe from this group, send email to joose-js+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joose-js?hl=en.
Malte Ubl
with eval in Firebug.
Nickolay Platonov
Tom
Nickolay Platonov
I'm using eval to translate the string "Some.Class" to the `Some.Class` constructor.
This doesn't introduce any security vulnerabilities as "eval" is being used on the piece of your own code (and not on something that came from untrusted source).
If someone *can* change your sources he would just embed the exploit directly into your code, not in the tokens :)
I have once again investigated a bit on the use of Eval and according to my sources it is far from recommended to use and should not be necessary in any case.
There are perfectly valid use cases for "eval". Those who said its not needed probably just have background from static languages.
Nickolay
Malte Ubl
> Token is the "id" of the resource - either the name of class in case of
> Joose classes ("Some.Class") or the url - in case of non-joose code.
>
> I'm using eval to translate the string "Some.Class" to the `Some.Class`
> constructor.
Why dont you split and then look down from the current global scope
using symbolic dereferencing?
> This doesn't introduce any security vulnerabilities as "eval" is being used
> on the piece of your own code (and not on something that came from untrusted
> source).
> If someone *can* change your sources he would just embed the exploit
> directly into your code, not in the tokens :)
I'd still also try to avoid using eval. Actually class names might
sometimes come from untrusted sources (e.g. in serialized classes).
Usage of eval in source loaders is, of course, totally fine.
Cheers
Malte
>
> On Mon, Nov 29, 2010 at 1:16 PM, Tom <tomm...@gmail.com> wrote:
>>
>> I have once again investigated a bit on the use of Eval and according to
>> my sources it is far from recommended to use and should not be necessary in
>> any case.
>
> There are perfectly valid use cases for "eval". Those who said its not
> needed probably just have background from static languages.
>
> Nickolay
>
Nickolay Platonov
On Mon, Nov 29, 2010 at 11:38 AM, Nickolay Platonov <nick...@gmail.com> wrote:Why dont you split and then look down from the current global scope
> Token is the "id" of the resource - either the name of class in case of
> Joose classes ("Some.Class") or the url - in case of non-joose code.
>
> I'm using eval to translate the string "Some.Class" to the `Some.Class`
> constructor.
using symbolic dereferencing?
Sure, thats possible. "eval" was just an instant solution.
> This doesn't introduce any security vulnerabilities as "eval" is being usedI'd still also try to avoid using eval. Actually class names might
> on the piece of your own code (and not on something that came from untrusted
> source).
> If someone *can* change your sources he would just embed the exploit
> directly into your code, not in the tokens :)
sometimes come from untrusted sources (e.g. in serialized classes).
Usage of eval in source loaders is, of course, totally fine.
So such code should be executed in some sort of sandbox anyway.. I'm still not completely convinced, perhaps
someone could provide an example in which the usage of "eval" to evalute the class name will introduce security hole?
And patches welcome of course.
Nickolay