Closed Bug 855399 Opened 7 years ago Closed 7 years ago

[tracking] Mixed active content (usually scripts and iframes) on blog.mozilla.org

Categories

(Websites Graveyard :: blog.mozilla.org, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: briansmith, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: compat, dogfood, sec-low)

+++ This bug was initially created as a clone of Bug #843977 +++

Today I noticed that this new blog post is using mixed content iframes (which won't work in IE) to make an important announcement:
https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/

It is important that such announcements work correctly in IE9 and Chrome, because one of the main purposes of these posts is to promote Firefox to users of other browsers so that they switch.

There are actually many pages on blog.mozilla.org that have this issue. The fix is usually to replace "http" with "https" in the links (e.g. replace <iframe src=http://youtube.com/...> with <iframe src=https://youtube.com/...>.

See my generic explanation of mixed content issues on mozilla.org.

--

This is a tracking bug for pages on blog.mozilla.org that will break when the mixed content blocker is enabled (bug 834836). Note that this bug blocks bug 815321 (the overall tracking bug for the mixed content blocker), but not bug 834836 (the enabling of the mixed content blocker in Firefox). We expect Firefox 22 to ship with the mixed content blocker enabled, so any pages that aren't fixed before Firefox 22 ships will be (partially) broken in Firefox 22. Note that all of these pages are already partially broken in IE9+ unless the user explicitly chooses to allow non-secure content. In some cases, the pages are also already broken in Chrome.

Here is my original notice about this change to Firefox in dev-webdev:
https://groups.google.com/d/msg/mozilla.dev.webdev/ACiyFQC6UGo/XxZoDlz06P8J

Please read the thread for important information and suggestions for identifying and fixing mixed-content issues. I suggest replying to the dev-webdev thread with questions.

Note that we are going to start blocking this kind of content because it (<script src> in particular) is a major security issue for any HTTPS website. In particular, if you load non-HTTPS script, then a MitM can basically "undo" all the protection that SSL gives the page. For example, it is trivial for them to modify the page to steal passwords and non-HttpOnly cookies.
Are there any owners here?  Who is in charge of blog.mozilla.org?
CCing some people who might be able to help here.
The Web Productions team (https://wiki.mozilla.org/Webdev/Web_Production) owns blog.mozilla.org from a technology perspective. We are checking this out now.
We could just simplify the embeds or objects to have src="// instead of hard coding http or https.

This would require the authors of the blogs to do this manually via the source tag in Wordpress.
Turns out that there are a lot of places that wordpress for blog.mozilla.org uses http links by default.  Changing the defaults to https (since blog.mozilla.org is an HSTS site anyway) would solve a lot of the mixed content problems.

For example - 

* When you add media, the <img src> is http by default instead of https.

* When you click on submit to enter a comment on a blog post, the form action is http://blog.mozilla.org/tanvi/wp-comments-post.php instead of https.  This actually causes a problem that predates the Mixed Content Blocker.  Users who try and submit a comment see a warning like this - https://people.mozilla.com/~tvyas/MixedContentPost.png - that they have to accept in order to submit.

* If you click add media, and then insert from url, the default url location starts with http:// instead of https://

The above are what I discovered when writing my own blog post about mixed content (https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/#comment-39), but there may be many other entrypoints where you could change the default to https.  Making these changes can at least help prevent mixed content loads on new blog posts.
Depends on: 703417
Keywords: sec-low
Depends on: 866936
Depends on: 866994
Depends on: 866998
Depends on: 867004
How is this going?  We have a couple months left until Firefox 23 hits stable (August 6th) and I want to make sure we fix all of our mozilla sites by then.
Priority: -- → P2
Its on my todo list will start in earnest in june.
Thanks Ben!
Ben, can you confirm that BID 734514 is a dupe of this one?

If so, I'll close the other bug.
Adam can you cc me on #734514 right now I get access denied.
(In reply to Ben (:bensternthal) from comment #10)
> Adam can you cc me on #734514 right now I get access denied.

Done :)
Ok technically I do not think this is a dupe.

To me this bug (855399) covers blog.mozilla.org not all the blogs under blog.mozilla.org

That other bug is specifically about https://blog.mozilla.com/decoder/ which has issues blog.mozilla.org does not.


I would suggest keeping this separate, putting all the mixed content bugs under blog.mozilla.org will get unwieldy.
Ben, thanks for the clarification, that makes a lot more sense. Does it also mean the individual blogs have not been reviewed?
Depends on: 882737
I just wrote a blog post today about Mixed Content and inserted an image.  When you go through "Insert Media" and try to upload a video file, it has an associated http:// link.  I can't change the link unless I copy it, change the "Link To" option to Custom URL, paste the link in and add the s to https.  Another option is to insert the image and then manually change the source attribute.

Since blog.mozilla.org is using HSTS, it should really be making defaults https:// instead of http://.  Until the defaults change, more and more blogs will be created with Mixed Content.

Ben, have you had a chance to get started on this?

Thanks!  And sorry for pestering you ;)
Tanvi:

I just got my credentials yesterday (see bug #874262) and have not done anything related to this yet.
Depends on: 888068
Depends on: 888069
Hi Ben, just a heads up that the new FF beta has the mixed content blocker. i think there's a good chance that people would ask for the blocker to be turned off if they can't get to the blogs.
I would agree with you that if FF beta prevented folks from getting to the blog, that would be a huge issue.

However, my understanding is that this is not the case.

The issue here is that a few blog posts will have some blocked content, this is limited to only posts containing iframes and similar content (embedding youtube). It does not include images.

I volunteered to help fix this content when I can and I want to get through the highest priority ones today as described in this bug 866998.
Depends on: 888414
I created a blog post that ended up having http images in them (https://blog.mozilla.org/security/2013/07/10/how-to-speed-up-owasp-zap-scans/)
Pretty sure I added the images via the 'Add media' button in Visual mode and then selected images from local filestore.
I didnt realise that they were http ones until Tanvi pointed it out.
To fix that I edited the blog post in Text mode and changed them all manually. I didnt have to upload the images again, so it looks like both http and https links work fine, its just the links that put in by default are wrong.
(In reply to Simon Bennetts [:psiinon] from comment #18)
> I created a blog post that ended up having http images in them
> (https://blog.mozilla.org/security/2013/07/10/how-to-speed-up-owasp-zap-
> scans/)
> Pretty sure I added the images via the 'Add media' button in Visual mode and
> then selected images from local filestore.
> I didnt realise that they were http ones until Tanvi pointed it out.
> To fix that I edited the blog post in Text mode and changed them all
> manually. I didnt have to upload the images again, so it looks like both
> http and https links work fine, its just the links that put in by default
> are wrong.

Ben, I can't remember if we discussed this entry point or not.  Was this something we could change or is it buried somewhere within the wordpress plugin?
Tanvi:

So the image issue is related to Bug 866936#c3.

I updated this setting on the blogs mentioned in the above comment but have not done this on others. Prior to changing all the blogs manually I wanted to hear back on the bug. I will ping again.

I changed this setting on the security site and confirmed it does fix the issue. 

That being said I will go ahead and manually change this on blogs that have had posts in 2013. 

For the main blog I do need devops help as this is something I can not change myself.
Ben, who can we loop in to the discussion to get it underway?
No longer depends on: 866936
Depends on: 899678
Depends on: 866936
All the blockers look to be resolved. If anything else pops up we can re-open.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: Websites → Websites Graveyard
Product: Websites Graveyard → Websites
Product: Websites → Websites Graveyard
You need to log in before you can comment on or make changes to this bug.