[signin] security issues of website sourced iframes in the persona dialog

[Lloyd Hilaiel]

(I need skinny and francois to read this!)

On FirefoxOS, the environment in which persona runs (rendered in a separate process) it does not make sense to spawn the web browser for ToS or privacy policy links. This puts us in a bit of a pickle (no pun intended).

Our approach to handle is to open ToS and PP links in an iframe inside the dialog on firefox os.

Now, we can secure this with the "sandbox" attribute on Firefox, but not everywhere - it is not available on IE8 & IE9 - http://caniuse.com/#search=sandbox

There are two approaches available to us:

1. use iframes for the ToS and PP links *everywhere*, accepting that now website code can run inside the dialog in an iframe, and can framebust [1] - benefits include less forking of our code based on UA, and arguably less likelihood for the popup to get buried, and maybe a better UX (?).
2. perform UA sniffing and only use iframes on FirefoxOS

There are also hybrid options available.

A fix needs to land in the codebase by friday and make it into production by 5/22 to support FirefoxOS.

We need a quick and decisive call on this - Francois can I hand this to you to get us a recommendation?
Skinny, do you feel strongly either way?

Anyone else wanna weigh in here?

lloyd

[1] current countermeasures are simply to register an unload handler in the dialog and close the dialog if we are unloaded and it is not during redirection to a primary domain.

[Jonathan Brown]

When I demoed Persona at Drupal meetup in Melbourne people were surprised
that the ToS and PP links opened underneath the Persona popup. The popup
had to be closed so the documents could be read.

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Sean McArthur]

Some context: when I had to add this to the B2G branch, I was vehemently
opposed because of the risk of frame busting in our dialog, until the
Firefox devs pointed out that for B2G, I could use the `sandbox` attribute
to be safe. If there's no equivalent in IE8 and 9, I'd feel all vehement
again.

[Francois Marier]

On 30/04/13 14:37, Lloyd Hilaiel wrote:
> We need a quick and decisive call on this - Francois can I hand this to you to get us a recommendation?

I summarized what I found here:

https://etherpad.mozilla.org/i2ZhpiC3di

I'm not sure I've got all of the possible risks (I will ping security
folks), but it looks like the "security=restricted" attribute would
solve the problem that Sean highlighted on IE8 and IE9.

So the only browser that wouldn't be protected if we were to load ToS/PP
in an iframe is Opera (until they release a chromium-based browser).

Francois

[Shane Tomlinson]

On 30/04/2013 03:37, Lloyd Hilaiel wrote:
> (I need skinny and francois to read this!)
>
> On FirefoxOS, the environment in which persona runs (rendered in a separate process) it does not make sense to spawn the web browser for ToS or privacy policy links. This puts us in a bit of a pickle (no pun intended).
>
> Our approach to handle is to open ToS and PP links in an iframe inside the dialog on firefox os.
>
> Now, we can secure this with the "sandbox" attribute on Firefox, but not everywhere - it is not available on IE8 & IE9 - http://caniuse.com/#search=sandbox

IE has an alternate implementation using the "security=restricted"
attribute. More can be read about here:

http://msdn.microsoft.com/en-us/library/ie/ms534622%28v=vs.85%29.aspx

Shane

[Shane Tomlinson]

On 30/04/2013 09:39, Francois Marier wrote:
> On 30/04/13 14:37, Lloyd Hilaiel wrote:
>> We need a quick and decisive call on this - Francois can I hand this to you to get us a recommendation?
> I summarized what I found here:
>
> https://etherpad.mozilla.org/i2ZhpiC3di
>
> I'm not sure I've got all of the possible risks (I will ping security
> folks), but it looks like the "security=restricted" attribute would
> solve the problem that Sean highlighted on IE8 and IE9.

This was already added to the PR. Glad to see we came to the same
conclusion. :D

https://github.com/mozilla/browserid/pull/3236/files#L7R20

Shane

[Austin King]

On 4/29/13 7:37 PM, Lloyd Hilaiel wrote:
> 2. perform UA sniffing and only use iframes on FirefoxOS

Instead of UA sniffing, you can do feature detection.
Modernizr does this for iframe sandbox:
http://modernizr.com/news/modernizr-262/

[Shane Tomlinson]

On 30/04/2013 17:18, Austin King wrote:
> On 4/29/13 7:37 PM, Lloyd Hilaiel wrote:
>> 2. perform UA sniffing and only use iframes on FirefoxOS
>
> Instead of UA sniffing, you can do feature detection.
> Modernizr does this for iframe sandbox:
> http://modernizr.com/news/modernizr-262/

There is a downside to doing UA sniffing and using iframes for only a
subset of browsers - we need a notification mechanism to tell an RP when
their TOS/PP agreements in displayed in an iframe instead of a new tab.

When a TOS/PP agreement is opened in a new tab, the content of that tab
can contain links and make use of Javascript. When a TOS/PP agreement is
shown in a sandboxed iframe, links are useless and Javascript is
disabled. An RP may want to know this so they can serve users
appropriate content.

