1582115 - Unable to display PDF due CSP

Status: VERIFIED FIXED

(Core :: DOM: Security, defect, P1)

Description

[seun landsberg]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Steps to reproduce:

Click on a link to display a PDF in i iFrame in a new window.

Actual results:

The PDF.js black windows remains blank.
We have the following messages :
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à resource://pdf.js/web/viewer.js, (« script-src »).Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à resource://pdf.js/build/pdf.js, (« script-src »).

CSP in configured in .htaccess file as followed :
Header always set Content-Security-Policy "script-src 'self';"

Expected results:

the pdf.js files should be allowed to be loaded

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Liviu Seplecan]

Attachment: tstpdf.html

Comment 3

[Liviu Seplecan]

Hi @seun landsberg, can you please provide the PDF doc or some extra details of how you can load the document. I guess that your doc contains a script.
Also, do you try this using localhost or normally?
I my end I've tried to load the file (you've found in the attachments) then the PDF will be loaded in a new tab.
Regards,
Liviu

Comment 4

[Daniel Veditz [:dveditz]]

Liviu: the reported problem is the PDF is served with a Content-Security-Policy: header (from a web server, not local). The remote PDF loaded by your testcase does not have one.

Comment 5

[Liviu Seplecan]

Hi, tks @ Daniel Veditz, in that case I need from the reporter the link - in order to test if the issue can be reproduced.
Regards,
Liviu

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 7

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #6)

For more information, please visit auto_nag documentation.

Dan, as discussed in the triage meeting, could you please take a look?

Comment 8

[Kamil Chlebek]

Hello,

here's simple reproduction of the issue: https://suspicious-nightingale-19ff29.netlify.com/

Steps:

1. Click Open PDF button

Expected:
PDF visible in the viewer

Actual:
Error in the console. PDF is not being displayed.

Loading failed for the <script> with source “resource://pdf.js/build/pdf.js”. 
Loading failed for the <script> with source “resource://pdf.js/web/viewer.js”. 
Content Security Policy: The page's settings blocked the loading of a resource at resource://pdf.js/build/pdf.js ("script-src").
Content Security Policy: The page's settings blocked the loading of a resource at resource://pdf.js/web/viewer.js ("script-src").

Other browsers correctly open the PDF regardless the CSP header.

Comment 9

[yanal_yves_fargialla]

Hello,

I am experiencing the same issue as described by Kamil Chlebek. To work arround issue in my web app I have configure the CSP :

• base-uri: add resource://pdf.js/web/
• script-src: add resource://pdf.js/

Comment 10

[tekai]

Hi,

