Fwd: Initial input for discussion of Widget security model

Just a refresher. Arve's security proposal.


---------- Forwarded message ----------
From: Arve Bersvendsen <arveb@opera.com>
Date: Thu, May 1, 2008 at 1:33 AM
Subject: Initial input for discussion of Widget security model
To: public-appformats@w3.org


Attached is a document providing some initial input on a security
model for a widget, that should provide a rough draft for providing
the/a widget security model.

Note that the document is not to be treated as input for specification
text, and it needs substantial work and review before any such thing
can take place.

My hope is that we can take this document up for discussion at the F2F
in Dublin.

---
Widget security
Introduction

This document defines a security model for widgets, specifying which
resources the widget is allowed and denied access to, and how the
widget can signal which resources it intends to access.

It is assumed that widgets are not web pages and that in order to be
useful they need a security model that is different from that of web
pages.

Conceptually speaking a widget is "loaded" onto a computer before it
is "run", and so its home domain is the computer on which it is
running. In addition, many useful widgets accomplish their task by
synthesizing information from various sources on the web. Thus the
widget needs greater rights than normal web pages in order to access
network resources. Yet the security concerns of unrestricted access
cannot be ignored: The main concern is that a widget that accesses
pages on an intranet can steal information, but there is also a
general concern about leaking information about the widget user from
one web site to another.

This document specifies what widgets are normally allowed to do, how
they can be granted greater privileges, and how their privileges can
be curtailed. Actions are controlled by reasonable defaults, with
overrides from the user or system administrator, and checked against
the behavior the widget declares itself to have.

A widget's config.xml file may contain a "security specification": a
declaration of the protocols, hosts, ports, and pages that the widget
will normally attempt to access. It may also contain declarations of
other things that the widget will do.

The security specification is represented as the "security" element in
the config.xml file. Additional local settings for widgets are
specific to the system.

This specification does not concern itself directly with signing, but
an implementation of signatures may use different policy documents
based on the identity provided by a signature, thus granting different
privileges based on said signature.
Widget lifecycle and identity

Latent widgets are identified by URLs that reference zip files on
hosts on the Internet. (They can also be identified by a path in the
file system to a config.xml file.) A widget is loaded into the user
agent by loading the URL of the zip or config.xml file.

Once the zip file is loaded, a running widget instance will normally
be created in a vendor-specific manner.

The widget runner may be suspended, and running widget instances are
suspended with it. Only when the user explicitly kills the instance
are it's data deleted.

The widget instance is unique in the universe. There is no notion at
all of two widget instances being "the same". No information in the
config.xml file or in the URL from which the zip file is loaded has
any bearing on widget identity.
Widget updates

Note that while upgrades is not directly covered in this
specification, any future upgrade mechanism should display a
warning/confirmation prior to upgrading. If the security settings of
the widget will change during such an upgrade process, and in such a
way that the network privileges change, or the widget asks for
additional APIs to be enabled, such a warning should be displayed,
with an option to inspect the new security settings.
Browser/Widget runner state

Separate widget instances share no information at all. Specifically:

    * A cookie set by a widget instance, or by a URL loaded by a
widget (eg through XmlHttpRequest) is visible only to that widget
instance, never to any other instances or to documents loaded into the
browser in any other way.
    * If a URL loaded by a widget requires HTTP authentication then
authentication must be performed on behalf of that widget instance;
the authentication is not shared with other widget instances or with
URLs loaded into the browser in any other way.
    * A set of settings for a widget instance is shared with no other
widget instances.
    * Other persistent storage mechanisms, such as those defined in
HTML must not share data with other widget instances, or with the
storage context in the web browser.
    * When a widget is running as part of a web browser, cache files,
indexes, or other data must not be shared with the web browser

Network access model
Scope

The access rights model determines whether a widget should be allowed
to access any particular URL, where "access" means the following:

    * Access through opening a URL in an external resource, such as a
web browser, by means of a link with an appropriate target, a call to
widget.openURL or similar mechanisms where the widget is opened in a
viewer outside the control of the widget runner.
    * Access through loading an embedded document or object inside the
widget, such as an image, iframe, object, svg:foreignObject and
similar.
    * Access to external windows happening under control resources
happening from a child window of the widget.

The rules for accessing the network are determined based on the
following components:

    * The widget's declaration of network intent.
    * The widget runner's declaration of global allowable network
policy, either through fixed configuration or through profile
configuration. This policy declaration may be either fixed, or vary
based on widget origin or identity.

Network classes

This specification describes two classes of networks, a default
"private" network, and a public network.

