Open Bug 248207 (universalphishing) Opened 20 years ago Updated 2 years ago

UniversalPhishing (UniversalWebApp) privileges

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: danm.moz, Assigned: dveditz)

References

Details

Remote XUL is restricted from opening windows with arbitrary appearance. It can nevertheless override that restriction by requesting UniversalBrowserWrite privileges. But this is a suboptimal solution. UBW is difficult and byzantine to set up. Developers of remote XUL will begin recommending that users begin the undesirable practice of setting signed.applets.codebase_principal_support true and leaving it that way. If remote XUL becomes popular, I foresee a time when the "can we have UBW privileges, please?" dialogs become common enough that users become inured to them, and slap the "Sure!" button as they do mosquitoes. And UBW bestows more privileges than are strictly necessary. So what about a new UniversalPhishing privilege, sufficient for remote XUL's purposes but easier to get and more restricted than UBW?
(spinoff from bug 244965 comment 44) Sounds good to me, though I would call it UniversalWebApp and include other features that webapps commonly need, such as opening/moving/resizing windows, hiding contextmenues, opening windows without statusbar and toolbar, setting cookies, using modal windows, blocking leaving a page, etc. However, as danm points out, there needs to be a good way to give a page UniversalWebApp privileges. If it's too easy to get this security level we'll be unsecure and back to square one. If it's too hard we'll anger developers and users since their applications will break. We could allow for some sort of signing, not sure what we already have when it comes to that. It would also be good to support some form of security zones where IT-departments could preconfigure intranet domains (bug 38966 and bug 165531). We'd probably also need some sort of UI where a homeuser could add his/hers favourite webapp if they want to. Once this is done we should be able to really tighten up what we allow untrusted webpages to do. We could also set webapp developers more free to do what they want with the users UI.
> It would also be good to support some form of security zones where > IT-departments could preconfigure intranet domains This has been a trail of tears of MSIE, and no picnic for IT departments. 0. Do not make a "local machine zone" that can be extended too easily via bugs to include downloaded or even cached files. 1. The browse configurer/distributor is not the same person or dep't as the web app deployer. How does one deploy a web app and cause all 50,000 seats in the enterprise to start trusting the hostnames or even IP addresses from which the web app's pages are served? There will be many wep apps, hosted on many different nodes. 2. Giving *end users* the ability to add to the trusted site list is a mistake. Users end up trusting www.bofa.com, and next month that site is hacked. If the site hack is a "zero day" bug, then the user is toast. Even if the exploit is known, the site's users can't have their trust revoked by the site without its hostname changing. 3. In any case, intranet or Internet, trusting the DNS is tricky, given "Princeton attack" variations. We need a better trust model than one based on hostnames. 4. While it must be very hard for end users to configure any trusted site list, it must be not only easy for a sysadmin to configure a single browser's list -- it must also be easy to centrally administer the list if you are the sysadmin. Sorry if these seem tangential, I wanted to get them down in writing somewhere. We need to look at the big picture before adding UniversalWebApp. And we must consider backward compatibility, as well as cross-browser compatibility, in our anti-phishing thoughts. /be
Summary: UniversalPhishing privileges → UniversalPhishing (UniversalWebApp) privileges
I certainly agree that we need to think this through before implementing, and i guess here is as good as any to discuss :) > 0. Do not make a "local machine zone" that can be extended too easily via > bugs to include downloaded or even cached files. Sounds good to me. > 1. The browse configurer/distributor is not the same person or dep't as the > web app deployer. How does one deploy a web app and cause all 50,000 seats in > the enterprise to start trusting the hostnames or even IP addresses from which > the web app's pages are served? There will be many wep apps, hosted on many > different nodes. Hopefully the distributer can mark an entire zone as trusted, like ".us.ibm.com" under wich all servers would be trusted. Or an ip-range such as "192.168.*.*". For cases where this is not possible maybe the webapp deployer could supply an xpi that would add the site as trusted. Alternativly they could go the signed route. Also, while we're here. It might be usefull to be able to trust just a subfolder of a server. Like just trusting a single "site" on geocities. Unless there's too big of a risk of exploitable bugs. > 2. Giving *end users* the ability to add to the trusted site list is a > mistake. Users end up trusting www.bofa.com, and next month that site is > hacked. If the site hack is a "zero day" bug, then the user is toast. Even > if the exploit is known, the site's users can't have their trust revoked by > the site without its hostname changing. I'm not entierly sure I follow you here, what's a "zero day bug"? I did have hacked sites in mind though, and at least for a UniversalWebApp privilege I don't think it would be too big a deal if a trusted site got hacked. I imagine such a privilege not being able to actually harm my computer or extract information from it. At worst it would be able to flood me with modal popups or huge windows. So a hacker wouldn't have anything to gain from hacking a trusted site and injecting evil code, nor would it be a big deal if he did. > 3. In any case, intranet or Internet, trusting the DNS is tricky, given > "Princeton attack" variations. We need a better trust model than one based on > hostnames. Hmm.. this is defenetly tricky. Maybe we should limit this to signing? Though I have a feeling that signing currently is too tricky for many developers.
I really think this bug should be WONTFIX as it stands, and we should instead fix our default permissions to be smarter and more permissive with user control. I don't think web apps have any intrinsically different needs than web pages, and we should make it so that untrusted web sites have the power to do a lot, but fully controllable by the user: Untrusted content should have the ability to open modal windows (or at least page-modal windows). And at least *add* options to context menus (WHATWG HTML extension is in order here!), and probably turn off the default context menu items by default (again, allowing the user to turn them back on). And display "minimal" chrome by some definition of minimal. My definition of minimal includes a status bar of some sort, see my blog posts http://www.saintpatrickdc.org/bsmedberg/index.php?p=24 and 23 and 22 The only real tussle I see is with popup blocking, since there are fairly many web-app-like systems that might want to open "toolbar" windows or similar mechanisms on startup.
I defenetly don't think we can cram trusted webapps and untrusted webpages into the same security boundries. Webapp developers want to do a lot of things that I don't want any untrusted page to be able to do. This includes popups chromeless windows modal windows (page-modal doesn't work too well with tabbed browsing) replacing contextmenues (just adding items isn't enough for many developers) webapp developers wants to be able to write applications that are as similar to desktop apps as possible, having extra chrome such as statusbars or a pile of contextmenu items will be confusing for their users. What they want is the power of desktop apps with the ease of webpages. As a user I don't want any webpage to be able to do the things above, but I want all trusted webapps to be able to do all of it. I don't want to configure the various settings separatly since all configurating is a pain. The default settings should be as pleasant for the enduser surfing the untrusted web as possible, since that's the common task. Also, having users turn on or off these capabilities at will will be a nightmare for webapp developers since they wouldn't be able to rely on any feature. Though I guess we could make the distinction between untrusted and trusted pages as opposed to trusted apps and untrusted web.
(In reply to comment #4) > I don't think web apps have any intrinsically different needs than web pages I completely disagree. Currently we have *no way* to run properly a web app because secure web apps need to be signed in a jar file. This has the following effects: a) you can't use dynamic generated pages b) you can't use dtd's remotely c) you can't add a jar url to popup blocker Though b) and c) are bugs which might be fixed in the future, a) needs a completly another approach.
(In reply to comment #2) > 2. Giving *end users* the ability to add to the trusted site list is a mistake. > Users end up trusting www.bofa.com, and next month that site is hacked. If the > site hack is a "zero day" bug, then the user is toast. Even if the exploit is > known, the site's users can't have their trust revoked by the site without its > hostname changing. > > 3. In any case, intranet or Internet, trusting the DNS is tricky, given > "Princeton attack" variations. We need a better trust model than one based on > hostnames. Regarding 2) and 3) I guess that these cases won't happen that often. What I want to say that I prefer a zone approach rather than having nothing like now. Even signing won't help right now (see previous post). > 4. While it must be very hard for end users to configure any trusted site list, > it must be not only easy for a sysadmin to configure a single browser's list -- > it must also be easy to centrally administer the list if you are the sysadmin. When not the *end user*, who else? When talking about web apps in most cases you don't have any sys admins at all.
Maybe we shold take this to a newsgroup, npm.security or npd.xul perhaps? I'm going to push kinda hard here that we should create a system where "web apps" have the permissions they *need* by default, no signing/whitelisting/special stuff would be *required*. However, these web apps might still look a little cramped, because you can still see some security UI such as a statusbar/whatever. Then as an optional extra step we could grant special privs so that web apps can disable this extra security UI. > popups > chromeless windows > modal windows (page-modal doesn't work too well with tabbed browsing) > replacing contextmenues (just adding items isn't enough for many developers) 1) We already allow popups, except for onload... is there anything unacceptable about the current system for web apps? 2) Totally chromeless windows? I don't ever want that on *my* browser, I want at least a little security UI that shows me what site I'm actually visiting. 3) Modal windows are not really any different than popup windows, as long as you have some basic UI to cancel + block them from the popup itself. 4) replacing contextmenus is also not a serious UI hurdle. We could allow any app to replace the context menu as long as there was one "security" sub-menu, or some way of expanding to see all the security-related items. > webapp developers wants to be able to write applications that are as similar to > desktop apps as possible, having extra chrome such as statusbars or a pile of What they *want* and what they *need* are two different things. I don't mind optionally giving them special stuff, as long as they can continue to work without it. There is no difference between untrusted web apps and untrusted web pages, period. We can't go around pretending that there is; we need to design them together with a reasonable set of permissions that give apps what they need but keep the user in control. Hish, signing is only an issue for http: pages, you don't have to manually sign https: pages since the signing is done at the protocol level. DTDs are also a non-issue here, the problems with DTD loading are entirely technical, not security-related.
First lets set the usecase so were talking about the same senarios here. Imagine a company that uses a pile of custom apps, such as inventory handling, bankbranch terminals, conferance room booking, employee database, project time tracking, TPS reports etc. The company has previously written these as custom desktop apps but want to migrate new versions to webapps to save cost. So in other words, these webapps replace older desktop apps. This is not just some made up example. I've seen it happen for most of the apps mentioned above and I'm sure it'll happen more and more as the browser evolves into a more powerfull platform. > 1) We already allow popups, except for onload... is there anything > unacceptable about the current system for web apps? I'd say that this is largly acceptable. Mostly since I can't think of very many cases where a desktop app would want to open a popup other then when we currently allow it. The one exception I can think of is some app that handles sensitive data and on a timer pops up a 'shutting down in 1 minute to protect confidential data' warning. (we currently don't allow popups on timers iirc) Also, we'll likly have to tighten up our popup blocker as popupblocking browsers gain marketshare. I today ran into the first instance of a site circumventing the mozilla popup blocker. Go to http://www.comics.com/comics/getfuzzy/ and click on the 'snoopy.com' link at the top of the page. And as we tighten the popup blocker we're likly to break more webapps. > 2) Totally chromeless windows? I don't ever want that on *my* browser, I want > at least a little security UI that shows me what site I'm actually visiting. While that applies to you and me, that probably doesn't apply to the people using the apps mentioned above. They might be sitting all day using only different webapps and want them as lean and userfirendly as possible. They couldn't care less what server served the small 'are you sure you want to quit? [yes] [no] [save before]' dialog that they've custommade. I guess you could ask yourself, how would you feel if every mozilla window (or other app that you use often) had some UI saying that "this window is an unsecured webpage loaded from 'webmozsuit.mozilla.org'" > 3) Modal windows are not really any different than popup windows, as long as > you have some basic UI to cancel + block them from the popup itself. Again, more clutter that you probably wouldn't want in every window you delt with. > 4) replacing contextmenus is also not a serious UI hurdle. We could allow any > app to replace the context menu as long as there was one "security" sub-menu, > or some way of expanding to see all the security-related items. I don't want them to touch any of my items, not just the security related ones. I guess we could place the original menu as a submenu (or maybe place the new items as a submenu), but that we be a lot of extra clutter for the webapp users to deal with. Another aspect is that if these users become customed to seing that bar in every window they'll stop paying attention to them. Then when surfing the web and actually end up on pages that try to go Phishing they are more likly to still ignore the bar. Kind of a weak argument I agree, but I figured I should mention it. > > webapp developers wants to be able to write applications that are as similar > > to desktop apps as possible, having extra chrome such as statusbars or a > > pile of > > What they *want* and what they *need* are two different things. I don't mind > optionally giving them special stuff, as long as they can continue to work > without it. Well, they *need* these things in order to develop userfriendly apps. If we find some security model that would allow even internet webapps to become trusted, maybe google or whoever could write a office suite and compete with MS Office. In fact, even if we let all the floodgates open the developers would most likly still be limited. If they were able to read and write directly to your filesystem they could come up with even more powerfull applications. And if we can come up with some way of doing that safly I think we should. But so far I havn't thought of a solution that I feel comfortable enough with. My point is that we need to think outside of what is done on the web currently. The applications will grow with the platform, there is nothing that they *don't* need, just things that will limit the kinds of applications they can write. > There is no difference between untrusted web apps and untrusted web pages, > period. We can't go around pretending that there is; we need to design them > together with a reasonable set of permissions that give apps what they need > but keep the user in control. I agree, that untrusted webapp and untrusted web page is no difference (at least for this argument). What matters is trusted vs untrusted. But the argument is still there, how do we give UniversalPhishing/UniversalWebApp/UniversalTrusted rights to the trusted webapp/web page.
> you don't have to manually sign https: tell that to CAPS...
> tracking, TPS reports etc. The company has previously written these as custom > desktop apps but want to migrate new versions to webapps to save cost. So in Agreed so far. Maybe we should think in terms of distribution. Are these apps still going to be "download-once" XUL apps (run by the xulrunner, for example)? Are they going to be entirely hosted on a local intranet (using https or http), or are they going to be out in the wild (hosted over http or https). Here's the matrix I'm thinking of: UWA+ the app automatically gets UWA UWA? the app or user can request UWA, but the user may refuse to honor request UWA- the app may not request UWA Local download/install (xulrunner): UWA+ Served over HTTP HTTPS/signedJAR Intranet UWA? UWA? Internet UWA- UWA? Even if you are UWA-, the app should be *able* to work (even if less pretty). We should minimize the intrusiveness of the security UI as much as reasonable. This of course leaves up for discussion what "intranet" is, and if that is too "Security Zone"-like. Also, and this depends on some major hacking in CAPS, the xulrunner should ideally be able to run XUL apps with limited privs. For example, you can download an XUL app from some website and run it using the XULRunner. You're not paying the price of network access and synchronicity issues, but you still get a mostly-untrusted application. (Networking and CAPS would need to be integrated/extensible more than today.)
(In reply to comment #11) > > tracking, TPS reports etc. The company has previously written these as > > custom desktop apps but want to migrate new versions to webapps to save > > cost. So in > > Agreed so far. Maybe we should think in terms of distribution. Are these apps > still going to be "download-once" XUL apps (run by the xulrunner, for > example)? Are they going to be entirely hosted on a local intranet (using > https or http), or are they going to be out in the wild (hosted over http or > https). I really think XUL is out of the question at this point, I doubt anyone will want to lock in themselfs to mozilla. And download-once XUL/HTML apps is probably a bad idea too as that puts them back to square one wrt desktop apps hassles. I'm talking about having HTML apps served over the wire, http or https. I think we could get a large enough buyin with https if we can motivate it through security. > Here's the matrix I'm thinking of: > > UWA+ the app automatically gets UWA > UWA? the app or user can request UWA, but the user may refuse to honor request > UWA- the app may not request UWA > > Local download/install (xulrunner): UWA+ > > Served over HTTP HTTPS/signedJAR > Intranet UWA? UWA? > Internet UWA- UWA? > > Even if you are UWA-, the app should be *able* to work (even if less pretty). > We should minimize the intrusiveness of the security UI as much as reasonable. > This of course leaves up for discussion what "intranet" is, and if that is too > "Security Zone"-like. I strongly doubt you'd get a buy-in on that. Writing apps for a platform where random features doesn't work is going to be a hell for the developers. They have enough trouble with different browsers. That would force them to the lowest common denominator, which would be the same as UWA- and you're back to square one again.
> I strongly doubt you'd get a buy-in on that. Writing apps for a platform where > random features doesn't work is going to be a hell for the developers. They have The only feature that might be missing is modal dialogs. jst already agreed that modal dialogs should be allowed in ordinary web content, subject to popup-blocking and user-overriding (see bug 194404), so that wouldn't be subject to the UWA policy. Other than that, I think we're only talking about extra UI goop, no? I think we should imagine this as "lowest common denominator plus some UI-hiding gravy".
(In reply to comment #9) [...] > gain marketshare. I today ran into the first instance of a site circumventing > the mozilla popup blocker. Go to http://www.comics.com/comics/getfuzzy/ and > click on the 'snoopy.com' link at the top of the page. For the record, that site simply opens a window when you click on that image (by sometimes dynamically registering an onclick handler on links), that's intentionally allowed, and I doubt we'll ever be able to do much about that. Blocking windows from opening when you click on things in a webpage would break the web...
I think there'll be more then UI and popups, but I can't think of any good examples yet. So far I've been able to think of access to clipboard, additional keys (F-keys and Ctrl combinations), adding bookmarks (which could be used as a 'save' feature) and crossdomain cookies (though these days many websites ask for this too). (I also seem to recall something about drag and drop being limited for webpages, but I could be making that up, or it might be too risky even for trusted webapps). Granted, this isn't a very big list, but I think if we asked someone that has been doing some webapp development in a larger scale then I have we might get a more comprehensive list. Any webapp developers out there with more suggestions? Any evangelism people out there (doron) that has gotten requests for stuff that IE does that we have deemed too evil to give to the entire web? Or simply stuff that people you've interacted with has requested. Kaply, any IBM customers asked for anything that we could help them out with this?
Actually, there's all the window-interaction functionality, like resize, lower/raise, make unresizeable. And chaging text in statusbar.
It would be very helpful to Web developers as well as other Web browser vendors, if, in the interests of interoperability, this discussion was carried out in the WHATWG mailing list. http://www.whatwg.org/mailing-list We don't want to have to reverse engineer whatever Mozilla does and then try to re-implement it in other UAs.
Alias: universalphishing
Blocks: 177988
QA Contact: caps
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.