On 09/07/2012 22:55, Jonas Sicking wrote:
On Mon, Jul 9, 2012 at 12:55 PM, Antonio Manuel Amaya Calvo <[email protected]> wrote:
On 09/07/2012 21:45, Lucas Adamski wrote:
On Jul 9, 2012, at 12:09 PM, Antonio Manuel Amaya Calvo wrote:
To make things more similar to how web pages normally work, we could
allow
pages from app://developer.com/ to make network requests to
http://developer.com. I.e. the app would be allowed to open
XMLHttpRequest
connections to http://developer.com/ <http://developer.com/.>myapi.cgi
without
requesting any special privileges. Likewise <img>s and <video>s loaded
from
http://developer.com would not be considered cross-origin for example
for
the purposes of tainting when drawn into a <canvas>. This way most of
the
code which would work for a website would work in a packaged app,
except
that the packaged app would have to ensure to use absolute URLs when
wanting to connect to the website.
I agree with everything before this paragraph but... the whole point of
reviewing the application in the first place is to ensure that the
application the user is about to trust is... well, trustworthy, for lack
of a better word. And the users are going to trust the application
because they think that somebody has reviewed the application. And all
of this goes out of the window if we let the application change what it
shows to the user without any kind of review. If, going for the easy
example here, the application has a login page with an image background,
the developer --or anyone that compromises his server-- can change that
log page to resemble whatever page they wish.
That's no different to any other page on the internet, you could say,
and it's true. But this applications are going to have access to a wide
range of abilities, because they're trusted. And even if sometime a
'trusted UI' is provided (something that informs the user that hey, this
application you're interacting with is trusted) they'll be marked as
trusted. So they should behave better than a random web page you found
on the internet.
So for the time being, and unless we can figure a way to add untrusted
content to a trusted base without losing "trustiness", I would say that
for an application to be trusted all its content has to be trusted...
and that if we allow external content (which might make sense for a
video player, for example) then the places where external content can be
shown are monitored and factored in the application review.
Almost all apps load data of the web. If anything its rare to have
apps that don't. Some of those apps load data only from a single
domain, but most of them load data from multiple sources (developer
server for help and other resources, ad servers for monetization, 3rd
party content and services like twitter, flickr, Facebook, etc).
We should keep data and code separate when discussing the security
model. Apps should be able to load data from anywhere; but code
importing (including CSS) is strictly limited to assets included in
the package. Dynamic code creation/injection is mitigated by a
required CSP policy.
Yes and no. The problem is that the barrier between data and code is
diffuse... is a background image on a logging page considered data?
Because I'm pretty sure that I can write a single HTML/CSS/JS that
seems like either a Facebook logging page or a Bank of America logging
page just by changing the background image.
Unless you are suggesting that we don't allow trusted apps to connect
to the internet at all, then this will always be possible.
Hmm yes and no. If we cannot provide any kind of... application closure
that makes reviewing the code meaningful, reviewing it will be
meaningless. 'Trusted' for me means that at least the user interface,
the client side, will remain... trustworthy. That someone has vetoed
what I see as part of the UI, and what that UI does with the received
data. That the data that comes into a messaging application is going to
be shown as messages, and not as other part of the UI, that a media
player application isn't going to transform it appearance into a
Facebook application just by altering the server side.
If you're telling me that we cannot guarantee just by examining the
client side code that a Facebook logging page isn't going to transform
itself into a Bank of America logging page just by downloading some
'data' from the Internet then what I'm saying is that we cannot give
'trust' seals.
And I think it's a matter of expectations. I expect the World Wild Web
to be lawless, ruthless, and untrustworthy. So if I get conned... well,
comes with the territory. But I also expect not to be conned by
something that that if someone I trust (might it be Mozilla, Google,
Apple, or whatever) have said it's trustworthy. After all, I'm going to
be giving it extra permissions because it's... trusted.
So basically, at least we should be able to guarantee that the core user
interface that has been vetoed isn't going to change without re-certifying.
I think that any blank statement such as we can just allow loading
resources from the developer web server isn't going to work... on both
sides. On one hand, it can make a trusted app untrusted (even more so
since we don't even force https as per Jonas description), and on the
other hand for some apps (media consuming apps for example) restricting
its data sources to just the developer site is kinda silly too.
I'm not suggesting that we restrict connections to just the developer's website.
The security model of the web today is that any website can connect
"home" without any security restrictions. I.e. a website can issue
XMLHttpRequests to their own website and read any responses coming off
of that website. Likewise, a website can point an <img> element to its
own website and read the pixel data from the resulting image using
various APIs.
However a website can also connect to any other third party server on
the net. But in that case the server has to indicate that this is ok
in order to prevent the website from stealing private data from the
server. This can be done using for example CORS.
I'm suggesting apps follow exactly the same model. I.e. that they can
connect to the home server without any opt-in from the server, but
connecting anywhere else either requires elevated privileges, or
requires that the server uses CORS or something equivalent.
Yes, that's the security model of the web today... but I stated
previously, the web is anything but trusted. You 'trust' some remote
servers with your data (or to show you data they already have, like
banks) but you don't usually trust them to do anything into your
computer... because you trust them as far as you can throw them basically :)
But before we go further, it's a bit unclear to me what types of
attacks you are worried about and want to protect. Could you please
elaborate that you are worried that either the app can do, or worried
about that someone else can do to attack the app.
The most basic attack is an spoofing or misleading attack. That would be
one in which we've checked a client side application, with it's CSS,
images, HTMLs, etcetera, but we allow remote loading of anything that's
shown to the user as part of the UI. So where we previously saw a
Username:
Password:
with a 'TrustedAppLogo" background image the user can now see a
Username:
Password:
with a Bank of America background.
Now it's perfectly legal for an application to ask for a username and
password to check on it's server, and so the veto would Ok it. But
without changing any client side functionality (I ask for a
username/password and send it to www.trustedapp.com) now I'm doing some
fine phishing.
This is the more basic attack. Now depending on what permissions the
application has asked for and been granted because it was trusted, the
basic attack can be complicated, and the application (either the
original developer or a clever attacker that hacks the server) can find
novel ways to trick the user.
So what I'm worried about is that on the web it's quite easy to
transform "downloaded data" into "user interface". In fact it's not only
easy, it's part of the model. And that model works. It just cannot be
called trusted that way.
Best regards,
Antonio
/ Jonas
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
