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. > 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. 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. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
