On Thursday 26 March 2009 20:10:56 Mike Bush wrote: > I was building a plan for a flog tool when I realised I had overlooked > the Javascript. > > >From what I can see the main security issues with javascript are: > Code insertion
Will need to be filtered before it is written, e.g. by sending it through an XMLHttpRequest to the node?? > AJAX AJAX is not dangerous as such. XMLHttpRequest's are however potentially dangerous; we should disallow them except when used by our libraries. > The eval() function Agreed, although theoretically we could pass the javascript to be evaluated back to the node to be converted into something safe? All of this assumes code mangling... > Possibly some of the higher level DOM objects A lot of DOM: setting src= on an img tag for example is very hazardous for Freenet. There are more subtle attacks however: If we allow javascript apps to insert stuff, which would enable a wide range of applications, it can gather data and then report it back. Specifically, data on which of a specified set of keys are fetchable and which are not, and how fast keys are fetchable. This could become very serious, enabling an attacker to explore datastore contents, connecting boards visited, messages seen, with stuff downloaded, uploaded ... One option is simply to disallow inserts. This is probably what we would want initially. Allowing them only for trusted pages is a hack-around, but it really doesn't solve the problem. Other options get rather extreme: getting/allowing the user to check the contents of the insert (fallible but doesn't allow for high bandwidth covert channels at least), linking to some source review system, delaying responses so that a fetch always takes a fixed time (but this doesn't solve the what-is-available part), using a separate cache AND a separate tunnel ... It's a hard problem in itself, it may not be solvable. Of course theoretically requests could serve the same function but they have much lower bandwidth and it requires a lot of hammering to get a remotely observable result - it may not even be possible given the attacker watching for the key to become more readily available would have to be polling it himself to see whether the javascript applet polls for it! > > Would this be good as a a summer of code project along with a freesite > app as proof of use. This would be a great summer of code project, however IMHO it is far from easy: I would want to be confident that the student would be able to produce something useful! IMHO it is a large enough project that you would not need to produce anything - it being able to deal with pages Specifically, there would be a good deal of code morphing: you need to convert eval() to [ my safe eval function ], but more tricky is that functions are normally called through a hierarchy of objects and objects can be put into variables and then brought back later - it is not necessarily possible at filtering time to know that blah.src means the src attribute on an image, rather than something else ... I had thought you'd need to do run-time type tracking in the morphed code, but another option might be to substitute the hierarchy roots with a "safe" copy ... either way, the basic infrastructure is going to be fairly heavy IMHO. However, I don't really know javascript... If you know javascript, there are other projects you could do too - lots of UI stuff would benefit from javascript e.g. progress bars. > > > On Thu, 2009-03-26 at 18:21 +0000, Matthew Toseland wrote: > > On Thursday 26 March 2009 15:26:19 Daniel Cheng wrote: > > > On Thu, Mar 26, 2009 at 9:47 PM, M <[email protected]> wrote: > > > > I understand that javascript has to be disabled because of the > > > > multitude of security holes it could open up. I was wondering if anyone > > > > had ever thought about a freenetscript similar to how facebook > > > > implemented FBML and FBJS to allow developers lots of scope for > > > > functionality whilst stopping phishing attacks. > > > > > > I did propose something similar in the past. > > > But some developers think it is far better to have a JavaScript > > parser/filter. > > > -- a "good" one, not a "complete" one. . > > > [it can not be comepleted, for it is a proven equivalent to the halting > > problem] > > > > Not true. Only a filter which cannot modify code is equivalent to the halting > > problem. A filter which can modify code and insert guard functions is quite > > feasible: it does not need to know what the long-term behaviour of the code > > is, it just needs to know that the function for e.g. HTML insertion will > > always be fed through our HTML filtering. Having said that, there are various > > subtle attacks which it may not be possible to exclude completely without > > some fairly extreme measures (e.g. not allowing scripts to insert). > > > > Also I don't recall a proposal for a flexible scripting subset, iirc we were > > talking about recipes... > > > > > > > The FreenetScript could be parsed by FProxy and turned into regular > > > > javascript with freenet-only links.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
