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

I'd like to understand this use case better. 

Lekies talk about three attack scenarios:
1. Cross site scripting
2. Untrustworthy network (attacker intercepts the connection and injects bad script)
3. Shared browser

It seems like you are talking exclusively about #3 here. In other words, the scenario is:

- Good guy goes to site, site caches JS in localStorage.
- Bad guy somehow accesses the same browser offline, overwrites localStorage with bad JS.
- Good guy goes to site again, runs bad script, gets owned.

The proposed remediation is:

- Good guy goes to site, caches JS in localStorage.
- Bad guy somehow accesses the same browser offline, overwrites localStorage with bad JS.
- Good guy goes to site again. Site downloads non-cacheable loader script, which verifies code in localStorage before running it.

This scenario appears to rest on two assumptions:

1. Bad guy has offline access to the device/browser to modify localStorage.
2. Bad guy can modify localStorage to inject evil script, but cannot modify it to change the verification code, cannot cause the loader script to be cached and cannot modify the browser environment itself.

Is this accurate? Also, do you agree that Lekies's attack scenarios #1 and #2 are out of scope for the WG?

-----Original Message-----
From: Tobie Langel [mailto:tobie@fb.com] 
Sent: Monday, August 27, 2012 7:56 AM
To: Vijay Bharadwaj; Ryan Sleevi
Cc: public-webcrypto-comments@w3.org
Subject: 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 Tuesday, 28 August 2012 13:15:50 UTC