Task-specific API subsets

[Gervase Markham]

This may be a really dumb idea, but...

At the moment, we have APIs which are too powerful to expose to the web
- e.g. TCPSocket.

Can we make libraries which restrict those APIs to a safer task-specific
subset, and which can then be signed, but which an unsigned app or
website can use without prompting?

So, for example, we make an IMAP library that uses TCPSocket, and only
speaks IMAP on IMAP ports, and exposes a high-level interface which does
not allow arbitrary packet manipulation. We then sign that, and
henceforth anyone can build an IMAP-using webapp which doesn't need
TCPSocket permission or to be signed - it just includes the signed library.

You can imagine the extension of this idea to different types of API.

Does this solve any problems at all, or am I on crack?

Gerv

[Anne van Kesteren]

On Tue, May 5, 2015 at 11:43 AM, Gervase Markham <ge...@mozilla.org> wrote:
> Does this solve any problems at all, or am I on crack?

Not allowing a website to initiate IMAP within the realm of a user's a
firewall is in fact one of the things we're protecting against by not
allowing TCPSocket. Anything that goes beyond
https://annevankesteren.nl/2015/02/same-origin-policy is a problem,
basically.


--
https://annevankesteren.nl/

[Gervase Markham]

On 05/05/15 11:01, Anne van Kesteren wrote:
> Not allowing a website to initiate IMAP within the realm of a user's a
> firewall is in fact one of the things we're protecting against by not
> allowing TCPSocket. Anything that goes beyond
> https://annevankesteren.nl/2015/02/same-origin-policy is a problem,
> basically.

Couldn't the library check its own origin, and only allow connections
back to it? Or is it hard to build a secure way for it to get that
information?

Gerv

[Frederik Braun]

On 05.05.2015 12:08, Gervase Markham wrote:
> On 05/05/15 11:01, Anne van Kesteren wrote:

>> Not allowing a website to initiate IMAP within the realm of a user's a
>> firewall is in fact one of the things we're protecting against by not
>> allowing TCPSocket. Anything that goes beyond
>> https://annevankesteren.nl/2015/02/same-origin-policy is a problem,
>> basically.
>

> Couldn't the library check its own origin, and only allow connections
> back to it? Or is it hard to build a secure way for it to get that
> information?
>

The origin is the set of URL scheme (i.e. http), domain (e.g.
example.com) and port (80). What you want to compare is not the origin,
but the domain or eTLD+1, right?

The answer is still the same, though. Me publishing a webiste somewhere
(e.g. freddyb.github.io) currently does not imply access to other ports
of this host. This is a crucial part of web security and I'm afraid that
we may not single-handedly revoke this promise without breaking the web.

On a side-note, I think that high-level permissions like the one you
promised are part of the solution. Their capabilities may be shaped
differently to what you proposed here, but with a specific use case in
mind, it may be easier to prompt the user without too much technical jargon.

[Anne van Kesteren]

On Tue, May 5, 2015 at 12:08 PM, Gervase Markham <ge...@mozilla.org> wrote:
> Couldn't the library check its own origin, and only allow connections
> back to it? Or is it hard to build a secure way for it to get that
> information?

But then we're not really solving the use cases for generic IMAP. You
might as well host a WebSocket-to-IMAP proxy on your origin in that
case.


--
https://annevankesteren.nl/

[Jonas Sicking]

On Tue, May 5, 2015 at 3:08 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 05/05/15 11:01, Anne van Kesteren wrote:

>> Not allowing a website to initiate IMAP within the realm of a user's a
>> firewall is in fact one of the things we're protecting against by not
>> allowing TCPSocket. Anything that goes beyond
>> https://annevankesteren.nl/2015/02/same-origin-policy is a problem,
>> basically.
>

> Couldn't the library check its own origin, and only allow connections
> back to it? Or is it hard to build a secure way for it to get that
> information?

But then the email website would only be able to connect to a single
email server. I.e. the server run by the app developers. That doesn't
sound like an email website.

But if that's all that you want to accomplish, you could simply use
WebSocket since it's easy enough for the web developers to write a
tiny library which proxies WebSocket messages to the email server
hosted by the web developer.