I propose we use one mechanism universally, so that RPs just don't have
to worry about it. The code to inform the RP is pretty trivial, I've
already implemented and then removed one version of it out, I just want
RPs to have as little to worry about as possible.

Shane

[Shane Tomlinson]

On 30/04/2013 17:35, Shane Tomlinson wrote:

> There is a downside to doing UA sniffing and using iframes for only a
> subset of browsers - we need a notification mechanism to tell an RP
> when their TOS/PP agreements in displayed in an iframe instead of a
> new tab.
>
> When a TOS/PP agreement is opened in a new tab, the content of that
> tab can contain links and make use of Javascript. When a TOS/PP
> agreement is shown in a sandboxed iframe, links are useless and
> Javascript is disabled. An RP may want to know this so they can serve
> users appropriate content.
>
> I propose we use one mechanism universally, so that RPs just don't
> have to worry about it. The code to inform the RP is pretty trivial,
> I've already implemented and then removed one version of it out, I
> just want RPs to have as little to worry about as possible.
>
> Shane
>
>

Cross browser fun alert!

Neither Firefox Beta+ nor IE are happy with our iframe solution when the
TOS/PP agreements are served over http. Firefox Beta+ refuses to show
the TOS/PP due to mixed content and IE shows a warning asking the user
whether they want to continue. We saw something similar with siteLogo.

This can be seen on the force-issuer ephemeral instance [1]. Basic STR -
open the dialog in Firefox. Open the dev tools (NOT firebug) to the
Security tab. Click 123done's TOS or PP link. Look for the security
warning in the security pane of the dev tools.

I can think of two alternatives:

1) Require RPs that want to show TOS/PP agreements to do so using HTTPS.
2) Use browser sniffing to detect FF OS. If yes, use the IFRAME. If no,
open TOS/PP in new tab.

#1 limits the number of RPs that can do deep integration.
#2 has two problems. First, will FF OS have the same restriction on HTTP
iframes embedded in HTTPS content? Second, separate code paths that
possibly require a notification mechanism to let the RP know whether the
TOS/PP agreement is being shown as a tab or in an iframe.

Thoughts? Ideas? Ways around this? Friday looms.

Shane

===============

[1] - http://force-issuer.123done.org/

[Jared Hirsch]

This is indeed bummer city.

On Tue, Apr 30, 2013 at 2:13 PM, Shane Tomlinson <stoml...@mozilla.com> wrote:
>
> I can think of two alternatives:
>
> 1) Require RPs that want to show TOS/PP agreements to do so using HTTPS.
> 2) Use browser sniffing to detect FF OS. If yes, use the IFRAME. If no, open
> TOS/PP in new tab.

Hmm, for completeness:

3) Sites embed TOS/PP as a string in the page and we escape and render
the string ourselves?


Even though I just offered another answer, I think I'm most in favor
of (1), on the assumption that most RPs already bought an SSL cert for
their pre-Persona login page.

(2) sounds complicated--I wouldn't want to have to explain that to a
potential RP.

(3) is an option, but it'll weigh down every RP page with a big blob
of legal text. Cacheable separate endpoint seems better.

[Francois Marier]

On 01/05/13 09:13, Shane Tomlinson wrote:
> 1) Require RPs that want to show TOS/PP agreements to do so using HTTPS.
> 2) Use browser sniffing to detect FF OS. If yes, use the IFRAME. If no,
> open TOS/PP in new tab.
>
> #1 limits the number of RPs that can do deep integration.

That's true, however (maybe we have metrics for this?), how many sites
have a tos/pp and don't run over HTTPS?

If you let users log in and you're not on HTTPS, then your session
cookie can typically be stolen. Would these "low-value" sites that don't
bother with keeping sessions secure bother with having tos/pp?

Also, tos/pp can be hosted on another server, they're not limited to an
absolute path like siteLogo.

> #2 has two problems. First, will FF OS have the same restriction on HTTP
> iframes embedded in HTTPS content? Second, separate code paths that
> possibly require a notification mechanism to let the RP know whether the
> TOS/PP agreement is being shown as a tab or in an iframe.

Whether or not FxOS currently has these restrictions is interesting in
the short term, but it will eventually have them so I'd say we shouldn't
rely on mixed content working at all.

That would mean that RPs need to provide an HTTPS URL that doesn't
require JavaScript.

Francois

[Sean McArthur]

I'm in favor of #1, but wouldn't that be a breaking change to what
currently works? Would we even be able to make that switch so quickly (to
support Firefox OS)?

