Re: Use Case: Cryptographic primitives can help check source integrity before executing Javascript code previously stored in local storage.

On 8/27/12 11:58 AM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>
wrote:

>I think we should distinguish between threats that need to be protected
>against at the user agent level and those that can be protected against
>by code running inside an environment provided by the user agent. A
>WebCrypto API can only do the latter. It seems to me that the source
>integrity problem is in the former class.

Except when the source is stored in localStorage and evaluated by the
application code itself using `eval`. Which is pretty much what everyone
(from Gmail to Bing) does on mobile these days[1].

>Unless I'm missing something, the countermeasure described by Lekies is
>only a proof of concept. I don't think he's claiming that implementing a
>solution this way would actually protect you against an attacker in the
>future. The technique used in the implementation (i.e. overriding the
>browser's implementation of localStorage) is also available to an
>attacker who can inject script.

The premise to any security conversation around JavaScript is that once an
attacker is able to inject a script, all bets are off.

What I'm trying to describe here is a situation where the environment is
not compromised and is about to evaluate code which has been stored in
localStorage and might have been tampered with by another user of the same
device.

Verifying that said code has not been tampered with and is safe to
evaluate is easily done by checksumming it (using code and checksums that
were not themselves stored in localStorage, obviously).

>In other words, what stops the attacker from also overriding your
>localStorage wrapper with their own implementation that does not do any
>security checks?

If potentially tampered code is checksummed before being evaluated then
this situation doesn't arise (unless of course you have other
vulnerabilities, but then, again, all bets are off).

>I think many aspects of the problem are well captured in the Matasano
>blog post that Harry posted to a different thread:
>http://www.matasano.com/articles/javascript-cryptography/

That post addresses a number of issues. To the best of my understanding,
none pertain to this particular problem.

--tobie

---
[1]: Unless they're ready to store JS code in localStorage and eval it
programmatically, developers have to choose to either concatenate all of
their JS code together and incur a complete cache busts every time a
single line of JS is modified, or send all JS files separately and incur
high network latency costs. Storing the JS in localStorage allows sending
diffs across the wire (rather than a new versions of the JS) and applying
these diffs before evaluating the JS. Note that in parallel to trying to
make this hacky solution more secure by interacting with this WG, I've
also brought the underlining problem to vendors. It seems diffing could be
added at the HTTP level, which would avoid app developers having to do it
manually.

Received on Monday, 27 August 2012 14:56:47 UTC