1167259 - CSP does not block favicon request

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Favicon Handling, defect)

Description

[Masato Kinugawa]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150513174244

Steps to reproduce:

Firefox's CSP does not block favicon request.
According to spec, it should be blocked : http://www.w3.org/TR/CSP/#directive-img-src

Due to this, attacker can bypass CSP partially and may get sensitive information via the request.

Steps to reproduce:
1. Go to http://vulnerabledoma.in/csp_favicon using Firefox Mobile. This page has CSP header and only following contents:

<link rel=icon href=http://www.google.com/favicon.ico?123456>

2. Firefox Mobile sends favicon request. See network traffic.

FYI, Firefox(desktop) can block this case properly. But using redirect, does not be blocked. You can test from:

http://vulnerabledoma.in/csp_favicon_redirect


Actual results:

CSP does not block the favicon request.


Expected results:

CSP should block the favicon request.

Comment 1

[:Gijs (he/him)]

Margaret, seems like Mobile could maybe fix this separately from bug 1119386? Desktop is going to have a harder time fixing the redirect thing, though we're working on it. Might make sense to split off into a separate bug?

(In reply to Masato Kinugawa from comment #0)
> FYI, Firefox(desktop) can block this case properly. But using redirect, does
> not be blocked. You can test from:
> 
> http://vulnerabledoma.in/csp_favicon_redirect

This requires the domain runs an open redirect, doesn't it?

Comment 2

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #1)
> (In reply to Masato Kinugawa from comment #0)
> > FYI, Firefox(desktop) can block this case properly. But using redirect, does
> > not be blocked. You can test from:
> > 
> > http://vulnerabledoma.in/csp_favicon_redirect
> 
> This requires the domain runs an open redirect, doesn't it?

More specifically, a domain that is allowed as per the csp's img-src directive.

Comment 3

[Masato Kinugawa]

(In reply to :Gijs Kruitbosch from comment #1)
> This requires the domain runs an open redirect, doesn't it?
Correct.

FYI, also link prefetching request does not be blocked by CSP. It seems that CSP's spec does not cover link prefetching request. You can test from: http://vulnerabledoma.in/csp_link_prefetching
What do you think?

Comment 4

[:Gijs (he/him)]

(In reply to Masato Kinugawa from comment #3)
> (In reply to :Gijs Kruitbosch from comment #1)
> > This requires the domain runs an open redirect, doesn't it?
> Correct.
> 
> FYI, also link prefetching request does not be blocked by CSP. It seems that
> CSP's spec does not cover link prefetching request. You can test from:
> http://vulnerabledoma.in/csp_link_prefetching
> What do you think?

I don't know much about link prefetching; it should probably be a separate bug, that way it can be picked up by people who do (know more about link prefetching).

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

Firefox for Android's favicon fetching is done in Java code. It may be difficult to handle this case correctly without impacting page laod time.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

As long as the load is done in Java it's likely going to be very hard to do this correctly. In particular handling redirects will be hard.

This likely doesn't just affect CSP compliance, but also mixed-content-blocking.

Comment 7

[:Margaret Leibovic]

See bug 507641 for some more context - there are multiple places where we don't use Gecko's networking stack.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Are there more than this one which enables webpages to trigger requests?

The other bug hasn't seen much action in the last two years, so it might be worth making a special exception for favicons.

Comment 9

[Richard Newman [:rnewman]]

Favicons and msapplication-TileImage, I think. Perhaps the latter is supplied by Gecko.

Favicon loads can and do occur outside of a page load context, and favicon URLs are not only provided by the page -- browsers have guessed favicon URLs for years and years, and we continue to do so.

It's not clear to me what's supposed to happen if:

1. Fennec guesses domain.tld/favicon.ico and fetches it
2. Fennec fetches a known favicon URL some time after the page load
3. … or the same favicon URL for a different page

These boil down to "what if the CSP isn't known or might have changed" -- if I'm not misunderstanding, CSP is delivered via headers and thus scoped to a particular page load, and that's really not a sane match for how a web browser works with favicons.

Making favicon fetches obey CSP would require reflecting CSP headers into Java, perhaps persisting them, and then looking at that context when processing a favicon load request.

It is very hard for me to justify that engineering time compared to, e.g., Bug 942653; not using your configured proxy leaks much more behavior than not obeying CSP.

I would accept a patch that fetched favicons using a wrapped Necko, if it didn't bloat our APK and functioned correctly when Gecko is running out of memory.

FTR, Fennec's favicon fetch doesn't send cookies, referrers, or otherwise behave much like a browser at all.

Comment 10

[Daniel Veditz [:dveditz]]

This is a spec violation, but not a security bug that needs to be hidden.

Comment 11

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.