On 4/3/07, Victor Bogado <[EMAIL PROTECTED]> wrote: > > > > > That paper is very misleading. It doesn't really have anything to do > > with client-side toolkits at all. > > I don't agree, it is irresponsible from the part of a toolkit to offer > a short-cut to a much desired operation that is known to be > problematic.
Uh, not really. > > > > The exploit in question ONLY applies to JSON arrays. If the server > > does not return an array, then the exploit does not work. If you > > return objects (which almost everyone does anyway) then this exploit > > does not apply. > > > > Bare objects aren't valid JS syntax on their own, but arrays are. > > Additionally the exploit depends on adding setters to Object, which > > only works in Firefox and IE (not Safari or Opera). > > well this is what only 90%, 95% of the whole internet world, I guess > you right not enough to worry about. > > The point is that this is bad, the fact that JSON is runnable simplify > but it makes things harder in the security arena, the ability to be > able to run data is not desirable. It can open a can of worms, even > more if you want to do inter-site operations (web 2.0). My point is that this exploit only applies to a very limited subset of JSON. If you use an array on the outside, then it's possible to leak data. If you use an object on the outside, then the exploit doesn't work because literal objects are only valid JavaScript syntax as part of an expression (which is why you add parens before eval). If the server-side doesn't send arrays, then it's not a problem and we don't need a new specification or any changes to the clients. -bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
