916446 - TweetDeck web shows a blank page

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Mathieu Marquer]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20130913030201

Steps to reproduce:

Go to web.tweetdeck.com


Actual results:

Blank page, page title and source code seem to load correctly (show source shows actual code)


Expected results:

TweetDeck web interface should load

Comment 1

[Josh Matthews [:jdm]]

I can't reproduce this in Nightly. Have you tried in safe mode?

Comment 2

[Josh Matthews [:jdm]]

Note that I'm on Fedora, too.

Comment 3

[Mathieu Marquer]

Yup, tried in Nightly safe mode as well, same result. Error console shows this:

19:02:06.356 The X-Content-Security-Policy and X-Content-Security-Report-Only headers will be deprecated in the future. Please use the Content-Security-Policy and Content-Security-Report-Only headers with CSP spec compliant syntax instead. web.tweetdeck.com
19:02:06.428 All candidate resources failed to load. Media load paused. web.tweetdeck.com

Comment 4

[Mathieu Marquer]

This was web console. Browser console says a bit more:

19:05:41.110 GET https://web.tweetdeck.com/ [HTTP/1.1 200 OK 523ms]
19:05:41.453 POST http://ocsp.digicert.com/ [HTTP/1.1 200 OK 18ms]
19:05:41.587 Content Security Policy: 'allow' or 'default-src' directive required but not present.  Reverting to "default-src 'none'"
19:05:41.591 The X-Content-Security-Policy and X-Content-Security-Report-Only headers will be deprecated in the future. Please use the Content-Security-Policy and Content-Security-Report-Only headers with CSP spec compliant syntax instead. web.tweetdeck.com
19:05:41.627 All candidate resources failed to load. Media load paused. web.tweetdeck.com
19:05:41.641 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/css/font.f776e02ee4.css ("default-src 'none'").
19:05:41.642 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/css/app-dark.6e2c495dde.css ("default-src 'none'").
19:05:41.642 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/css/app-light.1a168e6dfe.css ("default-src 'none'").
19:05:41.642 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/assets/global/backgrounds/spinner_large_grey_light.9bce719a36.gif ("default-src 'none'").
19:05:41.642 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/mustaches/mustaches.eb1a809065.js ("default-src 'none'").
19:05:41.642 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/scripts/default.4474e1a45e.js ("default-src 'none'").
19:05:41.642 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/scripts/lib/bower_components/requirejs/require.0206ab16c6.js ("default-src 'none'").
19:05:41.649 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/assets/sounds/tweet.de96e2b3d6.mp3 ("default-src 'none'").
19:05:41.650 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/assets/sounds/tweet.9663ad9dcb.ogg ("default-src 'none'").
19:05:41.652 Content Security Policy: The page's settings blocked the loading of a resource at https://web.tweetdeck.com/web/assets/logos/favicon.f5202c658f.ico ("default-src 'none'").
19:05:41.696 GET https://web.tweetdeck.com/favicon.ico [HTTP/1.1 200 OK 161ms]

Comment 5

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b86d7ce8d1eb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130912091339
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/1a475fdee12b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130912092736
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b86d7ce8d1eb&tochange=1a475fdee12b

Regressed by bug 836922

Comment 6

[Garrett Robinson [:grobinson]]

I can't reproduce the "nothing loads" behavior on Nightly 26.0a1 (2013-09-11) (Ubuntu 13). I see the TweetDeck logo on a gray background, a form asking me to "Sign in with your TweetDeck account", and an adjacent div headed "Don't have a Tweetdeck account?" Are you already logged in to TweetDeck?

AFAICT tweetdeck is only serving "report-only" CSP headers, so no content should actually be blocked. Note that they are using the deprecated "x-content-security-policy-report-only" header, which, as the warning states, should be transitioned to the CSP 1.0 header. Additionally, as the other warning says, they are not using the pre-spec-compliant header correctly.

Do you see the same behavior in Chrome?

Comment 7

[Mathieu Marquer]

Loads fine with Chrome Stable (29.0.1547.66). Note that I don't currently have a Linux computer to try with the Linux version, all tests are done with Windows 7 and latest Firefox nightly (currently 2013-09-15), could this bug be Windows-only? (Josh also couldn't reproduce it with Fedora)

Since the bug also occurs with Firefox safe mode and as I removed site-related cookies, I don't think I'm still logged on Tweetdeck.

Comment 8

[Garrett Robinson [:grobinson]]

NVM, my Nightly was out of date. Am able to reproduce and regression from Comment 5 appears to be the culprit.

Comment 10

[Sid Stamm [:geekboy or :sstamm]]

Based on the comment in bug 916875, the site is using an invalid csp in an x-content-security-policy-report-only header.  I think probably this is a tech evangelism bug, but also we're possibly blocking even though it's a report-only policy.

