1181379 - Image onload doesn't run if src attribute is data: on a facebook page due to a CSP that forbids data: loads

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Marco Salazar]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36

Steps to reproduce:

On any page add the following html:

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" onload="console.log(this)"/>
<img src="https://bugzilla.mozilla.org/extensions/GuidedBugEntry/web/images/advanced.png" onload="console.log(this)"/>


Actual results:

You see only the second image's console.log in FireFox beta


Expected results:

You should see both images' console.log. (This works in previous versions of FireFox)

Comment 2

[Boris Zbarsky [:bzbarsky]]

> This works in previous versions of FireFox

I don't know which version of Firefox you're using (you didn't say), but I see both images in the console log in both Firefox 39 and a current nightly when I put your HTML into a file and load that file.  Which exact Firefox version are you using?  Is there a specific page where you're seeing this problem?

Comment 3

[Marco Salazar]

It's in the Beta version 40.0

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, just tried a Beta 40.0 build on Mac, and I can't reproduce the problem there either....

Do you see the problem in safe mode?  What about in a clean profile?

Comment 5

[Marco Salazar]

Try on facebook.com

Comment 6

[Boris Zbarsky [:bzbarsky]]

The facebook.com front page doesn't have any data: images.

Look, I'm happy to help sort out what's going on here if you're willing to work with me a bit.  But you need to give me _something_ useful to work with.

Comment 7

[Marco Salazar]

The onload event for the first image doesn't fire when inserted into the DOM while logged into facebook.com

Insert the images anywhere in the DOM to reproduce:
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" onload="console.log(this)"/>
<img src="https://bugzilla.mozilla.org/extensions/GuidedBugEntry/web/images/advanced.png" onload="console.log(this)"/>

This doesn't happen on previous versions of FireFox or other browsers, just this beta v40.

Comment 8

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Might break faceboook

Oh, you're injecting images like that into facebook?

Facebook (at least the front page) has the following content-security-policy header:

  default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:* ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://attachment.fbsbx.com https://attachment.fbsbx.com;

Per the CSP specification (informative text at <http://www.w3.org/TR/CSP/#source-list-guid-matching>):

  As defined above, special URL schemes that refer to specific pieces of unique content,
  such as "data:", "blob:" and "filesystem:" are excluded from matching a policy of * and
  must be explicitly listed.

The normative bit is http://www.w3.org/TR/CSP/#match-source-expression step 2 which explicitly excludes "data:" URIs from matching *.

So Facebook's policy explicitly prohibits loading anything from data:.

We didn't use to implement the specification correctly here, but fixed that in bug 1086999.  Chrome is working on fixing a similar bug they have; see https://code.google.com/p/chromium/issues/detail?id=473904

All that said, I'm seeing some logs on facebook about font loads from data: being blocked too.  So it sounds like we should at least talk to facebook about this before shipping 40...

Comment 9

[Marco Salazar]

I'll pass this information along -- I'm an engineer at Facebook. Thanks for helping me debug this.

Comment 10

[Boris Zbarsky [:bzbarsky]]

No problem.  I wonder why there weren't clear console messages about CSP blocking this when I first tried it on facebook.com....

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Boris Zbarsky [:bz] from comment #10)
> No problem.  I wonder why there weren't clear console messages about CSP
> blocking this when I first tried it on facebook.com....

Hey Boris, I can take a closer look tomorrow, but I think we (as you) have identified the problem within Bug 970790. In particular your comment here [1] explains it best. It is on my to do list, but not very high up in my priority list at the moment. If you think we should prioritize a fix for that, please let me.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=970790#c14

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, right, that.  Well, it would have made [e-mail]'s job much easier if we'd just had a console message telling him what was up...

I do think we should up the priority if we're going to ship bug 1086999 because otherwise people will have their sites failing for mysterious reasons and be very very confused.  :(

Comment 13

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Boris Zbarsky [:bz] from comment #12)
> Oh, right, that.  Well, it would have made [e-mail]'s job much
> easier if we'd just had a console message telling him what was up...
> 
> I do think we should up the priority if we're going to ship bug 1086999
> because otherwise people will have their sites failing for mysterious
> reasons and be very very confused.  :(

Agreed, we should get that fixed. As a consolidation, the error should at least pop up in the browser console, no? At least I would hope so, see:
http://mxr.mozilla.org/mozilla-central/source/dom/security/nsCSPUtils.cpp#87

Comment 14

[Boris Zbarsky [:bzbarsky]]

I didn't obviously see it in the browser console....

Comment 15

[Boris Zbarsky [:bzbarsky]]

Ah, looks like I get things in the browser console in non-e10s mode.  Doesn't seem to happen in e10s.

Comment 16

[jen strickland :jenstrickland]

It is said above that this didn't happen in earlier versions, so can we get info on what version/s it works in, so we can identify this as a regression, if appropriate?

Do we want tracking for 41 and 42?

I'll enable tracking for 40 so we find a way to resolve either the issue or how it is communicated.

Comment 17

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

> so can we get info on what version/s it works in

See the "affected" flags and comment 8.

> Do we want tracking for 41 and 42?

Probably.

Comment 18

[Ed]

Hi. There is a similar problem with the Social Fixer addon (images that are links are invisible but the links work).  The problem does not exist in 39.0.  I don't know about 41, but it also affects Nightly.

Comment 19

[Kate Glazko]

Tracking, see Comment 8

Comment 20

[Ed]

Hi.  I've just been notified that the problem does not exist in 40 64 bit, as it does in 30 32 bit.

Comment 21

[Marco Salazar]

We've resolved the issue on our end, thanks again for helping debug this.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Thanks for fixing this!

Comment 23

[Kate Glazko]

Updating the status flags because of Comment 21.