WebOS
implements a very simple permission system that is not nearly as
expressive as the system on Android or BlackBerry. As explained earlier
in the WebOS architecture discussion, WebOS places an application into
one of two buckets: com.palm.* or everything else. The com.palm.*
applications can access the private bus and relatively unrestricted
service interfaces. Using these APIs, com.palm.* applications can access
and control much of the phone’s functionality, including gaining
unrestricted access to e-mail.
Third-party applications are
restricted to using the public Service APIs. This set of APIs only
exposes functionality that most users would deem as acceptable. For
example, applications may launch the phone dialer application with a
prepopulated number, but the user must press the dial button before a
phone call can be made. These pauses in behaviors interject decision
points where users can make security decisions without realizing they
are. Additionally, applications cannot read e-mail or message data from
the internal messaging stores using the e-mail Service APIs.
Storage
WebOS developers have a myriad
of storage options to choose from, including structured Depot storage,
HTML 5 databases, JSON Cookie objects, and files (using the File Picker
UI). Each of these options has its own peculiarities.
Cookie Objects
The
most basic form of WebOS storage objects are cookie objects. These
objects should be used for storing small amounts of data. User
application preferences or browser favorites are good examples of
potential cookie data. Palm recommends a maximum of 4KB per cookie, but
this is not a hard-and-fast limit. Only the application that created a
cookie is allowed to read the cookie’s data. For this reason, cookies
are recommended for per-application data storage of small amounts of
data. Interestingly, Luna enforces this restriction using a method
similar to how desktop WebKit isolates cookies between websites. When
the cookie object is created, Luna generates a fake domain name that
will be unique to the application. This domain is stored along with the
cookie in the application cookie database. When applications attempt to
load the cookie, their domain name is checked against the database
before the cookie is returned. Any requests for cookies not belonging to
the application are rejected. Use the Mojo.Model.Cookie interface to
create cookies.
Depots
Depots are structured
storage used for storing JavaScript objects as key/value pairs. The
simple Depot interface consists of simple key/value put methods. Luna
enforces Depot security by partitioning Depots per application. The
Depot receives a unique name generated from the application identifier,
and this name is used regardless of the name the application uses to
refer to the Depot. In this way, Depots are very similar to Cookie
objects. Smaller Depots that are less than 1MB in size can be stored
within the application’s directory. Depots larger than 1MB must be
stored within the file system’s media partition. To force a Depot to the
media partition, specify the keyword “ext” as part of the Depot’s name,
as shown here:
var isec_depot = new Mojo.Depot({name:"ext:iSEC"}, onSuccess, onFailure);
Do not store Depots containing
sensitive data on the media partition unless absolutely necessary
because this partition becomes browsable when the device is connected to
a PC (http://developer.palm.com/index.php?option=com_content&view=article&id=1734).
Depots
are currently built on top of HTML 5 databases, but this is an
implementation detail and may change in the future. Create Depot objects
using the Mojo.Depot() API.
HTML 5 Databases
WebOS includes full support
for HTML 5 Database objects. Like their server brethren, these databases
have tables and are queried using the SQL query language. Like Depots
and Cookie objects, databases are unique per application. To create a
database, use the openDatabase() method. To query a database, use the
executeSQL() method.
WebOS applications using
databases need to be careful to avoid SQL injection, a common web
application vulnerability. Similar to script injection, this
vulnerability results from inserting unescaped user data directly into
queries. Depending on the application, this may allow malware to corrupt
the application’s database or steal sensitive data. The risk on WebOS
is smaller than the risk to web applications because databases are
per-application and there aren’t different authentication stages.
Even though the risk is
less, it is worth preventing SQL injection by using parameterized
queries and never building SQL queries using string concatenation.
Parameterized queries are created by using the “?” placeholder instead
of the actual value when authoring the query. The parameter’s value is
then provided in a separate argument array. Because the query and the
data are provided separately, the database engine does not become
confused and accidentally interpret the user data as part of the
queries’ executable portion. Here’s an example:
transaction.executeSql('SELECT * FROM Vulnerabilities WHERE Id = ?',
[ vuln_id ],
onSuccess,
onError);
In this example, we are
selecting entries from the Vulnerabilities table that have the ID
matching the vuln_id argument. An arbitrary number of parameters and
values may be specified for any query. To prevent SQL injection, always
use parameterized queries.
File Storage
WebOS devices have
internal storage for storing documents, media files, and other large
data. Developers do not have access to file APIs for reading and writing
data, but they can invoke the FilePicker control, which will present
users with a list of files to choose from. The chosen filename will then
be returned to the user. Application developers can then launch a viewer for the file using the ApplicationManager’s “launch” action.
Networking
Applications are able to
connect to other servers using the XmlHTTPRequest object and receive
push notifications using the Palm messaging service. Applications are
not allowed to use raw TCP sockets directly. XmlHTTPRequest behaves
exactly the same as standard XmlHTTPRequest objects, except the Same
Origin Policy is not applied. Applications can make HTTP requests to any
site, port, and scheme.
The Palm messaging service
is an Extensible Messaging and Presence Protocol (XMPP) service that is
still in development. When completed, it will allow applications to
register for and receive push notifications of events. An example of an
event might be an updated time for a flight or the latest sports scores.
The security architecture of the messaging system will have to be
explored in more depth once it is finalized.