308496 - AJAX pages can load insecure content without user noticing (avoiding mixed content warning)

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Holger Rabbach]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

Pages that dynamically load content from the server using javascript and xml
techniques (AJAX) can fool the user into believing that the data transfer is
secured with SSL, when in fact the transfers in the background are going
unencrypted between the javascript application and the server. This imho is a
serious security problem that should be addressed asap, at least the user should
be made aware that insecure content is being loaded.

Reproducible: Always

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

I'm not sure how our lock icon works... I think any time an insecure request is
added to the loadgroup, the icon should change to mixed/unencrypted.

Comment 2

[Daniel Veditz [:dveditz]]

(In reply to comment #1)
> I'm not sure how our lock icon works... I think any time an insecure request is
> added to the loadgroup, the icon should change to mixed/unencrypted.

The UI should definitely change to mixed in this case.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is this a matter of us not changing the lock icon after onload has fired?  I
seem to recall something like that, but maybe I'm wrong?

Comment 4

[Darin Fisher]

We update the lock icon whenever we see a STATE_TRANSFERRING WPL event.  I think
WPL events are suppressed for LOAD_BACKGROUND content, so we should make sure
that LOAD_BACKGROUND isn't the culprit.

Reporter: can you post a sample page that demonstrates the problem?  Or, can you
provide further details on how you've managed to work around the lock icon?

Comment 5

[Kai Engert (:KaiE:)]

Could you please provide a testcase?

Comment 6

[Jesse Ruderman]

Keeping this bug hidden doesn't protect users, so I'm making it public.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ah, for XMLHttpRequest we certainly use LOAD_BACKGROUND...

We also use it for background images.  Does that mean that insecure background images won't trigger the broken lock icon?

Comment 8

[Jesse Ruderman]

Yes, see bug 305284.

Comment 10

[Honza Bambas (:mayhemer)]

Assigning to me, to track this bug.

Comment 11

[timeless]

it sounds like the work involved is probably in security ui (the wpl) and not dom (since it presumably does add the requests to the loadgroup, albeit w/ LOAD_BACKGROUND).

Comment 12

[Boris Zbarsky [:bzbarsky]]

The point is that necko sends no notifications to _anyone_ about LOAD_BACKGROUND loads.  So the security UI can't really do much about them.

Comment 13

[Honza Bambas (:mayhemer)]

I have plans to change the way we collect (in)security state of all requests inside a load group.  So, it's gonna work also for background requests, while those are added to the same load group.

Comment 14

[Matthew N. [:MattN]]

Attachment: PHP Test case for Sync & Async XHR

Comment 15

[Honza Bambas (:mayhemer)]

Releasing this, but still on my radar.  I would like to get this later back again.

Comment 16

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Tanvi, didn't you just fix this with nsMixedContentBlocker?

Comment 17

[Tanvi Vyas[:tanvi]]

(In reply to Brian Smith (:bsmith) from comment #16)
> Tanvi, didn't you just fix this with nsMixedContentBlocker?

Yes, this should be fixed by the patches in bug 822367 and bug 782654.