Comments on: Cookie.Json.js (a Mootools version of CookieJar)

By: lalit.lab » Blog Archive » Cookie Jar: Yummy JSON Cookies (using Prototype)

Sun, 15 Jun 2008 07:31:07 +0000

[...] MooTools port [...]

By: Aaron N.

Aaron N. — Thu, 08 May 2008 16:47:38 +0000

Nice article Jonah.

By: Jonah Dempcy

Jonah Dempcy — Thu, 08 May 2008 08:55:06 +0000

Nice work!

I wrote an article on using the Hash.Cookie class in MooTools:
http://www.thetruetribe.com/2008/05/using-mootools-hashcookie-api.html

By: Aaron N.

Aaron N. — Tue, 15 May 2007 01:22:40 +0000

Thanks ragaskar. We did indeed rename it when it moved into Mootools; my bad for not updating this post.

By: ragaskar

ragaskar — Tue, 15 May 2007 00:06:53 +0000

for those of us not following along closely, Cookie.Json was removed on the 22nd of April. Hash.Cookie apparently, should be used for these sorts of tasks. Not clear on whether this is a code-migration or rewrite — but seeing as how this site turns up first for Cookie json mootools, I hope it’ll help someone.

See this changeset: http://dev.mootools.net/changeset/487

By: Jeffrey Schrab

Jeffrey Schrab — Fri, 20 Apr 2007 14:19:29 +0000

…and that is what I had in mind (re: parseJSON). Happy to be part of the conversation that lead to that finding its way in Mootools.

By: Aaron N.

Aaron N. — Wed, 18 Apr 2007 03:46:48 +0000

I’ve updated the Cookie.Json class with a test to ensure that the code evaluated is valid Json.

By: Aaron N.

Aaron N. — Tue, 17 Apr 2007 22:50:23 +0000

Ok, after a bit of thought, here’s what I think of it. The security problem here isn’t a direct vulnerability, but rather a possible exploit of an existing one; an escalation vulnerability.

Let’s say that we have a site like cnet and on this page over in this corner, we have a cross site scripting vulnerability but there’s nothing interesting on this page. Let’s say we store user data in a Json cookie and this cookie is evaluated on every page of the site over. On some other page, the user enters credit card data I can exploit the cross site scripting problem to set a cookie and now I have escalated the cross site problem to every page on the site and now I can snoop your credit card.

So the solution, I think is to ensure that the json isn’t a function, as you recommend. The parseJSON function found on json.org (http://www.json.org/json.js) would solve the problem. I’m going to chat with Valerio about his thoughts on the subject.

By: Ethan Schlenker

Ethan Schlenker — Tue, 17 Apr 2007 21:05:40 +0000

The javascript that they run could alter the page by changing variables while the page is running (as opposed to after the page has loaded, ala firebug or javascript: )

And ‘dangerous access’ is really just a browser bug waiting to be exploited. Google: cross domain cookie injection to see how frequent and widespread the bugs are. It just takes a visit to one bad site. And while it by itself may not be an issue, why enable a potential atacker with more options?

Any thoughts on Jeffrey’s suggestion of a JSON regex / validation?

By: Aaron N.

Aaron N. — Tue, 17 Apr 2007 17:36:54 +0000

I’m not a security expert either, but the scenarios you describe seem to me to really talk about other security issues that would have to be present for this exploit to work. A user can always execute any javascript they want (just use firebug or javascript: in the url field), and a javascript portscanner inserted into the cookie of a site admin implies you already have dangerous access to that user’s machine…