/ Jonas

[Jonas Sicking]

On Tue, May 5, 2015 at 2:43 AM, Gervase Markham <ge...@mozilla.org> wrote:
> So, for example, we make an IMAP library that uses TCPSocket, and only
> speaks IMAP on IMAP ports, and exposes a high-level interface which does
> not allow arbitrary packet manipulation. We then sign that, and
> henceforth anyone can build an IMAP-using webapp which doesn't need
> TCPSocket permission or to be signed - it just includes the signed library.

IMAP is a good example.

The problem is that even if we did what you propose above, it would
still have security problems. Say that a user, Adam, who works at
Bankers'r'Us, goes to the website evil.com. At this point, evil.com
could include the IMAP library and then connect to any IMAP server
inside Bankers'r'Us corporate firewall. And of course it's quite easy
to trick Adam to visit evil.com by simply emailing Adam a link to
evil.com.

This could be improved by making the library display a dialog to Adam
which asks "Do you want to allow evil.com to connect to the mail
server at corp.mail.intranet?". That results in a somewhat unpleasant
UX, but it might be ok.

But at this point that IMAP library has now become more of a web
platform API, and less of a plain JS library. So why not just
introduce a IMAP API? After all, we'd need to do as thorough audit of
that IMAP JS library, as we'd do on the Gecko-implemented IMAP API.
And given that we support implementing Gecko APIs in JS, it wouldn't
necessarily even be faster to write the JS library.

One argument could be that adding a never ending list of APIs to gecko
will result in Gecko eventually growing crazy large. We'd also end up
with a very large body of libraries that we need to continuously fix
security bugs in.

/ Jonas

[Gervase Markham]

On 05/05/15 21:13, Jonas Sicking wrote:
> The problem is that even if we did what you propose above, it would
> still have security problems. Say that a user, Adam, who works at
> Bankers'r'Us, goes to the website evil.com. At this point, evil.com
> could include the IMAP library and then connect to any IMAP server
> inside Bankers'r'Us corporate firewall.

I see. The problem is the bit in Anne's post where he explains that it's
not possible for the browser to know which hosts are internal and which
hosts are not. That is frustrating.

evil.com wouldn't get far on that IMAP server without IMAP login
credentials; making accesses in new contexts credentialless might help,
but wouldn't solve the entire problem. Some sensitive content inside
firewalls is credentialless.

We can't even check that the domain name is a public one (on the PSL)
because some sites use publicly-rooted names for their internal machines.

> But at this point that IMAP library has now become more of a web
> platform API, and less of a plain JS library. So why not just
> introduce a IMAP API? After all, we'd need to do as thorough audit of
> that IMAP JS library, as we'd do on the Gecko-implemented IMAP API.

Would we? Or would we only need to audit the part which made sure the
library wasn't able to make arbitrary TCP connections?

In a sense, I guess perhaps what I'm suggesting (for TCPSocket at least)
is a set of signed firewall rules that only permit safe connections for
a particular application - if that's even possible - because then, the
request message can be much better than "Do you want foo.com to be able
to use TCPSocket", which no-one understands. It could be "Do you want
foo.com to be able to access the IMAP mail server at bar.com", which is
much more understandable.

Gerv

[Anne van Kesteren]

On Wed, May 6, 2015 at 10:41 AM, Gervase Markham <ge...@mozilla.org> wrote:
> I see. The problem is the bit in Anne's post where he explains that it's
> not possible for the browser to know which hosts are internal and which
> hosts are not. That is frustrating.
>
> evil.com wouldn't get far on that IMAP server without IMAP login
> credentials; making accesses in new contexts credentialless might help,
> but wouldn't solve the entire problem. Some sensitive content inside
> firewalls is credentialless.
>
> We can't even check that the domain name is a public one (on the PSL)
> because some sites use publicly-rooted names for their internal machines.

Indeed, see

https://annevankesteren.nl/2015/03/public-internet-proxy

for a summary of earlier deliberations from some Mozillians on this topic.


--
https://annevankesteren.nl/