imp.js.php and dimp.js.php have been removed.

imp.js.php and dimp.js.php are served as javascript, so if we don't 
protect them, someone can request them remotely (assuming a user is 
logged in to horde, which isn't far-fetched for these purposes) and 
steal a session id embedded in the javascript. So these need to be 
changed to go through the /*secure* trick somehow (and they can't just 
call evalJson in those files - then the attacker would just define 
evalJson), or inlined like I did for Kronolith and Gollem.



I'm hoping to pass this off since Michael, you're more familiar with 
the current js structure of dimp/imp, and frankly I'm a bit friend on 
bugs at the moment. Had a bad weekend with Turba. :)

The issue isn't actually whether or not we trust the output of our 
scripts; it's that without the security header, a malicious site can 
load the javascript we output without the user knowing (provided that 
they're logged in to Horde).



gollem.js.php doesn't contain anything that I could imagine being 
useful, but since it can be requested directly, it's the sort of thing 
that should probably be protected.



For things like Horde_Tree we're probably okay unless we make the data 
available with a text/javascript (or */*) content-type.

Outputting JSON directly in our javascript includes is no different 
than writing some javascript code such as "var a = { b: 1 };".  That 
is JSON, but you can't tell me we need to run every single object we 
create through evalJSON().



I think the question boils down to "how much do we trust any input 
that we are outputting via JSON."  Obviously, we can exploit all we 
want if we ourselves are outputting bad JSON.  But if that is 
happening, we are either scheming and mischievous people (unlikely) or 
we need to do a better job of filtering the data on the PHP side 
rather than the browser side.

I'll have to think about that one a bit more myself. Meanwhile, we use 
it in Gollem in a similar style as to IMP/DIMP I believe.

But we are not returning JSON code from a script in these instances - 
we seem to simply be using JSON as a shorthand to serialize objects in 
the javascript code we output.  As far as I can tell, this is not the 
security issue the commenting is meant to avoid - only the case where 
we are directly returning JSON from an open XmlHttpRequest channel.   
Or maybe I am wrong.

ansel/lib/Views/Gallery.php

Horde_Tree at least, and yes Ansel.

Upgraded to 1.5.1 today.  Added security delimiter to imp/dimp code.   
Not sure where else we are using JSON returns (ansel maybe?)

Saw this on Thursday, but I was going to wait to upgrade (along with 
the inevitable scriptaculous upgrades) until the stable version is 
released - since they have promised it "soon".

http://prototypejs.org/2007/4/24/release-candidate-3



It'd be good to add a security delimiter of some sort to our ajax, 
also, taking advantage of the support in rc3 for stripping them before 
eval'ing. See 
http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf and 
http://dev.rubyonrails.org/ticket/7910