1095967 - Icon of web notification API bypasses CSP and it's request shares cookie between non-private mode and private mode

Status: NEW

(Core :: DOM: Security, defect)

Description

[Muneaki Nishimura]

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

Steps to reproduce:

1. To set cookie, launch http://csrf.jp/cookie/set.php?domain=csrf.jp&name=VICTIM&value=SECRET on normal browsing mode.
2. Launch http://alice.csrf.jp/notification and permit web notification
3. Notification with red icon is shown on your desktop
(the icon is loaded from http://mallory.csrf.jp)
4. Open private-browsing mode and launch http://alice.csrf.jp/notification
5. Notification is shown with red icon on your desktop again



Actual results:

1) In procedure 3, alice.csrf.jp disallows loading of cross-origin images by CSP, but a red icon loaded from mallory.csrf.jp is shown in web notification.

2) In procedure 5, private-browsing mode inherits grants of notification, so no confirmation dialog for notification is shown when invoking web notification. And when red icon is loaded, non-browser mode cookie is sent even though the notification is invoked from private browsing mode.



Expected results:

Icon of web notification should not bypass CSP of the origin page.
And, cookie should not be shared between non-private mode and private mode.

Comment 1

[Daniel Veditz [:dveditz]]

1) I'm not convinced the notification icon should be covered by CSP because it's not "in" the page. The CSP spec certainly doesn't cover it. Then again, beacons are covered even though they can't return data to the page, but that's because they are more or less equivalent to XHR which is covered. (Also the event handlers for it run in the page so it's messy, but you can't get the icon back from the event or Notification object, just the URL you already know.)

It's worth discussing on the public-webappsec list and I'm going to defer thinking about that aspect until we get a sense of where the spec might land on the issue.

2a) I believe in all other cases permissions saved in non-private mode persist into private mode so this would be the correct behavior. Private browsing isn't anonymous browsing. Permissions shouldn't bleed from private to non-private, of course, although we do make exceptions for things the user has said to save permanently (like bookmarks). Not sure if that applies to "always remember" permissions. Ehsan?

2b) we do make an effort to give people a clean slate with respect to cookies, so sending the non-private cookies with the notification seems like it would be a bug. Thoughts, Ehsan?

Comment 2

[Daniel Veditz [:dveditz]]

> It's worth discussing on the public-webappsec list

Thread started here:
http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0119.html

Comment 3

[(no longer active)]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> 1) I'm not convinced the notification icon should be covered by CSP because
> it's not "in" the page. The CSP spec certainly doesn't cover it. Then again,
> beacons are covered even though they can't return data to the page, but
> that's because they are more or less equivalent to XHR which is covered.
> (Also the event handlers for it run in the page so it's messy, but you can't
> get the icon back from the event or Notification object, just the URL you
> already know.)
> 
> It's worth discussing on the public-webappsec list and I'm going to defer
> thinking about that aspect until we get a sense of where the spec might land
> on the issue.

Anne, what do you think?

> 2a) I believe in all other cases permissions saved in non-private mode
> persist into private mode so this would be the correct behavior. Private
> browsing isn't anonymous browsing. Permissions shouldn't bleed from private
> to non-private, of course, although we do make exceptions for things the
> user has said to save permanently (like bookmarks). Not sure if that applies
> to "always remember" permissions. Ehsan?

I think it's OK to honor the permission which was set in a non-private window here.

> 2b) we do make an effort to give people a clean slate with respect to
> cookies, so sending the non-private cookies with the notification seems like
> it would be a bug. Thoughts, Ehsan?

Yes, that is a bug.

I looked at the code and there are so many layers of abstraction here, but I think that on desktop, we end up opening alerts.xul which ends up loading the image here: <http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/resources/content/alert.js#64>.  Neil, is this the code that gets used on desktop?

If yes, we need to set the privacy status of the alerts.xul window that we open based on the privacy status of the window that is using the notification API.

Comment 4

[Anne (:annevk)]

I don't see why there would be any question of not handling them through CSP. CSP should cover all fetches an environment can make.

Comment 5

[Neil Deakin]

> I looked at the code and there are so many layers of abstraction here, but I
> think that on desktop, we end up opening alerts.xul which ends up loading
> the image here:
> <http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/
> resources/content/alert.js#64>.  Neil, is this the code that gets used on
> desktop?

That's used for notifications that appear in the corner of the screen when there isn't a native notification mechanism. On my Mac though, when I try using the steps above, the notifications are not using these; instead they are normal arrow notifications opened via PopupNotifications.jsm

Comment 6

[(no longer active)]

