On Mon, Jul 9, 2012 at 3:07 PM, Antonio Manuel Amaya Calvo <[email protected]> wrote: > > > 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.
The store can certainly review the code of the app and see that in the log-in screen, the app is displaying data loaded from the server as background image. If the store doesn't like this it can deny the review. >> 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. Ok, so it sounds like the attack you are worried about is that the app itself will change its behavior and trick the user into entering login credentials for something other than the app. The attack you are describing is possible without network connection too. The app can simply ship both the facebook background image and the bank-of-america background image and swap them as needed. If it wants to, it can obfuscate the bank-of-america background image, or even generate it using code so that there are no image files which the store reviewer might find. However all of these things, including loading the image from a server, is visible by reviewing the code of the application. It's certainly hard to find these things, but no harder than finding any other things through code review. Note that reviewing the app by simply testing the app is *never* going to be a good enough way to review an app. You will always have to look at the code of the app. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
