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

On 8/28/12 3:14 PM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>
wrote:

>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.

Correct.

>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.

That's correct except in step #2 the bad guy doesn't need to be offline
(apps are loading code from localStorage both when offline and online).

>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.

That's correct, though in step #3 the loader script could be cached in
http or app cache (anywhere the bad guy can't modify it).

>This scenario appears to rest on two assumptions:
>
>1. Bad guy has offline access to the device/browser to modify
>localStorage.

The access doesn't need to be offline.

>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.

Yes. The bad guy can modify code in localStorage, but cannot modify any of
the code stored on a remote server, in AppCache or in the HTTP cache. He
also cannot modify the browser env itself.

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

Yes and yes.

--tobie

Received on Tuesday, 28 August 2012 15:31:36 UTC