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

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.

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. In other words, what stops the attacker from also overriding your localStorage wrapper with their own implementation that does not do any security checks?

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/ 

-----Original Message-----
From: Tobie Langel [mailto:tobie@fb.com] 
Sent: Friday, August 17, 2012 11:09 AM
To: 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/17/12 7:51 PM, "Ryan Sleevi" <sleevi@google.com> wrote:

>On Fri, Aug 17, 2012 at 5:47 AM, Tobie Langel <tobie@fb.com> wrote:
>
>So I would seek one clarification: Do you trust the client's local 
>cache (eg: HTTP cache)?

Yes. It is not vulnerable to simple scripting through the browser's console. :)

>It would seem like an attacker with local privilege could just as 
>trivially inject code to the cached entry on disk, and from there 
>bypass the app-specific signature verification.

I am not a security expert and I don't know the specifics of how browsers cache scripts received through SSL. (Which itself is an indication of the difference in threat level between both types of attack).

Also, I suppose performing such an attack on certain mobile devices like the iPhone probably imply rooting the device first.

This scenario doesn't.

--tobie

Received on Monday, 27 August 2012 10:00:50 UTC