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

RESOLVED FIXED

Status

Core Graveyard
Security: UI
RESOLVED FIXED
13 years ago
2 years ago

People

(Reporter: Holger Rabbach, Unassigned)

Tracking

(Blocks: 2 bugs, {sec-low})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low][psm-padlock])

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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
Assignee: nobody → general
Component: Security → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: firefox → ian
Version: unspecified → 1.7 Branch
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.
(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.
Blocks: 130949
Status: UNCONFIRMED → NEW
Component: DOM: Mozilla Extensions → Web Services
Ever confirmed: true
Whiteboard: [sg:fix]
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

13 years ago
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

13 years ago
Could you please provide a testcase?

Updated

13 years ago
Whiteboard: [sg:fix] → [sg:low]

Comment 6

12 years ago
Keeping this bug hidden doesn't protect users, so I'm making it public.
Group: security
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

12 years ago
Yes, see bug 305284.
Summary: AJAX pages can load insecure content without user noticing → AJAX pages can load insecure content without user noticing (avoiding mixed content warning)
Assignee: general → nobody
Component: Web Services → DOM
QA Contact: ian → general
Version: 1.7 Branch → unspecified
Duplicate of this bug: 476036
Assigning to me, to track this bug.
Assignee: nobody → honzab.moz

Comment 11

8 years ago
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).
Component: DOM → Security: UI
QA Contact: general → ui

Updated

8 years ago
Whiteboard: [sg:low] → [sg:low][psm-padlock]
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.
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.
Created attachment 561084 [details]
PHP Test case for Sync & Async XHR
Releasing this, but still on my radar.  I would like to get this later back again.
Assignee: honzab.moz → nobody

Updated

6 years ago
Blocks: 782654

Updated

6 years ago
Blocks: 815321

Updated

6 years ago
No longer blocks: 782654
Tanvi, didn't you just fix this with nsMixedContentBlocker?

Comment 17

5 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.