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

Hi.
I'm difficult to find out the differences between Tobie's usecase and
Signed Web Application at
http://www.w3.org/2012/webcrypto/wiki/Use_Cases#Signed_web_applications

I think two use cases has similar aim.
protection JS source or libraries from vulnerabilities (cross-site
scripting, tampered, corrupted, etc.)

"checking javascript source integrity" is required for both (Signed-JS and
Tobie's usecase)

I can not find any more discussions for "Signed Web Applications" usecase.
but I believe it was added because of vulnerabilities from client side and
network side both.

as a experienced security manager,
one of important thing always I think is
"how to secure corporate security from me".
and I was able to generate acceptable solutions.

I hope to continue these discussion on ACTION-28.

best regards
mountie.

On Sat, Aug 18, 2012 at 2:51 AM, Ryan Sleevi <sleevi@google.com> wrote:

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


-- 
Mountie Lee

Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net
Twitter : mountielee

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World