1591807 - Network tab shows CSP-blocked errors for pre-load requests which confuses people

mail

Reporter

Description

•

5 years ago

Attached image screenshot.png (deleted) — Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Run HTTP server (nginx used in this example) statically hosting two following files:

File index.html:

<!DOCTYPE html>
<html>
  <head>
  <title>Welcome to nginx!</title>
  <meta charset="utf-8">
  <script nonce="dGVzdA==" src="/main.js"></script>
</head>
<body>
  <h1>Welcome to nginx!</h1>
</body>
</html>

File main.js:

console.log('Main JS was executed');

Web server is configured to add the following header:

Content-Security-Policy "script-src 'nonce-dGVzdA==';"

Navigate to the web server address (127.0.0.1:8080 in my case) while observing Firefox dev tools network tab and console.

Note: the test was done in the safe mode with no extensions enabled.

Actual results:

Request to the main.js file appears twice: the first request is Blocked with the CSP value in the Transferred column. The second request is fine (200). The script is executed normally as expected (according to the console output).

Please see attached screenshot for more information.

Expected results:

Only one HTTP request to the main.js should exist. CSP is not violated here (even though nonce is hardcoded and doesn't change), so I see no reason for the first blocked request.

YF (Yang)

Updated

•

5 years ago

Component: Untriaged → DOM: Security

Product: Firefox → Core

Christoph Kerschbaumer [:ckerschb]

Comment 1

•

5 years ago

Moving this over to Devtools. The problem is that at the time we fire a preload the 'nonce' is not available yet, so the preload gets blocked and reported to the console, but the actual load then succeeds (once the nonce is available). In the regular case we are excluding preloads from being reported to the console, but it seems we are not doing that for the network tab.

I am pushing this over to devtools but happy to provide guidance if someone can show me where the code lives. If you have a a channel and a loadinfo, you could basically check the content type and see if it's a SCRIPT_PRELOAD or a STYLE_PRELOAD, those are the only two cases which can be greenlighted by a nonce in CSP.

Component: DOM: Security → Netmonitor

Product: Core → DevTools

BugBot [:suhaib / :marco/ :calixte]

Comment 2

•

5 years ago

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(odvarko)

Jan Honza Odvarko [:Honza] (always need-info? me)

Comment 3

•

5 years ago

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)

I am pushing this over to devtools but happy to provide guidance if someone can show me where the code lives. If you have a a channel and a loadinfo, you could basically check the content type and see if it's a SCRIPT_PRELOAD or a STYLE_PRELOAD, those are the only two cases which can be greenlighted by a nonce in CSP.

Thanks for the analysis Christoph!

Alex, what could be good place to exclude a request from reporting it to the Network panel?

Do you think that we could filter it out in matchRequest?

https://searchfox.org/mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f/devtools/server/actors/network-monitor/network-observer.js#62

Honza

Flags: needinfo?(odvarko) → needinfo?(poirot.alex)

Alexandre Poirot [:ochameau]

Comment 4

•

5 years ago

matchRequest typicaly validates if the request belongs to the currently inspected target/document.

I'm wondering if we could filter it from here instead:
https://searchfox.org/mozilla-central/source/devtools/server/actors/network-monitor/network-observer.js#556-569
Otherwise, it sounds ok to also filter out unexpected request types from matchRequest, but be careful that it is called extensively and it should be kept efficient.
I would just suggest updating its code comment.

Flags: needinfo?(poirot.alex)

Jan Honza Odvarko [:Honza] (always need-info? me)

Comment 5

•

5 years ago

Thanks for the response Alex!

(In reply to Alexandre Poirot [:ochameau] from comment #4)

matchRequest typicaly validates if the request belongs to the currently inspected target/document.

I'm wondering if we could filter it from here instead:
https://searchfox.org/mozilla-central/source/devtools/server/actors/network-monitor/network-observer.js#556-569

Do it only in observeActivity wouldn't be enough. We'd need to do the same check in _httpResponseExaminer (and perhaps at other places?)
Basically duping matchRequest calls.

Otherwise, it sounds ok to also filter out unexpected request types from matchRequest, but be careful that it is called extensively and it should be kept efficient.
I would just suggest updating its code comment.

Yep, agreed.

Honza

Jan Honza Odvarko [:Honza] (always need-info? me)

Comment 6

•

5 years ago

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)

I am pushing this over to devtools but happy to provide guidance if someone can show me where the code lives. If you have a a channel and a loadinfo, you could basically check the content type and see if it's a SCRIPT_PRELOAD or a STYLE_PRELOAD, those are the only two cases which can be greenlighted by a nonce in CSP.

So, we should do the check in at this line:
https://searchfox.org/mozilla-central/rev/cac340f10816707e91c46db6d285f80259420f07/devtools/server/actors/network-monitor/network-observer.js#82

Can you please post more info about how to implement the check?
Thanks!
Honza

Status: UNCONFIRMED → NEW

Ever confirmed: true

Flags: needinfo?(ckerschb)

Priority: -- → P3

Christoph Kerschbaumer [:ckerschb]

Comment 7

•

5 years ago

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #6)

Can you please post more info about how to implement the check?

Initially I thought we can simply do