Comment 11

[Sid Stamm [:geekboy or :sstamm]]

Yep:
http://mxr.mozilla.org/mozilla-central/source/content/base/src/CSPUtils.jsm#483


481   if (!aCSPR._directives[SD.DEFAULT_SRC]) {
482     cspWarn(aCSPR, CSPLocalizer.getStr("allowOrDefaultSrcRequired"));
483     return CSPRep.fromString("default-src 'none'", selfUri);
484   }

Needs to create the "default-src 'none'" policy *and* set reportOnly if the argument value says it's a report-only policy.

Comment 12

[Garrett Robinson [:grobinson]]

Attachment: Patch 1

Fix the "fail closed" case for pre-1.0 CSP so it honors the reportOnly parameter, w/ Mochitest.

Comment 13

[Garrett Robinson [:grobinson]]

I have reported this issue to the Twitter (they run TweetDeck) Security Team via their Security Issues Report page (https://support.twitter.com/forms/security).

Comment 14

[Sid Stamm [:geekboy or :sstamm]]

Comment on attachment 805692 [details] [diff] [review]
Patch 1

Review of attachment 805692 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with these changes (and your manual verification that the tests fail without the changes to CSPUtils.jsm, and pass with them).

::: content/base/src/CSPUtils.jsm
@@ +482,5 @@
>    // directive to be present.
>    if (!aCSPR._directives[SD.DEFAULT_SRC]) {
>      cspWarn(aCSPR, CSPLocalizer.getStr("allowOrDefaultSrcRequired"));
> +    return CSPRep.fromString("default-src 'none'", selfUri, null, null,
> +                             reportOnly);

Instead of nulls, please forward the docRequest, and csp arguments to this function.

::: content/base/test/csp/test_CSP_bug916446.html
@@ +12,5 @@
> +
> +var inlineScriptAllowed;
> +var inlineScriptViolationReported;
> +var externalLoadAllowed;
> +var externalLoadViolationReported;

Please put these in some clear scope somewhere (like as fields inside examiner) so they're clearly located and clearly the same variable instance inside the examiner and inside the other functions.  Otherwise we could accidentally bind the examiner's callbacks to the wrong scope when they're notified.   When you check the values later you can ask for window.examiner.inlineScriptAllowed to make the scope explicit, or let examiner do all the checking.

@@ +111,5 @@
> +  function() {
> +    // test that an invalid report-only policy (a stripped down version of
> +    // what web.tweetdeck.com was serving) defaults to "default-src // 'none'"
> +    // but only sends reports and is not accidentally enforced // test inline
> +    // script, test a few types of external loads

This comment is a little awkward (text wrap fail?)  Please also put it at the top of the file so it's easy to find.

Comment 15

[Garrett Robinson [:grobinson]]

Attachment: Patch 2

Addresses Sid's comments, carrying over r+.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d63424e06b3e

Friendly reminder that the patch commit message should be summarizing what the patch is actually doing, not restating the bug title.

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/b2aabb7f482d for failing on b2g:
https://tbpl.mozilla.org/php/getParsedLog.php?id=27997566&tree=Mozilla-Inbound

Comment 18

[Sid Stamm [:geekboy or :sstamm]]

grobinson: I forgot that this uses the observer service, so the tests need to be disabled in b2g until we fix that.  See http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/b2g.json#202

Comment 19

[Garrett Robinson [:grobinson]]

Attachment: 3

Disable test on B2G due to the lack of a functioning observer service. Carrying over r+ from sstamm.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=0b4e8fe03e46

Comment 20

[Garrett Robinson [:grobinson]]

Attachment: 4

Fixes patch commit message per Comment 16. Now that this test is disabled on B2G, the try run looks good.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/960bd6979736

Comment 22

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/960bd6979736

Comment 23

[[e-mail] (:bhearsum)]

Works for me now as of today's Nightly.

Comment 24

[Tracy Walker [:tracy]]

Thanks Ben.

Comment 25

[Ekanan Ketunuti]

I think we should uplift this to aurora. Garrett, can you request approval?

Comment 27

[Garrett Robinson [:grobinson]]

Comment on attachment 807398 [details] [diff] [review]
4

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 836922
User impact if declined: Sites that serve invalid, pre-1.0 CSP headers will completely "fail closed" - that is, every resource load will be blocked. An example site is web.tweetdeck.com.
Testing completed (on m-c, etc.): Green try run on m-c
Risk to taking this patch (and alternatives if risky): Risk is low; only affects CSP. 
String or IDL/UUID changes made by this patch: None.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/500b46d8c38a

Comment 29

[Ekanan Ketunuti]

Verified fixed on Aurora 26.0a2 buildid 20131001004005.