Closed Bug 308496 Opened 16 years ago Closed 8 years ago

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

Categories

(Core Graveyard :: Security: UI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hrabbach, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: sec-low, Whiteboard: [sg:low][psm-padlock])

Attachments

(1 file)

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: lockicon
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?
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?
Could you please provide a testcase?
Whiteboard: [sg:fix] → [sg:low]
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?
Yes, see bug 305284.
Depends on: 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
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
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.
Releasing this, but still on my radar.  I would like to get this later back again.
Assignee: honzab.moz → nobody
Blocks: 782654
No longer blocks: 782654
Tanvi, didn't you just fix this with nsMixedContentBlocker?
(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
Closed: 8 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.