andyMatthews.net

Secure storage in JavaScript, a proof of concept

A week or so ago, a fellow JavaScript developer threw down a challenge.

Suppose you wanted to extend the JavaScript Object such that getting and setting data in the object is only possible when providing a predetermined access key. The key is first used to instantiate the SecureObject and subsequently used when storing and retrieving data from the SecureObject. Provide the implementation for a JavaScript function that satisfies the use case.

While I've been using JavaScript for quite a long time, I'm still lacking in some of the more advanced functionality. Prototyping, classes, public and private members, etc. So I decided to take this challenge and see what I could come up with. After doing some research this is what I came up with. You can download the full source, along with the original challenge doc.


// index.html
// script block
var sk = 'abc123';
var myDV = new SecureObject(sk);
myDV.setValue(sk, 'foo', 'bar');
var myVal = myDV.getValue(sk, 'foo');
console.log(myVal);

// SecureObject.js
// full contents
/**
 * Instantiate a SecureObject object
 * SecureObject(accessKey)
 * @accessKey - a string representing the read/write access key
 * returns an instance of SecureObject
 * Andy Matthews - andy@commadelimited.com
 * http://twitter.com/commadelimited
 * http://andyMatthews.net
 * http://commadelimited.com
 * 3/11/2010
**/

function SecureObject(accessKey) {

	// set the secrey access code for this instance
	var key = accessKey;
	// storage object
	var storage = {};

	// make sure that the key is not null, and isn't empty
	if (accessKey ==  undefined || accessKey == ')
		throw 'Accesskey cannot be an empty string';

	// setter
	this.setValue = function(k, n, v) {
		if (k === key) storage[n] = v;
	}

	// getter
	this.getValue = function(k, n) {
		if (k === key && storage[n] != undefined) return storage[n];
	}

}

I'd love to get some feedback. I'd also love to discuss the merits of taking this approach...after all, the files are available as plain text via the browser. How secure is it really, and how far should you trust it? What sorts of applications could take advantage of this approach?

If this article was interesting, or helpful, or even wrong, please consider leaving a comment, or buying something from my wishlist. It's appreciated!

i always laugh a bit when i see the words 'security' and 'javascript' used together ... shall i continue? the concept is pretty cool though!

Steve Withington - March 11, 2010 12:25 pm

I thought much the same thing when I started reading about it. But the other guy mentioned a project by Google, called Caja, that's taking a similar approach. Their code is obviously far better than mine, but it's a sample of where Google thinks things might be going.

andy matthews - March 11, 2010 12:27 pm

hmm, that looks kind of interesting. i struggle thinking of using js as a security framework of any kind though ... to me, no matter how solid it looks, there are just so many holes there. not to mention the fact that it's run on the client side. maybe that's something i just have to get over.

Steve Withington - March 11, 2010 12:35 pm

I don't understand, why would you want to do this?

Jason Dean - March 11, 2010 06:37 pm

@Jason, i don't know if you had a chance to check out the Google project Andy mentioned called Caja (http://code.google.com/p/google-caja/) ... but it does look interesting. it might shed more light on what he's trying to do here.

Steve Withington - March 11, 2010 08:11 pm

Steve Withington - March 11, 2010 08:12 pm

I did look at Caja, and I still don't see any practical use for this or see how it relates to Caja.

Jason Dean - March 11, 2010 10:03 pm

This doesn't directly relate to Caja. It was meant as a challenge to see if it could be done. While it's not perfect, as you can see the key in plain text, it's just meant to show what could be done by smater people than I.

andy matthews - March 12, 2010 12:04 am

This is something I'll need to look into more closely. I have to admit I'm a little hesitant to believe that there is any perfect way to do client-side security just from the aspect of the ease of query injections.

Tyson Cadenhead - March 12, 2010 06:10 am

But I still don't see the point. Sorry, but I don't understand what the practical use for something like this is.

Jason Dean - March 12, 2010 06:49 am

@Jason, actually, i think Andy was kind of asking/feeling the same thing at the end of his post.

Steve Withington - March 12, 2010 07:30 am

@Steve, I see he asked what kind of applications may be able to use this, but he also asked: "How secure is it really, and how far should you trust it?" Secure for what? Trust it to do what? To answer these questions, we really need to know what it is being used for, what it is being secured from, and what kind of data it is supposed to be protecting. "Secure" is relative. For something to be "secure" it needs to protect its charge to the extent necessary to prevent those who should not see it from seeing it (VERY simplified definition). For example, if the idea is to stop a determined user who is sitting in front of the browser from seeing the contents of an JS object, then no, it is not secure. But if the goal is to simply stop one part of the application from using a getter or setter without passing the appropriate key, then maybe it is (But I don't understand the point of doing that). I do not think that the questions asked can be answered without knowing for what this is to be used. If no one knows a uses for it, then I guess one could argue "Sure, it is secure, if you are not going to do anything with it" ;)

Jason Dean - March 12, 2010 08:13 am

@Jason, Perhaps it would be more "secure" if the data storage / retrieval was actually done via AJAX. In this way, the Data access object was just a facade. Of course, in this approach, you'd have to use a callback rather than return the data: getData( key, name, callback )

Ben Nadel - March 12, 2010 02:50 pm