A private network, or local network is by default defined as the
user's local machine, including any IP address that resolves to the
local machine. Further, the IP ranges as defined by [RFC 1918], are
considered to be private. These addresses are primarily being used in
systems set up behind a NAT translation device, and provides machines
with unique addresses where there is only one public IP address for
several machines. These addresses are:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

In addition, when a user is within an ad-hoc network, networking
equipment (including software components in operating systems),
typically use the IPv4 Link-Local addresses as defined by [RFC 3927],
which is also considered to be part of the local network.

    169.254.0.0     -    169.254.255.255 (169.254/16 prefix)

A widget runner should provide a default configuration wherein the
four network ranges described above are defined to fall within the
private IP range. As stated above, this policy may be editable, may be
possible to add or remove items to the list of private networks and
hosts.
Widget network access configuration through config.xml

When a widget wants to request access to resources, it does so by
adding a security fragment to the config.xml element, as specified
below:

  element security optional
    element access multiple
      element "protocol" multiple
        cdata
      element "host" multiple
        cdata
      element "port" multiple
        cdata
      element "path" multiple
        cdata
    element "content"
      attribute "plugin" value = "yes|no"

Configuration document elements
The access element

The access element is used to specify the access permissions of the
widget. The element. If the contents of the access element is empty,
then a widget would not be granted access. With the exception of the
'protocol' element, the absence of an element means the same as "match
all", granting access to all resources not limiting access.
The host element

The host element is a syntactical construct used to determine which
hosts a widget can contact. The element is defined as such

    element host
        attribute type optional value="localhost|string|range"
        cdata

The type attribute determines which kind of matching is done for the
host element:

localhost
    When the value of the type attribute is specified as 'localhost',
this refers to accessing the user's local machine, regardless of which
method of access is chosen -- hostname, or one of the IP addresses
that resolves to the user's local machine. In the case that localhost
is specified, the cdata in the element is disregarded for comparison
purposes
string
    In the case the value of the type attribute is 'string', the cdata
within the element is regarded as a string match for the hostname,
including an optional leading wildcard.
range
    When the value of the type attribute is 'range', the contents
inside the element is expected to be an IP address, or a range of IP
addresses separated by a single '-'.

If the 'type' attribute is omitted from any declaration, it is assumed
to be present, with the value 'string'

    * When a 'host' element is missing from an access element,
regardless of in which file this element occurs, the element is
assumed to be present, as a single wildcard value: <host>*</host>
    * When present, the default wildcard element is replaced with the
exact value of any matching host elements.

The 'protocol' element

The protocol element is used to determine which protocols a widget
should have access to. When missing from config.xml, the element is
assumed to be present three times, with the values 'widget', 'http'
and 'https'. When missing from any other context, the element gets no
value, and for instance if missing from 'access', a widget would not
be allowed to get network access.
The 'port' element

The port element is used to define which port numbers a widget should
have access to when initiating network traffic. The port element
accepts as its value a single port number, port numbers separated by a
comma, or a range of ports separated using '-'.

When missing from an 'access' element, the port element is assumed to
be present, matching all ports, and when a widget requests access to a
resource using http, it can do so on every port. It should however be
noted that there are certain port numbers for which the User Agent may
have disabled access for security reasons, and a configuration
override cannot change these.

When a different port number is specified for a protocol in an access
element, the port numbers specified are the only by which a widget can
communicate.
The 'path' element

The path element is used to restrict widget access to particular paths
within the rule sets. When missing from anywhere within widget
configuration, or policy file, the element is assumed to be present,
allowing access to any path, thus implicitly bearing the value "/".

The path is treated as a wildcard path, allowing access to any
matching subpath of the element. In the following access fragment,
placed within config.xml, access to any resource contained within the
"/cats" subpath is allowed:

    <path>/cats</path>

thus, the widget can access all of

    /cats/siamese.html
    /cats/
    /catsoup

In the case that the author of the config.xml fragment meant to limit
access to '/cats/', the specification of the path would have to
include the forward slash:

    <path>/cats/</path>

Enabling network access

A widget must declare its intention with regard to API and network
access through the config.xml file, using the syntax described in the
below config.xml fragment:

  element widget
    attribute "network" optional value = "public|&private"

To acquire access to the network, the widget must thus declare this by
adding the network attribute to the widget element in the widget's
config.xml file. The value accepted for this attribute is a list of
DOMStrings that can specify which network class it intends to access.
The values are case sensitive. Valid values are:

It is assumed that a security mechanism exists in the widget user
agent to enforce a policy where a separation between the two network
classes exist, and optionally lock access to either of the resources
after first access has taken place, so that a widget that has for
instance accessed the public network can no longer access the private
network.

private
    Governs any network the user has classified as a private network
in configuration. This might be predefined as for instance being the
four private IP ranges as defined by RFC 1918 and RFC 3927
public
    Governs any network NOT classified as private.

When a widget starts, The user agent reads this configuration, and
compares it to the User Agent's internal configuration.
URL Access rights
Scope

The term 'URL access' specifies any access to a networked resource a
widget may attempt. This includes:

    * The widget directly requesting a resource through inclusion
(such as iframes, objects and other elements)
    * The widget including images, stylesheets, and scripts. Including
indirectly, when a stylesheet or (SVG) image requests additional
resources to be loaded.
    * The widget attempting to open a resource in an external
application (in effect, using links or widget.openURL)
    * Resources contacted by API access: DOM3 Load/Save,
XMLHttpRequest and similar
    * The destination of form elements
    * When the UA includes resources in iframes and similar, any
access made by documents contained in these included documents.

Failure modes

If a widget, by configuration, excplicitly requires access to a
resource forbidden by other configuration, installation of the widget
should fail.

If a widget attempts to contact a resource that is in conflict with
the widget's own stated security policy, or the widget attempts to
contact a resource which it has been restricted from accessing (such
as accessing a private network resource when it has only requested
access to public network resources), it should fail in one of two
ways:

   1. If the access happens through direct access, such as opening
URLs using link constructs, form submissions, or similar methods, the
action should fail silently.
   2. If the access happens through API access, such as
XMLHttpRequest, the action should generally fail with a security
violation error in the same manner a web page that tries to do
cross-domain requests would.

Processing model for allowing network access

The algorithm for allowing access to the private network is as such:

   1. If the widget has added 'private' to the network attribute,
continue. Otherwise, deny access.
   2. If a system fixed configuration allows access, continue.
Otherwise, deny access.
   3. If a profile configuration on the device allows access,
continue. Otherwise, deny access.
   4. If a per-widget override configuration allows access, continue.
Otherwise, deny access.

The same algorithm is also applied separately to the public network.

When the widget requests access to both types of network, apply the
following algorithm

   1. If the widget requires access to both network classes, continue.
   2. If a system fixed configuration allows simultaneous access to
both network classes, continue. Otherwise deny access.
   3. If a profile configuration directive allows simultaneous access
to both network classes, continue. Otherwise, deny access.
   4. If a per-widget override configuration allows access, continue.
Otherwise, deny access.

In the case that any step in the above processes has resulted in "Deny
access", deny access. Otherwise allow access.
URL-based access check

When a widget attempts to contact a resource, and this resource has
been allowed by the network class above, the URL that is attempted
accessed is compared to a whitelist and/or a blacklist on the system,
that contains a componentized list of URLs.:

   1. Take the request URL string, componentize it.
   2. Compare the components of the request URL to that of the widget
config.xml's access element.
   3. Assume that the browser also has a black and whitelist which the
url can match. If the URL matches the whitelist, allow it. If the URL
matches the blacklist, deny it.

A leap of faith is required to understand how this works, but the
general idea is that domains have to match, while separate subdomains
want. Assume that the black/whitelists support wildcards. Assume that
the same lists supports both IP ranges and port ranges.
Form and Links Behaviour

    * A form element should have a valid target.
    * If the form has a reserved target, and this target leads to
intrisically replacing the topmost document in the widget, in effect
replacing the widget, submitting the form should fail silently.
    * If the form uses the '_blank' target for a GET request, the form
should be submitted to an external application.
    * POST requests that result in submission to an external viewer SHOULD fail.
    * The URL provided by the form's action attribute MUST be
permitted by the computed security policy for the widget.
    * Links must have default "_blank" target, and open in an external
viewer. The URL referenced MUST be permitted by the computed security
policy for the widget.

Embedded Objects Security

    * Objects must adhere to widget security policy.
    * Objects must not cross network boundaries when loaded.
    * Objects may share cookies and cache with widgets.
    * Objects must not share cookies and cache with browser.
    * Objects must not be aware of widget's existence.
    * There should be no reference to window.opener (the widget
shouldnt be visible to the object)
    * window.top should point to the embedding frame only.
    * Widgets may have a one-way reference to inject scripts, read
DOM, etc. The reference must be strictly one way and initiated from
the widget only.





--
Arve Bersvendsen

Developer, Opera Software ASA, http://www.opera.com/


-- 
Marcos Caceres
http://datadriven.com.au