On Jul 9, 2012, at 3:07 PM, Antonio Manuel Amaya Calvo wrote: > On 09/07/2012 22:55, Jonas Sicking wrote: >> >> 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.
We should be careful to not confuse data and code loading. We can ensure that the code that is reviewed and approved is the only code that runs with privilege. But if that code chooses to load the background from a remote server, or show an iframe or other content from an arbitrary 3rd party server, then that is the risk the developer is accepting (and, by extension, the marketplace that approved it). We cannot prevent applications from loading assets from other servers without destroying most of the useful test cases. The particular (UI spoofing) threat you mention is not mitigated by restricting where the data can be loaded from. The developer's server could provide that fake background, or act as a proxy to load data from any server in the world. Trying to prevent apps from loading data is not an effective solution to this problem. That is better handled by careful review process and consequences for developers that violate these conditions. >> 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 :) This isn't just the web though… desktop and mobile ecosystems allow essentially unlimited network access. Yes, Android has network access as a permission but I've literally never installed an app that didn't request it, and the user can't restrict it anyway. A safe ecosystem that results in no interesting apps is not a successful outcome. >> >> 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. > For such an attack I wouldn't even bother with a trusted app. A regular web installed app lets me mount that attack without any review or oversight, as it doesn't require any interesting privileges. Lucas. _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