(In reply to Neil Deakin from comment #5)
> > I looked at the code and there are so many layers of abstraction here, but I
> > think that on desktop, we end up opening alerts.xul which ends up loading
> > the image here:
> > <http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/
> > resources/content/alert.js#64>.  Neil, is this the code that gets used on
> > desktop?
> 
> That's used for notifications that appear in the corner of the screen when
> there isn't a native notification mechanism. On my Mac though, when I try
> using the steps above, the notifications are not using these; instead they
> are normal arrow notifications opened via PopupNotifications.jsm

Do you know how we load the notification image in that case?  I'm not sure what arrow notifications are, and looking at the code I found <http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/PopupNotifications.jsm#573> but it's not clear to me where the actual icon loading happens.

Comment 7

[Neil Deakin]

You'd be best to ask Gavin about PopupNotifications.jsm

Comment 8

[Muneaki Nishimura]

Desktop notification on Mac always uses oapplication icon. The icon url specified by web contents seems to be ignored.

Comment 9

[(no longer active)]

(In reply to Muneaki Nishimura from comment #8)
> Desktop notification on Mac always uses oapplication icon. The icon url
> specified by web contents seems to be ignored.

I definitely see both the application icon and the red square icon on this test case on OSX 10.10.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Gijs and Florian have looked at PopupNotifications lately.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(In reply to Neil Deakin from comment #5)
> That's used for notifications that appear in the corner of the screen when
> there isn't a native notification mechanism. On my Mac though, when I try
> using the steps above, the notifications are not using these; instead they
> are normal arrow notifications opened via PopupNotifications.jsm

That's not what I see, I see this: https://cloudup.com/cnQBV5zmP6Y

That's a nsIAlertsService notification, which on OS X typically ends up passing the absolute icon URL into http://hg.mozilla.org/mozilla-central/annotate/ff4a63d66806/widget/cocoa/OSXNotificationCenter.mm#l199. The alert.js code that Ehsan previously linked to is fallback in case the "native" notification system fails or doesn't exist.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

IIRC we use the generic XUL mechanism on Windows, which seems to be what the original reporter is testing with. I guess it would make sense to mark the alert.xul docshell as private if it is triggered from private browsing, but that would likely require adding some parameter to the showAlertNotification API.

Comment 13

[:Gijs (he/him)]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #12)
> IIRC we use the generic XUL mechanism on Windows, which seems to be what the
> original reporter is testing with. I guess it would make sense to mark the
> alert.xul docshell as private if it is triggered from private browsing, but
> that would likely require adding some parameter to the showAlertNotification
> API.

Do we need any other additional parameters to deal with the CSP part? hg blame for the loadimage here:

http://hg.mozilla.org/mozilla-central/annotate/ff4a63d66806/widget/cocoa/OSXNotificationCenter.mm#l246

seems to imply we are meant to already apply "referrer policies" on the image load, and we pass aPrincipal. I don't know if that is enough.

Comment 14

[Muneaki Nishimura]

> I definitely see both the application icon and the red square icon on this
> test case on OSX 10.10.

Thanks, the icon was not appeared on my OSX 10.8.5 but I could see it is shown on OSX 10.10 as you said.

Comment 15

[(no longer active)]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #12)
> IIRC we use the generic XUL mechanism on Windows, which seems to be what the
> original reporter is testing with. I guess it would make sense to mark the
> alert.xul docshell as private if it is triggered from private browsing, but
> that would likely require adding some parameter to the showAlertNotification
> API.

Thinking more about this, do you think we can simply get away by always opening the alerts.xul window in private mode?  Is there any reason to send cookies alongside the image request?

(In reply to :Gijs Kruitbosch from comment #13)
> (In reply to :Gavin Sharp [email: [e-mail]] from comment #12)
> > IIRC we use the generic XUL mechanism on Windows, which seems to be what the
> > original reporter is testing with. I guess it would make sense to mark the
> > alert.xul docshell as private if it is triggered from private browsing, but
> > that would likely require adding some parameter to the showAlertNotification
> > API.
> 
> Do we need any other additional parameters to deal with the CSP part? hg
> blame for the loadimage here:
> 
> http://hg.mozilla.org/mozilla-central/annotate/ff4a63d66806/widget/cocoa/
> OSXNotificationCenter.mm#l246
> 
> seems to imply we are meant to already apply "referrer policies" on the
> image load, and we pass aPrincipal. I don't know if that is enough.

The referrer policy is different, it controls whether we send the HTTP Referer header or not.  This code needs to use NS_CheckContentLoadPolicy to check the CSP, and set the policy on the channel that it's creating, similar to <http://hg.mozilla.org/mozilla-central/rev/0392348b7648#l6.174>, for example.

Comment 16

[Anne (:annevk)]

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #15)
> Thinking more about this, do you think we can simply get away by always
> opening the alerts.xul window in private mode?  Is there any reason to send
> cookies alongside the image request?

I see no reason why this image fetch should be different from others. I don't think we should change this without public discussion.

Comment 17

[(no longer active)]

I moved the part for loading the image in private mode to bug 1106116.

Comment 18

[Al Billings [:abillings - ex-MoCo]]

Ehsan, can someone take this issue as it is a security issue sitting on our plate. Can you confirm that this is a sec-moderate rated issue?

Comment 19

[(no longer active)]

I'm not sure what the implications of not respecting CSP when loading this icon would be, so it's hard for me to judge the rating here...

Comment 20

[Anne (:annevk)]

I think it's a minor issue as to be able to create a Notification object that issues the fetch that violates the policy of the page you need to be able to execute script and the page needs to have permission to show notifications (although someone needs to check whether we refuse to load images if the page doesn't have permission to display notifications I guess).

Comment 21

[Daniel Veditz [:dveditz]]

Looks like the security part of this, exposing the non-private cookie, was handled in bug 1106116. The remaining CSP part doesn't need to be hidden. Neither part really rises to the level of bugs to which we award a bug bounty.