TweetDeck web shows a blank page

VERIFIED FIXED in Firefox 26

Status

()

Core
Security
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Mathieu Marquer, Assigned: grobinson)

Tracking

({regression})

26 Branch
mozilla27
x86_64
All
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox25 unaffected, firefox26+ verified, firefox27+ verified)

Details

(URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

5 years ago
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

5 years ago
I can't reproduce this in Nightly. Have you tried in safe mode?
Flags: needinfo?(mathieu.marquer)

Comment 2

5 years ago
Note that I'm on Fedora, too.
(Reporter)

Comment 3

5 years ago
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
Flags: needinfo?(mathieu.marquer)
(Reporter)

Comment 4

5 years ago
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

5 years ago
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
Blocks: 836922
Status: UNCONFIRMED → NEW
tracking-firefox26: --- → ?
Component: General → DOM: Core & HTML
Ever confirmed: true

Updated

5 years ago
Keywords: regression
(Assignee)

Comment 6

5 years ago
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?
(Reporter)

Comment 7

5 years ago
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.
(Assignee)

Comment 8

5 years ago
NVM, my Nightly was out of date. Am able to reproduce and regression from Comment 5 appears to be the culprit.
Duplicate of this bug: 916875
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.
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.
(Assignee)

Comment 12

5 years ago
Created attachment 805692 [details] [diff] [review]
Patch 1

Fix the "fail closed" case for pre-1.0 CSP so it honors the reportOnly parameter, w/ Mochitest.
Assignee: nobody → grobinson
Status: NEW → ASSIGNED
Attachment #805692 - Flags: review?(sstamm)
(Assignee)

Comment 13

5 years ago
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 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.
Attachment #805692 - Flags: review?(sstamm) → review+
(Assignee)

Comment 15

5 years ago
Created attachment 806121 [details] [diff] [review]
Patch 2

Addresses Sid's comments, carrying over r+.
Attachment #805692 - Attachment is obsolete: true
Attachment #806121 - Flags: review+
(Assignee)

Updated

5 years ago
Component: DOM: Core & HTML → Security
Keywords: checkin-needed
OS: Windows 7 → All
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.
Keywords: checkin-needed
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
(Assignee)

Comment 19

5 years ago
Created attachment 806993 [details] [diff] [review]
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
Attachment #806121 - Attachment is obsolete: true
Attachment #806993 - Flags: review+
status-firefox25: --- → unaffected
status-firefox26: --- → affected
status-firefox27: --- → affected
tracking-firefox26: ? → +
tracking-firefox27: --- → +
(Assignee)

Comment 20

5 years ago
Created attachment 807398 [details] [diff] [review]
4

Fixes patch commit message per Comment 16. Now that this test is disabled on B2G, the try run looks good.
Attachment #806993 - Attachment is obsolete: true
Attachment #807398 - Flags: review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/960bd6979736
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-firefox27: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla27

Updated

5 years ago
Keywords: verifyme
QA Contact: twalker
Whiteboard: [good first verify]
Works for me now as of today's Nightly.
Status: RESOLVED → VERIFIED
Thanks Ben.
status-firefox27: fixed → verified
QA Contact: twalker
Whiteboard: [good first verify]

Comment 25

5 years ago
I think we should uplift this to aurora. Garrett, can you request approval?
Flags: needinfo?(grobinson)
Keywords: verifyme

Updated

5 years ago
Duplicate of this bug: 920385
(Assignee)

Comment 27

5 years ago
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.
Attachment #807398 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

5 years ago
Flags: needinfo?(grobinson)
Attachment #807398 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 29

5 years ago
Verified fixed on Aurora 26.0a2 buildid 20131001004005.
status-firefox26: fixed → verified
You need to log in before you can comment on or make changes to this bug.