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

Status: RESOLVED FIXED

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

Description

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

+++ 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.

Comment 1

[Tanvi Vyas[:tanvi]]

Are there any owners here?  Who is in charge of blog.mozilla.org?

Comment 2

[Christopher Van Wiemeersch [:cvan]]

CCing some people who might be able to help here.

Comment 3

[Chris More [:cmore]]

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.

Comment 4

[Chris More [:cmore]]

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.

Comment 5

[Tanvi Vyas[:tanvi]]

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.

Comment 6

[Tanvi Vyas[:tanvi]]

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.

Comment 7

[Ben (:bensternthal)]

Its on my todo list will start in earnest in june.

Comment 8

[Tanvi Vyas[:tanvi]]

Thanks Ben!

Comment 9

[Adam Muntner [:adamm] (use NEEDINFO)]

Ben, can you confirm that BID 734514 is a dupe of this one?

If so, I'll close the other bug.

Comment 10

[Ben (:bensternthal)]

Adam can you cc me on #734514 right now I get access denied.

Comment 11

[Tanvi Vyas[:tanvi]]

(In reply to Ben (:bensternthal) from comment #10)
> Adam can you cc me on #734514 right now I get access denied.

Done :)

Comment 12

[Ben (:bensternthal)]

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.

Comment 13

[Adam Muntner [:adamm] (use NEEDINFO)]

Ben, thanks for the clarification, that makes a lot more sense. Does it also mean the individual blogs have not been reviewed?

Comment 14

[Tanvi Vyas[:tanvi]]

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 ;)

Comment 15

[Ben (:bensternthal)]

Tanvi:

I just got my credentials yesterday (see bug #874262) and have not done anything related to this yet.

Comment 16

[Adam Muntner [:adamm] (use NEEDINFO)]

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.

Comment 17

[Ben (:bensternthal)]

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.

Comment 18

[Simon Bennetts [:psiinon]]

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.

Comment 19

[Tanvi Vyas[:tanvi]]

(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?

Comment 20

[Ben (:bensternthal)]

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.

Comment 21

[Adam Muntner [:adamm] (use NEEDINFO)]

Ben, who can we loop in to the discussion to get it underway?

Comment 22

[Ben (:bensternthal)]

All the blockers look to be resolved. If anything else pops up we can re-open.