let type = channel.loadinfo.internalContentPolicyType;
if (type == Ci.nsIContentPolicy.TYPE_INTERNAL_SCRIPT_PRELOAD || type == Ci.nsIContentPolicy.TYPE_INTERNAL_STYLESHEET_PRELOAD) {
// do something

But then I realized that internalContentPolicyType is not exposed to script [1]. Any chance we could move the check into C++ code? Alternatively, can we expose a helper function, e.g. IsPreloadType(channel.loadinfo) or something there like so we evaluate whether it's a preload type in C++?

[1] https://searchfox.org/mozilla-central/rev/cac340f10816707e91c46db6d285f80259420f07/netwerk/base/nsILoadInfo.idl#572

Flags: needinfo?(ckerschb)

Jan Honza Odvarko [:Honza] (always need-info? me)

Comment 8

•

5 years ago

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #7)

But then I realized that internalContentPolicyType is not exposed to script [1]. Any chance we could move the check into C++ code? Alternatively, can we expose a helper function, e.g. IsPreloadType(channel.loadinfo) or something there like so we evaluate whether it's a preload type in C++?

[1] https://searchfox.org/mozilla-central/rev/cac340f10816707e91c46db6d285f80259420f07/netwerk/base/nsILoadInfo.idl#572

There is a comment: This should not be used for the purposes of security checks, since the content policy implementations cannot be expected to deal with _INTERNAL_ values. Please use the contentPolicyType attribute above for that purpose.

Could we use contentPolicyType?

Honza

Flags: needinfo?(ckerschb)

Jan Honza Odvarko [:Honza] (always need-info? me)

Updated

•

5 years ago

Blocks: devtools-resource-blocking

Christoph Kerschbaumer [:ckerschb]

Comment 10

•

5 years ago

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #8)

[1] https://searchfox.org/mozilla-central/rev/cac340f10816707e91c46db6d285f80259420f07/netwerk/base/nsILoadInfo.idl#572

There is a comment: This should not be used for the purposes of security checks, since the content policy implementations cannot be expected to deal with _INTERNAL_ values. Please use the contentPolicyType attribute above for that purpose.

Could we use contentPolicyType?

Sorry for the lag here, but for this specific check it's fine to use contentPolicyType.

Flags: needinfo?(ckerschb)

:Harald Kirschner :digitarald

Comment 11

•

5 years ago

Should we really hide this request? We also show failed favicon requests and with bug 1624368 we want to mark preload requests. Would the last issue make this easier to understand for developers (if so, we can dupe this issue against it)?

:Harald Kirschner :digitarald

Updated

•

5 years ago

Blocks: 1484005
No longer blocks: devtools-resource-blocking

BMO Automation

Updated

•

2 years ago

Severity: normal → S3

Comment hidden (offtopic)

It causes a huge loading time for another my page where I have a spreadsheet with around 15000 cells. And it calls a JS for cell calculation, displaying, etc.
All JS are set with the nonce. See sample from
The CSP noce setup for scripts and can see it's working. See snippet from
view-source:http://127.0.0.1:8000/:

28    <script nonce="9WO5+pSMYOZgAjK3R5x0nw==" src="/static/js/jquery-3.6.1.js"></script>
29 </head>
30 <body> 
31    
32    <style>
33        .nice-select.dropup-container ul.list.dropup {
34            top: auto;
35            bottom: 100%;
36            margin-bottom: 4px;
37        }

So I'm receiving so many errors to the cosole that Firefox is not responding around 3-5 min.
The console errors aren't showing which line caused it as it's usually presented in case CSP really did block script due to a policy set.
Interesting to notice that the number of errors repeats is not constant for the same page. Every time refresshing the page it will show in range 10000-40000 error repeats.

Comment hidden (offtopic)

I've debugged it and found 2 problems.

Any inline handler (i.e. onclick, onblur etc) will cause CSP error report about blocked inline script without providing a line number. Therefore it's unclear at the first place what caused the error.

In case there are many of inline handler the Firefox getting overloaded when it parses these inline handlers. This is seems to be general search/parsing issue. Because it's possible to reproduce when Firefox is not responding even when you just search the debug console a string which is repeated multiple times i.e. 32216 in my attached example
Below is the snippet of the repeatable cells of the spreadsheet code with guilty inline handlers.

                             value=""
                             data-verc="project_12_verc_total" data-user="3255438" data-type="project" data-idd="12" data-timesheet='1531'/>                            
                     </td>               
                     <td>
                         <input name="3255438_1531_total" id="3255438_1531_11_project_1" 
                             class="input-box project_11_verc_total project-box" type="number" readonly="true" onblur="this.readOnly='true';"                              
                                 draggable="true" ondrop="this.readOnly='';drop(event);" ondragstart="drag(event)" ondragover="allowDrop(event)"
                             value=""
                             data-verc="project_11_verc_total" data-user="3255438" data-type="project" data-idd="11" data-timesheet='1531'/>                            
                     </td>
                     <td>
                         <input name="3255438_1531_total" id="3255438_1531_20_project_1" 
                             class="input-box project_20_verc_total project-box" type="number" readonly="true" onblur="this.readOnly='true';"                               
                                 draggable="true" ondrop="this.readOnly='';drop(event);" 
                             value=""
                             data-verc="project_20_verc_total" data-user="3255438" data-type="project" data-idd="20" data-timesheet='1531'/>                            
                     </td>

Comment hidden (offtopic)

Tom Schuster (MoCo)

Updated

•

2 years ago

Blocks: csp-console-logging

Daniel Veditz [:dveditz]

Comment 16

•

2 years ago

Comment 12 through 15 look like something else. The reporter filed bug 1796728

Summary: Unexpected blocked requests to scripts when CSP for script-src is nonce → Network tab shows CSP-blocked errors for pre-load requests which confuses people

screenshot.png 5 years ago mail (deleted), image/png		Details
csp-nonce-firefox.gif 2 years ago Alexander Konrad (deleted), image/gif		Details
CSP-blocked.jpg 2 years ago Alexander Konrad (deleted), image/jpeg		Details
lag_search.mp4 2 years ago Alexander Konrad (deleted), video/mp4		Details