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

UniversalPhishing (UniversalWebApp) privileges

Categories

(Core :: Security: CAPS, defect)

x86
Windows XP
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.