although op reported this for Chrome the issue is still present in the latest beta (Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0). The "workaround" from @yanal_yves_fargialla works (script-src: add resource://pdf.js was enough for me). Chrome seems to have fixed this.

Comment 11

[Darkspirit]

Seen on Twitter today: https://twitter.com/k4ii_/status/1258657381157867520
Confirmed with STR from comment 8.

mozregression --good 2019-03-01 --bad 2019-06-01 --pref security.sandbox.content.level:0 -a https://suspicious-nightingale-19ff29.netlify.app/

6:59.16 INFO: Last good revision: 6c2047bc2f3e9e2e165d0c03177ae4212a912077
6:59.16 INFO: First bad revision: c5554e93087a727b56a05ac67f20b7ccba47c3c5
6:59.16 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6c2047bc2f3e9e2e165d0c03177ae4212a912077&tochange=c5554e93087a727b56a05ac67f20b7ccba47c3c5

c5554e93087a727b56a05ac67f20b7ccba47c3c5 Christoph Kerschbaumer — Bug 965637: Move CSP from Principal into Client, part 4: test updates. r=mccr8,jkt
63587b402c35ba828007cf7b8b4c9a23fcf97e85 Christoph Kerschbaumer — Bug 965637: Move CSP from Principal into Client, part 3: frontend changes. r=Gijs
3399e7c519424a82824f48abd3b2a4d75346d723 Christoph Kerschbaumer — Bug 965637: Move CSP from Principal into Client, part 2: worker changes. r=baku
ddf4012a7652e36d144fc43bc99335276deeafbe Christoph Kerschbaumer — Bug 965637: Move CSP from Principal into Client, part 1: backend changes. r=mccr8

Comment 12

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #11)

Seen on Twitter today: https://twitter.com/k4ii_/status/1258657381157867520
Confirmed with STR from comment 8.

I am on it.

Comment 13

[Christoph Kerschbaumer [:ckerschb]]

Attachment: Bug 1582115: Exempt pdf.js from being subject to CSP from page. r=gijs

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/24b704620e67
Exempt pdf.js from being subject to CSP from page. r=Gijs

Comment 16

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/24b704620e67

Comment 17

[Christoph Kerschbaumer [:ckerschb]]

Hey Ryan, I know the issue reported in this bug has been a problem for long time. Apparently it got more prevalent recently (see comment 11 or also duplicate Bug 1636639). I personally think it's worth uplifting given that it's an easy fix and we also have an automated test for it. Wanted to check for you opinion if that's something we would consider worth uplifting?

Comment 18

[Pascal Chevrel:pascalc (PTO until April 26)]

Christoph, I think that you are correct and we should uplift it, can you file the uplift request so as that we get it in Friday's beta? Thanks

Comment 19

[Tom S [:evilpie]]

https://suspicious-nightingale-19ff29.netlify.app/ still doesn't work for me. The tab immediately closes. I however don't see the previous CSP error anymore.

Comment 20

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Tom Schuster [:evilpie] from comment #19)

https://suspicious-nightingale-19ff29.netlify.app/ still doesn't work for me. The tab immediately closes. I however don't see the previous CSP error anymore.

You sure Tom? Are you using the latest from mozilla-central or Nightly? Works for me when using latest mozilla-central.

Comment 21

[Tom S [:evilpie]]

Sorry! I had tested this in my normal profile and apparently my adblocker was responsible for closing the opened tab.

Comment 22

[Christoph Kerschbaumer [:ckerschb]]

Comment on attachment 9147195 [details]
Bug 1582115: Exempt pdf.js from being subject to CSP from page. r=gijs

Beta/Release Uplift Approval Request

• User impact if declined: Web pages using a CSP which does not allow scripts to load and additionally display a PDF using a blob URI, then the CSP will block pdf.js scripts not allowing the PDF to be displayed.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: * https://suspicious-nightingale-19ff29.netlify.app/
• click 'Open PDF'
• pdf should open and now CSP errors should be displayed in the console.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is 'low' risk because the patch only allowlists specific resource:// URIs not to be subject to CSP.
• String changes made/needed: no

Comment 23

[robbterr]

if you have a base-uri csp rule set,

something like:
base-uri: 'self'

you still need to add resource://pdf.js to it, to make this fix work
base-uri: 'self' resource://pdf.js

if not, you get the the error:
Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf resource://pdf.js/web/ blockiert ("base-uri").

Comment 24

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9147195 [details]
Bug 1582115: Exempt pdf.js from being subject to CSP from page. r=gijs

P1, has tests, does not look risky and this is a bug reported multiple times, uplift approved for beta 6, thanks.

Comment 25

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/1b36f89fbb9a

Comment 26

[Hani Yacoub, Desktop QA]

Verified as fixed on Windows 10 x64, MacOS 10.14 and on Ubuntu 18.04 on the latest Firefox Nightly and on Firefox 77.0b6.

Comment 27

[robbterr]

Attachment: demo page - base-uri blocks the loading of pdf.js

Comment 28

[robbterr]

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

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #11)

Seen on Twitter today: https://twitter.com/k4ii_/status/1258657381157867520
Confirmed with STR from comment 8.

I am on it.

Just wanted to make sure you did get my point from my last comment.
You added an exception for the the script-src rule, but not for the base-uri rule.
So if you have both rules set in your app, you still need to add resource://pdf.js/ to base-uri wo allow the allow pdf.js to work.

I added an example html.

Comment 29

[robbterr]

Attachment: demo page - base-uri with added resource://pdf.js

Comment 30

[Christoph Kerschbaumer [:ckerschb]]

(In reply to robbterr from comment #28)

Just wanted to make sure you did get my point from my last comment.
You added an exception for the the script-src rule, but not for the base-uri rule.
So if you have both rules set in your app, you still need to add resource://pdf.js/ to base-uri wo allow the allow pdf.js to work.

Hey :robterr, thanks for your contributions and for testing. Our patch should make resource://pdf.js/ agnostic to any kind of directive within a CSP. In other words, it should not matter whether you set script-src 'none' or base-uri 'none'. I tested using latest mozilla-central and I can't reproduce the base-uri error.

What version of Firefox did you use for testing? mozilla-central or Nightly, or Release? Please note that the fix is not in release yet, it was uplifted to beta which should go into release on June 2nd.

BTW, your test cases in comment 27 and comment 29 do not include a base-uri directive.

Anything I am missing? If so, please let me know and I'll take a look right away. Thanks again for testing and your help!

Comment 31

[robbterr]

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

(In reply to robbterr from comment #28)

Just wanted to make sure you did get my point from my last comment.
You added an exception for the the script-src rule, but not for the base-uri rule.
So if you have both rules set in your app, you still need to add resource://pdf.js/ to base-uri wo allow the allow pdf.js to work.

Hey :robterr, thanks for your contributions and for testing. Our patch should make resource://pdf.js/ agnostic to any kind of directive within a CSP. In other words, it should not matter whether you set script-src 'none' or base-uri 'none'. I tested using latest mozilla-central and I can't reproduce the base-uri error.

What version of Firefox did you use for testing? mozilla-central or Nightly, or Release? Please note that the fix is not in release yet, it was uplifted to beta which should go into release on June 2nd.

BTW, your test cases in comment 27 and comment 29 do not include a base-uri directive.

Anything I am missing? If so, please let me know and I'll take a look right away. Thanks again for testing and your help!

hi,
i tried it with the current nightly build ( 78.0a1 (2020-05-17) (64-Bit) )
if i open the html from comment 27 i get the error and with comment 29 not

the comment 27 has this csp line ( when i click on the little "Details" link)
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-Wp1I6UYyAEvePYUa4YkEDw==' 'unsafe-inline' https://cdnjs.cloudflare.com; object-src 'none'; base-uri 'self' ">

and comment 29 this:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-Wp1I6UYyAEvePYUa4YkEDw==' 'unsafe-inline' https://cdnjs.cloudflare.com; object-src 'none'; base-uri 'self' resource://pdf.js ">

Comment 32

[Christoph Kerschbaumer [:ckerschb]]

Attachment: base-uri-bug.png

Ha, interesting. So I can confirm there is another problem, the error I get is:

Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”). panel.js:78:24

but I currently don't see that we are blocking resource://pdf.js anywhere. This needs more investigation.

Thanks for reporting (and sorry, your CSPs were correct in comment 27 and comment 29).

Comment 33

[Christoph Kerschbaumer [:ckerschb]]

I just filed a follow up bug for the base-uri problem (see Bug 1638826). Uplifting Bug 1638826 is probably too big of a change that close to the end of the cycle and I rather fix that problem as a follow up.

To sum it up: The problem within this Bug that a CSPs script-src directive affects the loading for pdf.js was fixed and uplifted within this bug.

The follow up bug is to fix the problem within base-uri which might also affect pdf.js but uses a different code path within Firefox. The reason I think it was worth uplifting this bug is that the script-src directive is more likely used than base-uri. I know this is not the optimal solution, but page's using a CSP of base-uri have to wait one more iteration of Firefox till this problem is fixed - sorry about that but in this situation the best possible path forward!