Joose3: JXND: Eval is being used quite a lot

5 views
Skip to first unread message

Tom

unread,
Nov 27, 2010, 4:47:07 PM11/27/10
to joos...@googlegroups.com
Hi there,

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

unread,
Nov 28, 2010, 1:10:13 PM11/28/10
to joos...@googlegroups.com
Your debugger (Firebug?) is not able to debug the code which has been *executed* with <script>.
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

unread,
Nov 28, 2010, 2:53:56 PM11/28/10
to joos...@googlegroups.com
You can add a special comment on the first line to make it work nicely
with eval in Firebug.

--
http://twitter.com/cramforce
http://nonblocking.io

Nickolay Platonov

unread,
Nov 28, 2010, 4:04:38 PM11/28/10
to joos...@googlegroups.com
Oh, thanks for the hint, didn't know that.

Tom

unread,
Nov 29, 2010, 5:16:07 AM11/29/10
to joos...@googlegroups.com
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.

I've been told that the use of Eval can cause security vulnerabilities aswell.

Could you tell me why these "tokens" need to be evaluated dynamically using Eval? What are they?

- Tom

2010/11/28 Nickolay Platonov <nick...@gmail.com>

Nickolay Platonov

unread,
Nov 29, 2010, 5:38:21 AM11/29/10
to joos...@googlegroups.com
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.

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 :)


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

Malte Ubl

unread,
Nov 29, 2010, 5:42:46 AM11/29/10
to joos...@googlegroups.com
On Mon, Nov 29, 2010 at 11:38 AM, Nickolay Platonov <nick...@gmail.com> wrote:
> 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

unread,
Nov 29, 2010, 6:15:40 AM11/29/10
to joos...@googlegroups.com
On Mon, Nov 29, 2010 at 1:42 PM, Malte Ubl <malt...@gmail.com> wrote:
On Mon, Nov 29, 2010 at 11:38 AM, Nickolay Platonov <nick...@gmail.com> wrote:
> 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?

Sure, thats possible. "eval" was just an instant solution.
 
> 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.

Well, if a serialized class comes from untrusted source, the hacker would probably modify some method of the class.
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

Reply all
Reply to author
Forward
0 new messages