1668777 - Security: Access to Gmail account cookies and website spoofing

Status: RESOLVED DUPLICATE of bug 371923

(Firefox :: Security, defect)

Description

[Jose María Acuña]

Steps:

1- The user is instructed to select the Gmail access icon and drag it to the favorites bar.
2- The user clicks and accesses his account
3- With a double click the javascript code is executed and the Gmail session cookies are intercepted and the web page can also be impersonated.
This information could be captured from the attacker's domain.

Video is attached.
PoC: https://www.finanser.es/test/gmail.html

Mozilla Firefox Version 81.0.1 (64-bit)

Comment 3

[:Gijs (he/him)]

If I drag this to the bookmarks toolbar, I just get a bookmark pointing to the image (ie https://ssl.gstatic.com/ui/v1/icons/mail/rfr/logo_gmail_lockup_default_1x.png )

You also wrote you attached a video but I do not see it - neither is it in the 2 duplicates you filed?

Comment 4

[Jose María Acuña]

Sorry, I submitted the bug twice because the form apparently was throwing an error.
Video: https://drive.google.com/file/d/1DISajPNY8kB731PnxSVx92-En1jtcnoS/view?usp=sharing

Comment 5

[:Gijs (he/him)]

I still cannot reproduce.

The JS bookmark is:

javascript:location.href="https://mail.google.com/mail/u/0/";setTimeout(function(){window.stop();document.write("This is not Google");alert("Document.cookie:\n\mail.google.com"+document.cookie)},500)

For me, the timeout ends up not running when I'm logged in to google, because the page navigates before the timeout resolves so it's thrown away.

As it is, when I try the other parts of the exploit separately, it seems that the JS runs on whatever the current page is - so the document.write is a lie - you're executing document.write on the gmail webpage, and so that's whose cookies you get.

(In reply to Jose María Acuña from comment #0)

3- With a double click the javascript code is executed and the Gmail session cookies are intercepted and the web page can also be impersonated.
This information could be captured from the attacker's domain.

Whatever the current webpage is will be what is alerted. This doesn't seem like it achieves anything that a bookmark for javascript:alert(document.cookie) wouldn't also achieve, so I think this is a dupe of bug 371923

Comment 6

[Jose María Acuña]

And wouldn't it be possible to send the cookie to the attacker's server in a parameter of an ajax request?

Comment 7

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #6)

And wouldn't it be possible to send the cookie to the attacker's server in a parameter of an ajax request?

Sure, but any JS bookmark will do that if you convince the user to create that bookmark and then run it against the victim's page, which is exactly what you need to do here...

Comment 8

[Daniel Veditz [:dveditz] out until Nov 10]

Another mitigation could be that we don't let user's create bookmarklets by dragging (we probably have a bug on that, too), just as we don't let users paste "javascript:..." urls into the awesomebar. But yeah, bookmarklets are a known sharp edge here. Gijs: do you know of any such bug or plan? If not I'm ok duping to 371923

Comment 9

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #8)

Another mitigation could be that we don't let user's create bookmarklets by dragging (we probably have a bug on that, too), just as we don't let users paste "javascript:..." urls into the awesomebar. But yeah, bookmarklets are a known sharp edge here. Gijs: do you know of any such bug or plan? If not I'm ok duping to 371923

bug 1156967