1735994 - Implicit reference to `/favicon.ico` should be allowed regardless of CSP header

Status: UNCONFIRMED

(Core :: DOM: Security, enhancement, P3)

Description

[Mikko Rantalainen]

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

Steps to reproduce:

Distribute an image from a HTTP server with following HTTP header:

Content-Security-Policy: default-src 'none';

Actual results:

The image is rendered but CSP violation is triggered and if the policy contained report-uri, it will be spammed about this issue.

Expected results:

The distributed image should have been rendered without errors.

Additional details:

When Firefox renders the image fetched over the HTTP connection it also wants to use implicit reference to /favicon.ico to use for tab icon (I think Firefox used the image as tab icon historically but this was changed later).

The implicit reference to /favicon.ico should not be limited by the CSP rules because it's caused by internal Firefox implementation and will not cause security issues regardless of CSP header.

In practice, the current Firefox implementation prevents anybody from using header like

Content-Security-Policy: default-src 'none';

and at minimum they should use

Content-Security-Policy: default-src 'none'; img-src 'self'

to avoid this issue. However, this latter policy is actually much less strict.

Firefox should be fixed not to block internally decided requests based on server CSP header. In addition, in case e.g. Firefox MathML rendering or PDF reader need to fetch fonts from some trusted remote server, those fetches should not be limited by the server sent HTTP headers either because such requests are about Firefox internal implementation only.

Comment 1

[Mikko Rantalainen]

I forgot to mention that you have to load the image in a (new) tab, not use it as embedded part of the other resource.

Comment 2

[Mikko Rantalainen]

I think bug 1698115 has the same root cause.

Comment 3

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 4

[Daniel Veditz [:dveditz]]

To be very clear, we're only talking about the implicit favicon.ico that might be OK. Sites that specify a custom favicon in a <link> header of course must be blocked by CSP (depending on the policy).

Questions:

• Is it worth the code complication making that distinction? (probably not?)
• should we even honor CSP headers for non-document things like images? (also maybe not?)

Comment 5

[Paul Romer]

I seem to be encountering another side effect of this same underlying bug -- false positive violations of CSP caused by favicons. I agree with this reporter that this seems to be related to bug 1698115.

Why this bug matters: For any security related measure, false positives are a serious problem. They detract from the true positives and encourage responses that weaken security such as the one that the original report noted.

The common feature here is that Firefox generates a false positive report of CSP violation when someone opens a page that has an image or a pdf in a new tab. The reported violation is related to the request for a favicon.ico file.

To see an illustration in production:

a) Open this link

b) Then

• click on the link in the first line of paragraph 5 with text that says "1990 paper" -- it will open a pdf in a new tab -- or
• copy and paste the link into a new browser tab.

In each case, the PDF opens as it should. To see the bug, inspect the page for the net tab and look for this error in the console:

"The resource at “https://paulromer.net/favicon.ico” was blocked due to its Cross-Origin-Resource-Policy header (or lack thereof). See https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)# Endogenous.pdf"

FF does indeed prevent the favicon.ico file from displaying in the browser tab.

The suggested work-around -- adding img-src to the security policy -- stops violations for images but not PDFs

FYI, I was able to replicate the suggestion from the original report that when opening an image (instead of a PDF) in another tab, one can avoid this error by adding this to the security policy: img-src 'self'.

You see a case that does not generate an error after this change here:

a) Opening this page and

b) then opening the image from the right side of the page in a new tab whilst monitoring the console to verify that there is no CSP violation and confirming that the favicon does show in the browser tab.

However, as the previous report notes, this addresses the problem by weakening the security policy. Moreover, it does not address the underlying problem. In particular, opening PDF files in a new tab still generate the false report of a violation.

Comment 6

[Paul Romer]

PS: I do not understand this thrust of the comment by Daniel Veditz regarding implicit links.

But to rule out one possible issue, I changed my website to include an explicit link to the favicon.ico file in the header. It is now present if you follow the steps described above to replicate the problem. The problem is still there: opening a PDF in a new tab causes a report of a CSP violation.

The simplest way to see the problem is to try to go directly to a link to a pdf on my website such as:

• https://paulromer.net/the-trouble-with-macro/WP-Trouble.pdf

• https://paulromer.net/posts/2015/pdf/Endogenous.pdf

In each case, if Firefox is set to display PDF files, it sends a report of a CSP violation related to the favicon.ico file.

Comment 7

[Paul Romer]

PPS:

• I also see false reports of CSP violations when I try to view these pdfs using Safari.

• I do not see any false reports of CSP violations when I view them using Chrome.

Comment 8

[Adrian]

This bug requires me to use a less restrictive CSP such as default-src 'none'; img-src 'self' instead of just default-src 'none' on a page service arbitrary user-uploaded content. While I don't see a risk there, it's ugly because I can't just do "user-uploaded --> zero permissions" due to this.

It would be nice if it could be fixed.