<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet href="https://dev.horde.org/themes/horde//default/feed-rss.xsl" type="text/xsl"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> 
 <channel> 
  <title>Upgrade Prototype to 1.5.1_rc3 and make use of CSRF protection</title> 
  <pubDate>Fri, 10 Apr 2026 05:21:33 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/5307</link> 
  <atom:link rel="self" type="application/rss+xml" title="Upgrade Prototype to 1.5.1_rc3 and make use of CSRF protection" href="https://bugs.horde.org/ticket/5307/rss" /> 
  <description>Upgrade Prototype to 1.5.1_rc3 and make use of CSRF protection</description> 
 
   
   
  <item> 
   <title>http://prototypejs.org/2007/4/24/release-candidate-3



It&#039;d</title> 
   <description>http://prototypejs.org/2007/4/24/release-candidate-3



It&#039;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&#039;ing. See http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf and http://dev.rubyonrails.org/ticket/7910</description> 
   <pubDate>Wed, 25 Apr 2007 19:27:45 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32270</link> 
  </item> 
   
  <item> 
   <title>Saw this on Thursday, but I was going to wait to upgrade (al</title> 
   <description>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 &quot;soon&quot;.</description> 
   <pubDate>Thu, 26 Apr 2007 09:38:54 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32300</link> 
  </item> 
   
  <item> 
   <title>Upgraded to 1.5.1 today.  Added security delimiter to imp/di</title> 
   <description>Upgraded to 1.5.1 today.  Added security delimiter to imp/dimp code.  Not sure where else we are using JSON returns (ansel maybe?)</description> 
   <pubDate>Wed, 02 May 2007 18:24:07 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32486</link> 
  </item> 
   
  <item> 
   <title>Horde_Tree at least, and yes Ansel.</title> 
   <description>Horde_Tree at least, and yes Ansel.</description> 
   <pubDate>Wed, 02 May 2007 18:26:47 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32489</link> 
  </item> 
   
  <item> 
   <title>&gt; Upgraded to 1.5.1 today.  Added security delimiter to imp/</title> 
   <description>&gt; Upgraded to 1.5.1 today.  Added security delimiter to imp/dimp code.  

&gt; Not sure where else we are using JSON returns (ansel maybe?)



ansel/lib/Views/Gallery.php</description> 
   <pubDate>Wed, 02 May 2007 18:30:50 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32490</link> 
  </item> 
   
  <item> 
   <title>&gt; Horde_Tree at least, and yes Ansel.



But we are not retu</title> 
   <description>&gt; Horde_Tree at least, and yes Ansel.



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.</description> 
   <pubDate>Wed, 02 May 2007 18:42:53 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32493</link> 
  </item> 
   
  <item> 
   <title>I&#039;ll have to think about that one a bit more myself. Meanwhi</title> 
   <description>I&#039;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.</description> 
   <pubDate>Wed, 02 May 2007 19:22:21 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32496</link> 
  </item> 
   
  <item> 
   <title>&gt; I&#039;ll have to think about that one a bit more myself. Meanw</title> 
   <description>&gt; I&#039;ll have to think about that one a bit more myself. Meanwhile, we 

&gt; use it in Gollem in a similar style as to IMP/DIMP I believe.



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



I think the question boils down to &quot;how much do we trust any input that we are outputting via JSON.&quot;  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.</description> 
   <pubDate>Wed, 02 May 2007 20:27:28 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32499</link> 
  </item> 
   
  <item> 
   <title>The issue isn&#039;t actually whether or not we trust the output </title> 
   <description>The issue isn&#039;t actually whether or not we trust the output of our scripts; it&#039;s that without the security header, a malicious site can load the javascript we output without the user knowing (provided that they&#039;re logged in to Horde).



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



For things like Horde_Tree we&#039;re probably okay unless we make the data available with a text/javascript (or */*) content-type.</description> 
   <pubDate>Thu, 03 May 2007 03:54:41 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t32509</link> 
  </item> 
   
  <item> 
   <title>imp.js.php and dimp.js.php are served as javascript, so if w</title> 
   <description>imp.js.php and dimp.js.php are served as javascript, so if we don&#039;t protect them, someone can request them remotely (assuming a user is logged in to horde, which isn&#039;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&#039;t just call evalJson in those files - then the attacker would just define evalJson), or inlined like I did for Kronolith and Gollem.



I&#039;m hoping to pass this off since Michael, you&#039;re more familiar with the current js structure of dimp/imp, and frankly I&#039;m a bit friend on bugs at the moment. Had a bad weekend with Turba. :)</description> 
   <pubDate>Tue, 19 Jun 2007 04:48:26 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t34405</link> 
  </item> 
   
  <item> 
   <title>imp.js.php and dimp.js.php have been removed.</title> 
   <description>imp.js.php and dimp.js.php have been removed.</description> 
   <pubDate>Wed, 20 Jun 2007 19:33:55 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5307#t34490</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
