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

On Fri, Aug 17, 2012 at 5:47 AM, Tobie Langel <tobie@fb.com> wrote:
> Hi,
>
> I was asked to provide more information on the following use case we
> (Facebook) submitted when this group was chartered:
>
> "Cryptographic primitives can help check source integrity before executing
> Javascript code previously stored in local storage."
>
> Is is common for web applications to store JavaScript code in
> localSotrage/IndexedDB etc. and execute portions of it as needed by the
> application, sometimes after having patched the code through a delta
> update downloaded from the server[1]. This is mainly done for performance
> reasons and to reduce network traffic.
>
> Code stored in localStorage/IndexedDB, etc. is vulnerable to malicious
> attempts by users of the same device to modify it in order to gain access
> to the data of another user of the same device. This is typically a
> problem when different users are using the same OS level user and
> consequently have access to the same browser; a very common scenario on
> mobile.
>
> Until the stored code is executed, however, the environment is immune to
> this problem. A simple mitigation strategy when online involves
> checksumming the code to verify it wasn't tampered with before executing
> it. This requires downloading a crypto library and checksums, neither of
> which can be stored locally.
>
> Cryptographic primitives would make downloading a dedicated library
> unneccessary, would be much faster, and would avoid the risk of
> accidentally storing the crypto library in localStorage (which is a
> mistake which is bound to happen).
>
> This vulnerability and a similar mitigation strategy has been described
> recently[2] by Sebastian Lekies.
>
> Hope this helps,
>
> --tobie
>
> ---
> [1]:
> http://www.stevesouders.com/blog/2010/07/09/diffable-only-download-the-delt
> as/
> [2]:
> http://www.sec.t-labs.tu-berlin.de/spring/content/spring7_02_slides_lekies.
> pdf
>
>

Hi Tobie,

The problem you described seems related to trying to protect clients
against local users with privileged local access. However, the slides
you mentioned ( [2] from your mail) are more focused on defending
against attackers in privileged network positions exploiting
vulnerable applications (applications susceptible to reflected XSS
attacks)

So I would seek one clarification: Do you trust the client's local
cache (eg: HTTP cache)? 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.

As such, I'm not sure we can meaningfully protect against client
compromise, although I certainly appreciate and understand the need,
particularly for large sites which may wish to cache information
locally, but only when the privacy can be preserved.

As for Lekies' proposal, it would seem like if an attacker can use
reflected XSS, then they have access to any keys available in that
origin, and thus could possibly bypass these checks. However, not
having done a full analysis to consider the implications, it certainly
seems true at least that exposing the hashing functions could help
make such code smaller/faster.

Received on Friday, 17 August 2012 17:52:02 UTC