Closed Bug 1298680 Opened 8 years ago Closed 8 years ago

No errors in developer error console when CSP prevents loading of resources

Categories

(DevTools :: Console, defect, P3)

50 Branch
defect

Tracking

(firefox52 fixed)

RESOLVED FIXED
Firefox 52
Tracking Status
firefox52 --- fixed

People

(Reporter: jonasthiem, Assigned: ckerschb)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160827004001

Steps to reproduce:

1. Write an invalid CSP containing https://self:443 and serve it using HTTP headers
2. Visit the site using HTTPS
3. No scripts will load, but no errors on dev console


Actual results:

no errors on dev console


Expected results:

errors on dev console
This is just one of many instances where Firefox absolutely fails to produce appropriate error messages reliably when something went wrong. For example, when linked resources fail to load due to SHA1 enforcement level but the site itself loaded fine as seen in #1297467 you can get entirely unrelated(!) error messages about some supposed header parsing problem, or no error messages at all (while half of the page design, scripts, ... are missing).

If you don't want developers to jump to Chrome all the time for basic error investigation, you should really revamp the error handling and make it more reliable..
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

I have tested your issue on latest Firefox release (v48.0) and latest Nightly (Build ID: 20160831030224) and could reproduce it. I have accessed mail.example.com:443, https://mail.example.com:443, https://self.example.com and in the Web Console and Browser Console there were no errors displayed. I have tried the same scenario with Google Chrome and in the console there were errors displayed.
Status: UNCONFIRMED → NEW
Component: Untriaged → Developer Tools: Console
Ever confirmed: true
(In reply to Vlad Bacia [:VladB] from comment #2)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101
> Firefox/51.0
> 
> I have tested your issue on latest Firefox release (v48.0) and latest
> Nightly (Build ID: 20160831030224) and could reproduce it. I have accessed
> mail.example.com:443, https://mail.example.com:443, https://self.example.com
> and in the Web Console and Browser Console there were no errors displayed. I
> have tried the same scenario with Google Chrome and in the console there
> were errors displayed.

Loading those pages I get 'Server Not Found' errors.  Is there another URL I can use to test this?
Flags: needinfo?(vlad.bacia)
This issue can be 100% reproduced everywhere with the help of Docker.

1. Install docker, install docker-compose

2. Make a new directory /somewhere/firefox-test/

3. Put this into /somewhere/firefox-test/Dockerfile:

FROM ubuntu:16.04

# Install nginx:
RUN apt-get update --fix-missing
RUN apt-get install -y nginx

# Add a test site which is supposed to give a "Hello!" popup when visiting:
RUN echo "<!DOCTYPE HTML><html><head><title>Firefox test</title><script src='myscript.js'></script></head><body>Test site.</body></html>" >> /var/www/html/index.html
RUN echo "alert('Hello!');" >> /var/www/html/myscript.js

# Add an invalid http://self; CSP header:
RUN sed -i 's/location \/ {/location \/ {\nadd_header "Content-Security-Policy" "script-src http:\/\/self;" always;/g' /etc/nginx/sites-enabled/default

CMD nginx -g "daemon off;"


4. Put this into /somewhere/firefox-test/docker-compose.yml:

main:
  build: .
  ports:
  - "8000:80"

5. Open a terminal and make sure the docker daemon runs with:
   sudo service docker start

5. Open a terminal, and cd to /somewhere/firefox-test/docker-compose.yml and run this to launch the container:
   sudo docker-compose up -d

6. Now browse to http://localhost:8000

Expected behavior: developer console shows an error, OR site works correctly and "Hello!" messagebox is displayed

Actual behavior: developer console doesn't show ANYTHING, but the script is simply silently ignored and doesn't run either due to the faulty header.
Just as a small heads up: the resulting running nginx instance is world-reachable (although it is also trapped in a container so it can't really do much).

To turn it off and remove the container again, run this command in the /somewhere/firefox-test/ directory:
sudo docker-compose down
Based on comment 4.
Flags: needinfo?(vlad.bacia)
Hi Cristoph, there's a test case in Comment 4 in which CSP errors are not showing up in the console. Could someone help trace this down from the platform end to help figure out why the error isn't being reported?
Flags: needinfo?(ckerschb)
Priority: -- → P3
(In reply to Brian Grinstead [:bgrins] from comment #7)
> Hi Cristoph, there's a test case in Comment 4 in which CSP errors are not
> showing up in the console. Could someone help trace this down from the
> platform end to help figure out why the error isn't being reported?

Browsing through this bug I have to mention that both policies [script-src https://self:443] as well as [script-src  http://self] are valid according to the spec [1] which uses the following ABNF [2]. More precisely the spec mentions:
> host-part   = "*" / [ "*." ] 1*host-char *( "." 1*host-char )
where the '*' after the first appearing host-char means that there might be 0 or more occurences of "." after the first host-char. That means that 'http://self' represents a valid CSP. We even have a test for that [3].

As of now I haven't invested the time to precisely follow the steps of comment 4, but given comment 0 that would explain why no script is executed.

Is it possible that you are running a multi process Firefox version and the error does not show up in the dev console but is logged to the more general 'browser console'?

Can someone please check and let me know? I doubt that we are not displaying any kind of error. If that is true, we should fix that immediately.

[1] https://www.w3.org/TR/CSP3/#framework-directive-source-list
[2] https://tools.ietf.org/html/rfc5234#section-3.6
[3] https://dxr.mozilla.org/mozilla-central/source/dom/security/test/TestCSPParser.cpp#692
Flags: needinfo?(ckerschb)
The issue seems super sporadic:

I just re-tested with an update available. Two very verbose CSP errors show up, one of them being a generic one about the policy explaining that http://self doesn't really work and 'self' should probably be used, and another one specifically for the script saying the file wasn't loaded.

However, now I updated the browser and tested again with the tab auto-reloaded after the browser restart for update: no errors, absolutely no trace on the console that something wrong. (Even when pressing CTRL+SHIFT+R)

Thherefore I suspect it's kind of unpredictable to reproduce.
(In reply to Jonas Thiem from comment #9)
> The issue seems super sporadic:
> 
> I just re-tested with an update available. Two very verbose CSP errors show
> up, one of them being a generic one about the policy explaining that
> http://self doesn't really work and 'self' should probably be used, and
> another one specifically for the script saying the file wasn't loaded.
> 
> However, now I updated the browser and tested again with the tab
> auto-reloaded after the browser restart for update: no errors, absolutely no
> trace on the console that something wrong. (Even when pressing CTRL+SHIFT+R)
> 
> Thherefore I suspect it's kind of unpredictable to reproduce.

I suppose you tested using the STR from comment 4, right? If we would have a smaller testcase, that would be awesome. Really curious why that bug would only appear intermittently.
I found a reliable way to reproduce this:

1. Set up the docker container as above (or a similar web server with the faulty header "Content-Security-Policy" "script-src http://self;") with the minimal test website above

2. Start firefox dev edition (haven't tested stable) with firefox -P -safe-mode

3. In the profile choice dialog, create a new profile, choose it in the selection and click start.

4. In the dialog offering to refresh, click "Use Safe Mode" (no refrehsh).

5. Visit the page, for the docker container the URL is http://localhost:8000

6. Open the developer console with right-click > Inspect and click "Console". You will see the proper errors. Keep the website tab open and don't touch anything else and leave the website tab active.

7. Click the menu button, Click the "?" button at the bottom, Click "Restart with Addons Enabled"

8. Now reopen with right-click > Inspect and go back to the "Console" tab. You will see there are now absolutely no trace of the proper errors, and apart from an unrelated encoding warning absolutely no indication that something went wrong.
slightly improved STR for our QA
1) Visit <https://web.security.plumbing/tests/bug-1298680/
2) Open dev tools console, you should see two messages
2a) A warning about interpreting http://self as URL and not they keyword
2b) A warning that the script empty-console.js was blocked

What happens in fact is as ckerschb guessed: The messages are shown in the browser console, but not in the devtools console.

I'll turn this into a mochitest for our testsuite next week.
Assignee: nobody → fbraun
I can confirm. If you follow my extensive instructions, it will indeed show up on the browser console properly, just not on the dev console.

However, the shortened instructions in Comment 12 don't reproduce it for me. Therefore, if you have trouble, try instructions in Comment 11 on the given test URL in comment 12.
Stealing this one from freddyb.
Assignee: fbraun → ckerschb
Status: NEW → ASSIGNED
Whiteboard: [domsecurity-backlog1]
Blocks: csp-w3c-3
The windowID is a uint64_t and not a uint32_t [1] - rrrh. That also explains that the problem appeared intermittently. If the window ID was able to fit in a uint32_t -> all good, otherwise that check [2] failed and we logged to the browser console instead of the web console.

@Jonas: Thanks for filing the bug.

@Freddy: Can we land that patch right away? Merge is in a few hours, we can file a follow up for a test. Thanks!

[1] https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPContext.h#108
[2] https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPUtils.cpp#148
Attachment #8792465 - Flags: review?(fbraun)
Comment on attachment 8792465 [details] [diff] [review]
bug_1298680_do_not_overflow_uint32.patch

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

Well spotted. r+
Attachment #8792465 - Flags: review?(fbraun) → review+
Blocks: 1303712
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/75ac3067a19e
Use uint64_t consistently for windowID within CSP. r=freddyb
https://hg.mozilla.org/mozilla-central/rev/75ac3067a19e
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
I have successfully reproduce this bug on firefox nightly 51.0a1 (2016-08-28)
with windows 7 (32 bit)
Mozilla/5.0 (Windows NT 6.1; rv:51.0) Gecko/20100101 Firefox/51.0

I found this fix on latest nightly 52.0a1 (2016-10-16) (32-bit)

Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID : 20161016030205
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: