1003674 - install WebAPP with slow doubleclick (clickjacking) (missing focus delay)

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Web Apps, defect, P1)

Description

[Jordi Chancel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140421221237

Steps to reproduce:

go to https://alternativ-testing.fr/Research/test666.html and doubleclick slowly or tripleclick on the button 

Result :

App is installed


Actual results:

WITH A SLOW DOUBLECLICK OR A TRIPLECLICK IT'S POSSIBLE TO INSTALL a WEBAPP !


Expected results:

with clickjacking it's possble to install a webapp.

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

This gives the proper door-hanger that asks the user if they want to install the item. A user could accidentally install if the door-hanger acceptance happens to overlay the click location. I believe this is sec-low or sec-moderate at best.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

I can reproduce the problem.  I guess it's similar to the clickjacking attack on the addon installation dialog.  And presumably the solution is the same: disable the button for a few seconds after the doorhanger appears (except when the user opens the doorhanger by clicking the app icon in the URL bar after previously dismissing it, since the user can't be tricked by the page in that case).

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Erm, moving this back to the Core product to return it to the core-security group it was in.

Comment 4

[Daniel Veditz [:dveditz]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #2)
> I can reproduce the problem.  I guess it's similar to the clickjacking
> attack on the addon installation dialog.

Yes, this is a generic pattern that all "dangerous" confirmation dialogs should follow. See bug 162020 for example.

But I thought the lack of delay in this particular dialog was already filed. Dupeme?

Comment 5

[Jordi Chancel]

what is the severity of this vulnerability please?

Comment 6

[Jordi Chancel]

this way can works with webRTC too.
do you need a new testcase?

Comment 7

[Daniel Veditz [:dveditz]]

Didn't you already file a bug on the webrtc dialog?

For the APP issue I'm calling this sec-low because WebApps can't do anything more dangerous than a web Page. This is sort of the equivalent to a "pinned tab" except it clutters up your desktop. Annoying, but not terrible.

There are web apps with permissions, but we only allow those to be installed from our Marketplace site, and they've been reviewed for safety. If you've got a way to plant an unsafe marketplace app and then hack the marketplace site both of those would be severe problems and should be addressed in separate bugs.

Myk: please check my understanding that WebAppRT will only install apps with permissions from the marketplace site.

Comment 8

[Marco Castelluccio [:marco]]

(In reply to Daniel Veditz [:dveditz] from comment #7)
> Myk: please check my understanding that WebAppRT will only install apps with
> permissions from the marketplace site.

That's correct. Right now privileged apps (that can access sensitive APIs) can only be installed from our marketplace.

Comment 9

[Marco Castelluccio [:marco]]

In the addon case we have a doorhanger and then a dialog with a button disabled for three seconds.
I think in our case we can just disable the doorhanger button for three seconds (without opening a new dialog).

Comment 10

[Jordi Chancel]

Attachment: WEBRTC TESTCASE1.html

With WebRTC I think that this vulnerability is now Sec-Moderate isn't it?

Please UPDATE THE SEVERITY.

Comment 11

[Marco Castelluccio [:marco]]

(In reply to Jordi Chancel from comment #10)
> Created attachment 8419280 [details]
> WEBRTC TESTCASE1.html
> 
> With WebRTC I think that this vulnerability is now Sec-Moderate isn't it?
> 
> Please UPDATE THE SEVERITY.

Could you file another security bug for this issue? Here we'll track the app installation bug.

Comment 12

[Marco Castelluccio [:marco]]

Notice that we already have a "security delay" for popup notification buttons: http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/PopupNotifications.jsm#930

It was introduced in bug 583175, where 500 ms was deemed a good compromise between avoiding this security issue and not annoying users.

I'm not sure why sometimes it doesn't correctly work in our case. The timeSinceShown value (http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/PopupNotifications.jsm?rev=7f5a8526b55a#921) sometimes is obviously incorrect (like 20 seconds).

Anyway, I think we should probably increase this timeout.

Comment 13

[Marco Castelluccio [:marco]]

Looks like sometimes if you dismiss the popup (or reload the page) and re-open it, the timeSinceShown value is incorrect.

I clicked the button in the webpage several times and the install button once, then dismissed the popup notification. Repeated this several times.

These are the timeSinceShown values:
> TIMESINCESHOWN: 184.63593200000105
> TIMESINCESHOWN: 298.185177000003
> TIMESINCESHOWN: 56.31000899999708
> TIMESINCESHOWN: 180.38798300000053
> TIMESINCESHOWN: 305.8437239999985
> TIMESINCESHOWN: 30014.85982
> TIMESINCESHOWN: 60.59432299998298
> TIMESINCESHOWN: 184.55681300000288
> TIMESINCESHOWN: 126295.78562000001
> TIMESINCESHOWN: 362932.824662

Three of them are obviously wrong.

Comment 14

[Matthew N. [:MattN]]

(In reply to Marco Castelluccio [:marco] from comment #13)
> Three of them are obviously wrong.

Can you dump the two operands as well?

Comment 15

[Marco Castelluccio [:marco]]

TIMESINCESHOWN: 34988.060805
TIMESHOWN: null
perfNow: 34988.106882

I've just noticed there's an error logged before this happens:
JavaScript error: , line 0: Property 'handleEvent' is not callable.
JavaScript error: , line 0: Property 'handleEvent' is not callable.

Comment 16

[Matthew N. [:MattN]]

The delay doesn't seem to be working in some cases and that should be fixed in this bug.

Comment 17

[Jordi Chancel]

(In reply to Marco Castelluccio [:marco] from comment #11)
> (In reply to Jordi Chancel from comment #10)
> > Created attachment 8419280 [details]
> > WEBRTC TESTCASE1.html
> > 
> > With WebRTC I think that this vulnerability is now Sec-Moderate isn't it?
> > 
> > Please UPDATE THE SEVERITY.
> 
> Could you file another security bug for this issue? Here we'll track the app
> installation bug.

Bug Reported :
https://bugzilla.mozilla.org/show_bug.cgi?id=1009833

Comment 18

[Myk Melez [:myk] [@mykmelez]]

Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.