Permission Systems across APIs

The following comment contains information about a general observation,
identified during a recent security analysis of 13 W3C standards,
organized by ENISA (European Network and Information Security Agency),
and performed by the DistriNet Research Group (K.U. Leuven, Belgium).

The complete report is available at http://www.enisa.europa.eu/html5
(*), and contains information about the process, the discovered
vulnerabilities and recommendations towards improving overall security
in the studied specifications.



The security analysis of multiple specs shows that permission systems
are very inconsistent or incomplete across the specifications. The
specifications suffer from a number of problems, which will be addressed
below.

* Permission System Design

Several specifications include a permission system, without any
consistency between these systems. This is troublesome, since some
systems are fairly weak compared to other systems. One good example is
the Geo-location API versus the System Information API, where the latter
is much more extended (e.g. it requires permission for a pair of origins
for a framed document and distinguishes between one-host vs. monitoring
permissions).

Our recommendation is to co-ordinate these permission systems across
specifications. This would enable a strong permissions system for all
involved APIs and makes it less complicated for browser vendors.
Optionally, a separate permission specification, which describes how
permission systems should work across all the specifications, can be
created. The specification should describe the necessary types of
permissions (e.g. persistent vs one-time, one-shot permission vs a
watching process, ...) and what they are based on. The specifications
describing the APIs can then reference the permission specification with
a certain type of permission, and require the implementation of that
permission system. This brings consistency across all permission systems
and decouples improvements to permission systems from functionality
developments. Recent work on Feature Permissions
[http://dev.w3.org/2009/dap/perms/FeaturePermissions.html] already
points in this direction, but does not yet cover all aspects raised in
this analysis.

Additionally, it might be useful to investigate potential conflicts of
the permission systems with underlying security controls (e.g. on a
smartphone device). Integration of API permissions systems and
underlying security controls not only avoids potential conflicts between
systems, but can also be useful in delivering an integrated and
consistent experience to the end user. 

* User Interfaces

The specifications do not include much detail about the user interfaces
for giving permissions and managing permissions. Typically, they require
that the origin of the document is displayed. One major missing item is
the nature of the permission (one-shot vs watching process) as well as
the actual document requesting it (e.g. is it sandboxed or framed? is it
visible?). For managing permissions, the specifications typically state
that it should be clear and easily usable. This is very vague and is not
even a strong requirement (should instead of must). Evidence of this are
the current permission management interfaces, which are not always
intuitive or clear.

Our recommendation is to extend the specifications to include more UI
requirements. At least all the aspects of the requested permission
should be present. For managing the permissions, the specifications
should describe how it should happen (not what it should look like). For
example, they could state that "A user must be able to get an overview
of all assigned permissions, grouped per origin".

Optionally, these UI requirements can be included into the
abovementioned separate permission specification, which is then
referenced from all other specifications requiring a permission system.
This ensures consistency and facilitates improvements or extensions of
the permission system. 


(*) HTML version of the report is available as well:
https://distrinet.cs.kuleuven.be/projects/HTML5-security/
-- 
Philippe De Ryck
K.U.Leuven, Dept. of Computer Science


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Wednesday, 3 August 2011 17:49:16 UTC