Cookie.Json.js (a Mootools version of CookieJar)
UPDATE: This code is now in the plugins directory of the mootools library as Hash.Cookie.
Over on Ajaxian there was a recent post about a little Prototype.js dependent class called CookieJar.
Lalit Patel has created a JavaScript Library to use JSON to store data in cookies. JSON Cookies is built on top of Prototype and gives you a simple API to put and get JSON values into cookies
I liked the idea, so I wrote a version for Mootools. The Mootools version is a little different and adds some functionality (for merging data) and it stores its info a little differently, but it’s basically the same concept.
Examples:
var cookieJar = new Cookie.Json('clientSideTest');
/* writes a new object in its entirety */
cookieJar.save({
apple: 'red',
lemon: 'yellow'
});
console.log(cookieJar.get('apple')); /* logs 'red' */
/* adds a key/value */
cookieJar.set('lime','green');
console.log(cookieJar.get('lime')); /* logs 'green' */
/* merges new data, overwriting anything already present */
cookieJar.merge({
apple: {
sweet: 'red',
sour: 'green'
},
grape: 'purple'
});
console.log(cookieJar.get('apple').sour); /* logs 'green' */
/* fills in data, leaving anything already present; so apple is not overwritten */
cookieJar.fill({
apple: 'red',
orange: 'orange'
});
console.log(cookieJar.get('apple')); /* logs {sweet: 'red', sour: 'green'} */
/* empties the cookie jar */
cookieJar.empty();
April 16th, 2007 at 9:53 am
My concern with this is that it evals the contents of a cookie, which is user editable. It’s obscure, but it makes me nervous.
The Json.evaluate is:
evaluate: function(str){
return eval(’(’ + str + ‘)’);
}
which doesn’t check for actual json formatting. So if I could set you up with a malicious cookie, I could do whatever I wanted. I could be overreacting, but still, it makes me nervous.
April 16th, 2007 at 10:16 am
A method in the Mootools JSON object for validation of JSON structures would be nice. I have seen such things around the web, however, they are not tiny and I wonder about bloat within Mootools if such a thing were added.
Maybe there’s a wicked regex w/recursion way of doing it 5 lines of code or something…
April 16th, 2007 at 10:59 am
@Ethan, how would someone set a malicious cookie unless they already have dangerous access to you? Exploiting this, it seems to me, is a smaller problem than the access they implicitly already have.
April 17th, 2007 at 8:40 am
@Aaron
It could be a browser bug that lets them do it, it could be something else. But it’d be a great way to sneak something into their machine that they probably wouldn’t notice. Stick a javascript portscanner into the cookie of a site admin (or someone who you know is on the intranet), and there you go.
Or the owner could change the cookie themselves to set variables in the site’s javascript, or do other interesting things to the site.
I’m not a security expert, so my ability to give hard examples is weak at best, but allowing the execution of unknown javascript on the sites makes me nervous.
April 17th, 2007 at 9:36 am
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…
April 17th, 2007 at 1:05 pm
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?
April 17th, 2007 at 2:50 pm
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.
April 17th, 2007 at 7:46 pm
I’ve updated the Cookie.Json class with a test to ensure that the code evaluated is valid Json.
April 20th, 2007 at 6:19 am
…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.
May 14th, 2007 at 4:06 pm
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
May 14th, 2007 at 5:22 pm
Thanks ragaskar. We did indeed rename it when it moved into Mootools; my bad for not updating this post.
May 8th, 2008 at 12:55 am
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
May 8th, 2008 at 8:47 am
Nice article Jonah.
June 14th, 2008 at 11:31 pm
[...] MooTools port [...]