So as to not break HTTP URLs completely, maybe they could be still be
opened in a new tab (except that's not acceptable on Firefox OS)...

[Burak Yiğit Kaya]

I was thinking about getting a plain text version via CORS + XHR and
wondering if this would trigger a mixed content error and then I came by
this comment: http://code.google.com/p/chromium/issues/detail?id=115616#c10

It might be annoying but to make sure the site is legit, I think HTTPS
requirement make sense since TOS is usually binding right?

--BYK

On Tue, Apr 30, 2013 at 6:18 PM, Sean McArthur <smca...@mozilla.com>wrote:

> I'm in favor of #1, but wouldn't that be a breaking change to what
> currently works? Would we even be able to make that switch so quickly (to
> support Firefox OS)?
>
> So as to not break HTTP URLs completely, maybe they could be still be
> opened in a new tab (except that's not acceptable on Firefox OS)...
>
>
> On Tue, Apr 30, 2013 at 6:14 PM, Francois Marier <fran...@mozilla.com
> >wrote:
>

[Shane Tomlinson]

On 30/04/2013 23:57, Jared Hirsch wrote:

> Hmm, for completeness:
>
> 3) Sites embed TOS/PP as a string in the page and we escape and render
> the string ourselves?
>

Jared, you brought up another option yesterday that is worth discussion
- setting up an https proxy and route all TOS/PP HTTP requests through
that. Brian Warner explained security repercussions of doing this long
ago for siteLogo, I forget all of the nuances that must be considered.

Burak, you mentioned using CORS, which is another viable alternative
although we would have to get RPs to serve their TOS/PP agreements with
Access-Control-Allow-Origin headers. My gut feeling is this will cause
problems for the same subset of RPs that are http only.

As an aside - would it be worthwhile tracking which options RPs are
using and whether their page is http? We are having this discussion
because we do not know how many RPs are both http only and using the
TOS/PP options. If we were able to look at data and see that only an
extremely small number of sites would be affected, the decision would be
easier.

Thanks for all the ideas everyone! It's awesome to see people chime in
when in a bind.

Shane

[Ryan Hurst]

Coming to this thread late, one of the problems we have ran into while
integrating other authentication modalities into Persona is the inability
to present meaningful user experience for the associated error conditions;
for example someone chooses to log on with us...@domain.com but presents a
certificate bound to us...@example.com. Would the changes discussed here
help with that problem?

> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Burak Yiğit Kaya]

On Wed, May 1, 2013 at 1:55 AM, Shane Tomlinson <stoml...@mozilla.com>wrote:

> Burak, you mentioned using CORS, which is another viable alternative
> although we would have to get RPs to serve their TOS/PP agreements with
> Access-Control-Allow-Origin headers. My gut feeling is this will cause
> problems for the same subset of RPs that are http only.

I agree that this *may* cause some implementation backlash, I think it will
be a lot less than https enforcement. HTTPS is still expensive(yeah stupid)
and having a "proper" https setup is not very trivial: you have to have
certificate and all that jazz. With CORS, though, you simply add headers.

Using a proxy sounds a bit creepy to me to be honest.

Another option might be RP's sending this information (like the actual TOS)
using postMessage. Since postMessage has the notion of "origin"s, it can
easily verify the source. How about that?

--BYK

[Sean McArthur]

On Sun, May 5, 2013 at 3:26 PM, Burak Yiğit Kaya <b...@byk.im> wrote:

> Another option might be RP's sending this information (like the actual TOS)
> using postMessage. Since postMessage has the notion of "origin"s, it can
> easily verify the source. How about that?
>

This involves sending all the bytes of them super lengthy TOS and Privacy
Policies, all full of legalese, across the wire for *every* single login
attempt, as opposed to before where they are only downloaded if the user
wants to see them.

[Francois Marier]

And it would mean that we have to be extra-careful about sanitizing it
because we'd be serving it from our own domain (i.e. we wouldn't benefit
from browsers' cross-origin filtering).

Francois

[Burak Yiğit Kaya]

I think you got me wrong. postMessage is cross-frame communication, it is
not over the wire?

And for sanitation, you can enforce "text only dude" and then use
document.createTextNode and boom? Not sure what you mean by cross-origin
filtering though.

--BYK

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Francois Marier]

On 10/05/13 16:53, Burak Yiğit Kaya wrote:
> And for sanitation, you can enforce "text only dude" and then use
> document.createTextNode and boom?

If we were to restrict things to plain UTF-8 text (no formatting), I'm
not sure everyone would be happy. These long contract-like documents
often have headings and some light formatting.

> Not sure what you mean by cross-origin filtering though.

If you include content from another domain into your own page (e.g. an
image from a different domain), the browser enforces a number of
restrictions specific to the content that's being pulled in. Basically,
the assumption is that the 3rd-party content will be hostile, so some
filtering / restrictions are necessary.

Francois

[Burak Yiğit Kaya]

On Sun, May 12, 2013 at 5:41 PM, Francois Marier <fran...@mozilla.com>wrote:

> If you include content from another domain into your own page (e.g. an
> image from a different domain), the browser enforces a number of
> restrictions specific to the content that's being pulled in. Basically,
> the assumption is that the 3rd-party content will be hostile, so some
> filtering / restrictions are necessary.
>

Well now I see your point but again, if it's text only, then you don't have
this problem since text doesn't do anything.

For formatting, I would say they have much formatting but I can see that
becoming a problem in the future. Not sure if it would be a bigger problem
than "https or nothing" though.

--BYK