Ensure discovery pane never loads anything insecure or from a different domain

VERIFIED FIXED in mozilla2.0b9

Status

()

defect
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: Unfocused, Assigned: mossop)

Tracking

unspecified
mozilla2.0b9
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [rewrite][sg:want])

Need to ensure discovery pane never loads anything insecure or from a different domain. The discovery page on AMO should generally handle the obvious cases by targetting a new tab (_blank), but we shouldn't rely on this.
Blocks: 558158
No longer blocks: 550048
Assignee

Updated

9 years ago
blocking2.0: --- → final+
Assignee

Updated

9 years ago
Assignee: nobody → bmcbride
Assignee

Updated

9 years ago
Whiteboard: [rewrite] → [rewrite][good first bug]
This doesn't include resources on the page, right? We may need to pull in assets from other domains like mozilla.com or our CDN.
(In reply to comment #1)
> This doesn't include resources on the page, right?

Correct.
Assignee

Updated

9 years ago
Assignee: bmcbride → dtownsend
Depends on: 601143
This bug isn't really specific, but it sounds like you could use CSP for this.  I think our current settings fix this bug: http://github.com/jbalogh/zamboni/blob/master//settings.py#L570

CSP is currently enabled report-only on preview.amo, but is expected to go live sometime in the (near-ish) future.
(In reply to comment #3)
> This bug isn't really specific, but it sounds like you could use CSP for this. 
> I think our current settings fix this bug:
> http://github.com/jbalogh/zamboni/blob/master//settings.py#L570

I don't think CSP applies here though I could be misunderstanding the technology. What we are concerned with is ensuring that the top level page in the content browser here never leaves services.addons.mozilla.org and is always securely delivered.
And we want to show a pretty error message rather than a scary security warning, as wifi login pages and other stuff will likely try to sneak in here.
Note that the client only cares about the top-level document (as far as the domain checking goes, for security everything on the page must be secure), it is up to you guys to ensure you never include anything dangerous from other domains, but I presume that is what CSP will help you with.
(In reply to comment #5)
> And we want to show a pretty error message rather than a scary security
> warning, as wifi login pages and other stuff will likely try to sneak in here.

I actually thought that any page on a different domain would just automatically open in a new tab.
(In reply to comment #7)
> (In reply to comment #5)
> > And we want to show a pretty error message rather than a scary security
> > warning, as wifi login pages and other stuff will likely try to sneak in here.
> 
> I actually thought that any page on a different domain would just automatically
> open in a new tab.

That is a possibility but it feels a little strange that you could click on Get Add-ons and suddenly it opens a new tab with your wifi login page.
(In reply to comment #8)
> That is a possibility but it feels a little strange that you could click on Get
> Add-ons and suddenly it opens a new tab with your wifi login page.

Maybe - though it kinda feels like a normal popup to me. The alternative is either not showing the wifi login page at all (which would be more confusing, IMO), or showing untrusted content in an area that is assumed to always show trusted content (which would be a Bad Thing).
There is some complication with this since some routers just hand back their login page to any url request, as opposed to redirecting to their url. I don't know if this is something that is detectable reliably by firefox...
(In reply to comment #10)
> There is some complication with this since some routers just hand back their
> login page to any url request, as opposed to redirecting to their url. I don't
> know if this is something that is detectable reliably by firefox...

It shouldn't be able to fake the SSL cert though
(In reply to comment #9)
> (In reply to comment #8)
> > That is a possibility but it feels a little strange that you could click on Get
> > Add-ons and suddenly it opens a new tab with your wifi login page.
> 
> Maybe - though it kinda feels like a normal popup to me. The alternative is
> either not showing the wifi login page at all (which would be more confusing,
> IMO), or showing untrusted content in an area that is assumed to always show
> trusted content (which would be a Bad Thing).

Right now there is a bug in catching this case where we still end up loading it (bug 602256), until that is fixed I don't think it makes sense to implement opening the new window for these different sites.
Whiteboard: [rewrite][good first bug] → [rewrite][needs 601143]
Is there a bug somewhere dealing with the fact that Larry (identity-box) isn't very assuring about the integrity of about:addons?  I just get an unencrypted connection popup/page info.  I don't know what the plans are here, since the navigation bar has been left out of every mockup I've seen.
Actually, it looks like the behavior surrounding identity-box with about:addons is sporadic.  Sometimes when it loads, there's a blue glow (but unclickable and "...does not supply..." tooltiptext), and sometimes there isn't.  Sometimes it will start off with the glow, and then it disappears after switching back from other tabs.

Known bug?
(In reply to comment #13)
> Is there a bug somewhere dealing with the fact that Larry (identity-box) isn't
> very assuring about the integrity of about:addons?  I just get an unencrypted
> connection popup/page info.  I don't know what the plans are here, since the
> navigation bar has been left out of every mockup I've seen.

bug 590206
Whiteboard: [rewrite][needs 601143] → [rewrite][needs 601143][sg:want]
(In reply to comment #9)
> (In reply to comment #8)
> > That is a possibility but it feels a little strange that you could click on Get
> > Add-ons and suddenly it opens a new tab with your wifi login page.
> 
> Maybe - though it kinda feels like a normal popup to me. The alternative is
> either not showing the wifi login page at all (which would be more confusing,
> IMO), or showing untrusted content in an area that is assumed to always show
> trusted content (which would be a Bad Thing).

Let's have a standard pane which displays when there's either no or an untrusted internet connection.  Maybe it could be based on cached content from the last time, or even just a simple explanation of what add-ons are.  We don't need to tell people what isn't displaying.
Fixed by bug 601143
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [rewrite][needs 601143][sg:want] → [rewrite][sg:want]
Target Milestone: --- → mozilla2.0b9
Finally was able to verify this fix with the entry page of my hotels WIFI. We do not serve any content which doesn't belong to AMO. Marking as verified fixed based on my tests with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110413 Firefox/5.0a2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.