Re: Security mitigations for IP leakage

<technical contributor hat>

Just some commentary on the mitigation mechanisms... we've had quite
strong push to be "secure by default", for some meaning of the word
"secure". This means (I think) being "secure" for the case where
Javascript content is embedded in the primary page the user loads, and
which the user interacts with for other reasons.

Den 22. april 2015 11:06, skrev Dominique Hazael-Massieux:
> Hi,
> 
> As previously discussed, the ability that WebRTC gives to any random web
> site to discover IP addresses that would not be otherwise detectable is
> an issue that we will need to address:
> https://github.com/w3c/webrtc-pc/issues/179
> 
> Justin recently brought a proposal to the RTCWeb list on how to manage
> this mostly from a protocol perspective:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.html
> 
> In complement to the protocol approach, I thought it would be worthwhile
> to document what mitigation mechanisms exist on the Web platform to
> limit when potentially sensitive features can be used by Web pages.
> 
> I list below the ones I've been able to identify (but there may be
> more); I think it would be useful to study at some point which of these
> could be used to limit the impact of the IP address leakage — but that
> probably requires a good understanding of the various threats that
> revealing private IP address entails (on which I have enlisted the help
> of the Privacy Interest Group, with only limited results so far [1]).
> 
> The mitigations off the top of my head (please help complete it):
> * the same-origin policy (limits what can be done on and by resources
> from different origins)

reduces attack surface, but doesn't mitigate the "default case" above

> * user prompt (ask the user before granting permission)

see the debate about "dialog blindness" ...

> * user forgiveness (allow by default, but let user undo the permission
> grant)

fails to be "secure by default"

> * user opt-in (denied by default, but allow the user to explicitly allow)


(side note: I've seen several pages in the last few days on "here's the
instructions on how to allow NPAPI in Chrome" - it's annoying.)

> * user engagement (only grant access to a feature if the user has
> interacted with the page)

doesn't mitigate the "default case".

> * restricted to top-level browsing context (a feature can only be used
> from the top frame, with sometimes the ability to explicitly grant it to
> embedded content)
> 
> * content security policy (limit set by HTTP header on what the content
> can do)

on response headers? that will only help if the site is not owned by the
attacker.

> * UI indicators (give hints to the user that something is going on)
> 
> * secure-origin only (feature only available from https)
> 
> * frecency heuristics (feature only available if the user has come to a
> given Web page recently and frequently)

this will lead to inconsistent behavior, which is not a great thing to
support

> * bundled permission (permission granted if a more sensitive and related
> permission has been granted)
> 
> * whitelist / blacklist and other out-of-band mechanisms (e.g. search
> engine warnings)

I think "available to installed applications/extensions" belongs on the
list too (as we've so far done for the screencast permission).

> 
> Dom
> 
> 1. https://www.w3.org/wiki/Privacy/IPAddresses
> 
>

Received on Wednesday, 22 April 2015 11:14:35 UTC