I don't (yet) have an opinion on the relative merits of different alternatives, but likewise I am perfectly willing to entertain the possibility that eval should be ignored when untrusted data sources are involved. I think the smart way to go, as another poster mentioned, is to measure the alternatives to see if they have significant disadvantages, and, if so, each developer can design accordingly.
Pete Gontier <http://pete.gontier.org/> P.S. Encryption does not imply trust. Identity might. On Oct 9, 2008, at 2:02 AM, Simon Ask Ulsnes wrote: > > Oh, I'm all for using JavaScript anywhere and all over the place! > Especially now we have such an excellent interpreter for it. > > Data source trust issues are important to consider. It is, however, > fairly irrelevant to the original criticism, which was related to the > performance of parsing JSON structures using eval() in V8. > > Using eval() is always dangerous. But I fail to see the need for an > external parser just for JSON. If you are exchanging data with an > external source over an unencrypted connection, then yes, using eval() > is a critical bug. But there are other ways. > > For instance, it would be fairly simple to implement an evalJSON() > method that rejects all function calls. To obtain production-ready > security, you probably need more than that, but I'm just throwing > examples out there. > > - Simon > > 2008/10/9 David Champion <[EMAIL PROTECTED]>: >> >>>> It's not just for server-side JavaScript. There are any number of >>>> conditions where an interpreter might parse JSON from an unknown or >>>> untrusted source. >>> >>> Can you mention an example or two? I'm interested, because I >>> couldn't >>> think of other examples. :-) >> >> I'll incorporate what Pete Gontier said by reference, then add that >> you seem to be thinking of V8 only in terms of its role in Google >> Chrome. Once you begin to think of it simply as an embeddable >> ECMA-262 >> implementation, the possibilities for this situation are endless. >> >> * People are talking about V8 as a scripting engine for games. >> Consider >> downloadable skins, extensions, modules, etc for such a game which >> might >> store certain data in JSON object files. >> >> * JavaScript could be a platform implementation language for >> components >> in any web application framework; JSON data might be loaded from >> any data provision source (with or without an HTTP proxy involved). >> Imagine, say, an analysis engine for electoral data which allows the >> user to point the applicaton to any source of data accessible by the >> browser. It need not necessarily be a browser (i.e., application >> hosting platform) that provides standard XSS privilege limitations. >> >> * I might develop a GPS interface program that downloads tracking >> data >> from my GPS device and stores it in JSON format. Some visualization >> product using V8 JavaScript as an internal implementation language >> loads >> that data and does something clever with it. >> >> I don't know, I just made those up off the top of my head. Keep >> going, >> it's easy once you stop thinking of JS as an exclusive property of >> web >> browsers. :) >> >> -- >> -D. [EMAIL PROTECTED] NSIT University of Chicago >> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
