KUER: A Security Model for Web Applications

Qiang Wang, Zhiguang Qin

School of Computer Science and Engineering
University of Electronic Science and Technology of China, Chengdu, China
{ wangq,qinzg}@uestc.edu.cn
Abstract-Web Applications have changed signifcantly since
the World Wide Web was introduced, facing a shif in web
content from simple hyperlinked documents to active programs.
However, the prevailing web protection model, the same origin
policy, is an imperfect approach to identify web applications and
govern their behavior. As a result, web applications have become
attractive targets of exploitation, especially web plug-ins. In this
paper, we present KUBER, a new web browser security model
that adapts lessons from OS to make the browser a more suitable
platform for web applications. Using system call interposition,
KUBER is responsible for uniformly specifying and enforcing
security policies on not just HTML and JavaScript, but plug-in
media and browser extensions as well. We describe our
implementation of a prototype of KUBER, and illustrate how
browsers can use KUBER for securing their resources.
I. INTRODUCTION
W
EB browser plu
.
g-ins have become
.
a doinated tool on
the World Wide Web for mUSIC, Videos and rich
applications; for example, Flash player is behind what makes
YouTube work, 99.3 percent of all Interet desktop users have
the Flash Player installed[ 1]. In some sense, the introduction
of feature-rich plug-ins make the web browser act like an
operating system and provides runtime environments for
programs that demand device access, network support, and
local fle access.
However, plug-ins violate the same-origin police (SOP)
and cause enormous security risks. Plug-ins are the largest
source of vulnerabilities in browsers today. The security
models implemented by these plug-ins generally diverge fom
the models of the browser. Each plug-in enforces and defnes
its own security policy. An attacker can compromise the
whole system once he exploits a plug-in.
Researchers have been studying browser features related to
the plug-in security. To isolate exploited plug-ins, browser
such as Chrome[2], OP[3], and Gazelle[4] place plug-ins in a
separate process. OP and Gazelle impose unacceptable
limitations on plug-ins, which make them difcult to deploy in
reality. Chrome uses one instance of Flash for the entire
browser, any vulnerability in Flash can jeopardizes the whole
system. ESCUDO[5] uses hierarchical protection rings(HPR)
to meet the protection requirements of web applications, but
ESCUDO needs server-side change, Non-ESCUDO
applications can't be protected.
In this paper, we aim to design and build an interposition
layer and sufcient restrictions on browser plug-in by
sandboxing [6-8] existing plug-ins like Flash and Silverlight.
This would allow interposition on their call to both the
operating system and browser APIs.
The rest of the paper is organized as follows: In Section II
we describe problems that web browsers face. We discuss the
design of KUBERA and give the architecture of KUBERA in
Section III. In Section IV we give our performance evaluation
of KUBERA, and conclude in Section V.
II. PROBLEMS
A. Web Browser Plug-in
Unlike natively supported document formats, the landscape
of web browser plug-ins displays a growing trend towards
variety. Most of the plug-ins are invoked by using <OBJECT>
or <EMBED> tags (or <APPLET>, for Java). Common
document-embeddable plug-ins can be divided into four
primary categories[9]:
1) Programmable plug-in. This includes technologies such
as Adobe Flash, Java, and Microsof Silverlight, together
present at a vast majority of desktop computers.
2) Embedded non-HTML document formats. Such as
Acrobat Reader Add-in and Microsof Ofce Add-in.
3) Specialized HTML-integrated markup languages. It
refers to specialized markup languages such as VRML,
VML, or MathML,
4) Rich multimedia plug-in. Such as includes Windows
Media Player, QuickTime, RealPlayer, and VLC.
B. The Same Origin Polic
The same origin policy (SOP) [ J O]in web browsers
identifes a web object's origin as a unique combination of
<protocol, domain name, port>. By web object, we mean
HTTP cookies, HTML documents, images, Javascript, etc.
Browsers consider two objects to have the same origin if
protocol, domain name, and port are the same for both web
objects. For instance, http://www.example.com/index.php and
http://www.example.comJlogin.php belong to the same origin,
but ht://www.example.com/index.php and
http://www.google.comJindex.php do not belong to the same
origin because they have different domains. Similarly,
htp://www.google.com and https://www.google.com do not
have the same origin because they use different protocols.
978-1-4244-8223-8/10/$26.00 2010 IEEE 274
C The SOP is Inadequate for Plug-in Safet
All modem web browsers implement the same origin police.
However, this model has not adequately evolved to manage
the security consequences of the additional complexity in
modem web pages. The imperfect SOP is a major cause of
web exploit. Because a page can change its origin at runtime,
most web exploits are relevant to SOP breach. In a way, attack
will be successfl as long as attackers breach the SOP. For
example, XSS(Cross-site scripting) and CSRF(Cross-site
request forgery) are essentially violation of the same origin
policy. Moreover, DNS rebinding[ll] or server-side proxies,
permit the host name check to be partly subverted, and make it
possible for rogue web pages to directly interact with sites
through addresses other than their "true", canonical origin.
Other plug-ins, such as the Java Runtime, Flash and
Silverlight each have their own policy for restricting network
access and fle access. These policies ofen differ fom the
browser's same-origin limitations on JavaScript.
Plug-ins
(Flash, Java ... )
Browser
Unrestricted
, access
Operating System
Fig. I. The current browser architecture. Plug-ins makes system calls with
the OS directly.
Both the browser and plug-ins are able to make system calls
and interact with the Operating System directly. Figure 1
shows the current architecture for including plug-ins. Both the
browser and plug-ins are able to make system calls and
interact with the as directly. The challenge of securing
plug-ins is to maintain a large range of fnctionality and
enable feature-rich applications while at the same time
providing safety and resilience to plug-in exploits.
Several previous works[ 12-14] address some specifc
shortcomings in the SOP, they do not address the general gap
between the fndamental SOP model and the security
requirements of modem web applications[5].
Browsers must uniformly apply policies to web program
instances and the code they run, regardless of the content type
of the code. This is necessary for reasoning about what
programs can and cannot do in the browser. To achieve this,
browsers must provide appropriate interfaces for interposing
on web program behavior. They must also allow extensible
security policies to be registered with these interfaces, to
support new policies that react to unforeseen theats.
III. KUBERA ARCHITECTURE
We propose a system call interposition-based sandbox
called KUBERA. KUBERA is a protection model specifcally
designed to meet the protection needs of modem web
applications. Because the sandboxing system has complete
control over accessing resources, it can ensure that this takes
place in a manner that excludes the possibility of race
conditions.
KUBERA consists of the interposition layer and the policy
engine. The policy engine is responsible for interpreting a web
application policy and deciding which resources the
sandboxed web application should be allowed to access. The
interposition layer provides the fnctionality required by the
policy engine to make decisions and enforce decisions. Fox
example, provides access to system call arguments or access
to video camera.
Policy decisions are made by interpreting the meaning of a
system call or a request of cross domain communication, then
making a decision based on a global policy. The global policy
is a fle consisting of a set of rules specifing which resources
a web application may access. The global policy allows only
those actions necessary for the intended fnctionality of the
web application and denies everything else; see Figure 2.
Policy: lusrlsbinlnamed, Emulation: kubera
kubera - sysctl: permit
kubera -accept: permit
kubera -bind: sockaddr match "inet-*:53" then permit
kubera -break: permit
kubera -chdir: flename eq "I" then permit
kubera -chdir: flename eq "/namedb" then permit
kubera -chroot: flename eq "/var/named" then permit
kubera -close: permit
kubera -connect: sockaddr eq "/dev/log" then permit
Fig.2. A part of the global policy. New policy statements can be appended.
The bind statement allows the daemon to listen for DNS requests on any
interface.
The Liux for providing access to the network, device, and
fle system is based on a "descriptor," a simple capability
model where obtaining a capability. For example, fle
descriptor with the open call. Applications are always started
with a descriptor space containing only the standard input,
output, and eror descriptors. This ensures that applications
can only access resources explicitly permitted by the sandbox.
Because the Linux API is quite large, we only need to
regulate the certain number of calls that have an impact
outside of the process. We mainly focus on fle system access,
network access and device access here. The persistent state
and DOM access are easy to handle as they are generally
allowed or denied out right.
275
TABLE I SYSTEM CALLS THAT KUBERA REGULATES
File system * create fle, delete fle
Access * open, close
* read, write, reposition
* get fle attributes, set fle attributes
Device * request device, release device
Access * read, write, reposition
* get device attributes, set device attributes
* logically attach or detach devices
Network * create, delete communication connection
Access * send, receive messages
* transfer status information
* attach or detach remote devices
Some plug-ins enforce their own policy to access resources.
Flash plug-ins can provide cross-domain network
communication via the use of its own policy fle
(crossdomain.xml). Microsof Silverlight has similar policy
fle. Fox example, the following fle allows open access to
fles in its directory and all subdirectories. Meanwhile, the
browser instance may not allow access like this.
<?xml version="l.O"?>
<cross-domain-policy>
<allow-access-fom domain="*" to-ports="*" />
</cross-domain-policy>
The current browser makes all these decision by the SOP.
Without the global policy, a plug-in vulnerability exposes not
only the browser to attack but places the whole system at risk.
By restricting the plug-in fom accessing the local system and
forcing it to comply the global policy we can prevent damage
to the underlying system.
KUBERA creates global policy automatically based on each
web application policy. In according to the principle of least
privilege[lS], KUBERA translates the system call arguments
and canonically transform them into policy statements for the
corresponding system calls.
KUBERA's tracing mechanism is similar to Janus
version2[ 16]. It overcomes the shortcomings of existing
process tracing mechanisms for supporting secure system call
interposition. The tracing monitor attaches a descriptor to a
process and specifes which system calls to allow and which to
trap. The tracing monitor calls select on the descriptors
associated with its sandboxed processes to poll for trap events.
Trap events are triggered when a "trapped" system call is
made by the sandboxed process. When a trap event is holding
on a descriptor, the descriptor read the type of call that was
trapped. As long as a process has generated a trap , it is put
into an uninterruptible sleep state and can only continue once
given an "allow" or "deny" by the tracing monitor. A process
cannot escape the sandbox; closing a descriptor kills its
process, and descriptors cannot be unbound.
[ Persistent State I
[ DOM Access I
[Filesystem Access I
[ Device Access I
Network Access
Browser
System call
KUBERA
Plug-ins
(Flash, Java .. )
t i System call result

System Call Gateway
KUBERA
Operating System
Fig. 3. KUBERA achitecture.
As shown in Figure 3, KUBERA monitors web application
behavior by interposing on the system call interface. This
interposition layer in the browser can gover a program's
access to the DaM, the network, other web program
instances, and other browser resources. KUBERA applies
uniformly to each content type, so that a single set of policies
can gover HTML, JavaScript, Plug-ins, and other types of
web content.
When a web application requests a sensitive call, the tracing
mechanism of KUBERA puts it to sleep and sends a request to
the system call gateway. A small part of KUBERA is placed at
the kerel-level. The kerel-level component supports a fast
channel for system calls that should always be allowed or
denied. A user space implementation is more portable but may
afect the system's performance. The policy engine is
responsible for making decision according to the global
policy. Wen the current policy does not cover the attempted
system call, a policy decision is required by the user, the user
is presented with a notifcation that contains all relevant
information in the browser. Finally, the system call gateway
responds to the request with "allow" or "deny" based on the
decision that KUBERA makes. The tracing mechanism then
wakes up the pending process. If the call is denied, the call
will retur an error message immediately. If the call is
allowed, the application call proceeds normally. Calls which
are not regulated by KUBERA are never trapped by the tracing
interface, and thus execute in an unsandboxed operation
mode.
IV. PERFORMACE
KUBERA is currently available for Linux, Mac as X. To
determine the performance impact of KUBERA, We evaluated
its overhead on the execution time of html rendering and on
several plug-ins. Our experiments were carried out on a
276
desktop PC running Ubuntu 9. 10 with 2GB of RM and dual
2.56GHz Dual Core Intel Processors.
The table II shows that KUBERA takes slightly longer in
most cases. It is expected that for most operations KUBERA
will have a performance overhead as compared to standalone
browser, due to interposition costs. Considering the benefts
of the interposition layer, the latency caused by KUBERA is
acceptable.
TABLE II A COMPARISON BEFORE AND AFTER THE INSTALLATION OF
KUBERA
FireFox FireFox 3.5
3.5 with KUBERA
Navigate to google.com In 81lms 907ms
htl page (with a cross-origin
fame)
Navigate to google.com in 1470ms 1563ms
Flash movie (with a
cross-origin request)
Navigate to google.com In 1623ms 1793ms
Silverlight fle (with a
cross-origin request)
Respond to a request for local 33ms 42ms
fle access(Flash movie )
Respond to a request for local 36ms 54ms
fle access(Silverlight)
Respond to a request for a 74ms 86ms
socket (Flash movie )
Respond to a request for a 89ms 97ms
socket (Silverlight)
V. CONCLUSION
In order to prevent the browser fom being attacked or used
to launch an attack, policies must also limit a plug-in's ability
to corrupt and directly interact with the browser and the
operating system. Controlling sensitive system call also
prevents interal browser state fom being exposed to plug-in
attacks.
To reach this goal, KUBERA sandboxes existing plug-ins
like Flash and Silverlight using system call interposition.
KUBERA leverages the isolation provided by the OS's process
abstraction. All security-sensitive interactions between the
different sandboxed web applications or diferent browser
instances are conducted through the system call interface. It is
an adaptation of system call interposition to meet the
protection requirements of web application.
[I]
[2]
[3]
REFERENCES
AdobeSystems. Flash content reaches 99% of Internet viewers.
Available:
ht://www.adobe.com/products/player census/flashplayer/
A. Barth, et 01. (2008, The securit architecture of the chromium
browser. Available:
http://seclab.stanford.edu/websec/chromium/
G. Chris, et 01., "Secure Web Browsing with the OP Web
Browser," in Proceedings of the 2008 IEEE Symposium on
Securit and Privacy, ed: IEEE Computer Society, 2008, pp.
402-416.
[4] H. J. Wang, et 01., "The Multi-Principal OS Construction of the
Gazelle Web Browser," presented at the The 18th USENIX
Security Symposium, Montreal, Canada, 2009.
[5] K. Jayaraman, et 01., "Escudo: A Fine-grained Protection Model
for Web Browsers," in The 30th International Conerence on
Distributed Computing Systems, Genoa, Italy, 20 I O.
[6] T. Garfnkel, et 01., "Ostia: A Delegating architecture for Secure
System Call Interposition," presented at the Proceedings of the
Network and Distributed System Security Symposium, San
Diego, USA, 2004.
[7] I. Goldberg, et 01., "A Secure Environment for Untrusted Helper
Applications," presented at the Proceedings of the 6th USENIX
Security Symposium, San Jose, USA 1996.
[8] T. Fraser, et 01., "Hardening COTS Sofware with Generic
Sofware Wrappers," presented at the IEEE Symposium on
Security and Privacy, Oakland, USA, 1999.
[9] M. Zalewski. (2009, BroJllser Securit Handbook. Available:
http://code.google.coll /p/browsersec/
[10] Same origin policy for JavaScript. Available:
https://deveioper.mozilla.orgiEn/Same_ origin ol icy_for _JavaS
[II]
[12]
[13]
[14]
[15]
[16]
cript
J. Collin, et 01., "Protecting browsers from DNS rebinding
attacks," ACM Transactions on the Web, vol. 3, pp. 1-26,2009.
K. Chris, et 01., "Dynamic pharming attacks and locked
same-origin policies for web browsers," in Proceedings of the
14th ACM conference on Computer and communications
securit, ed. Alexandria, Virginia, USA: ACM, 2007, pp. 58-71.
L. Benjamin and E. I far, "Using web application construction
frameworks to protect against code injection attacks," in
Proceedings of the 2007 workshop on Programming languages
and analysis for securit, ed. San Diego, Califoria, USA: ACM,
2007, pp. 95-104.
J. Collin, et at., "Protecting browser state fom web privacy
attacks," in Proceedings of the 15th interational conference on
World Wide Web, ed. Edinburgh, Scotland: ACM, 2006, pp.
737-744.
J. H. Saltzer and M. D. Schroeder, "Protection of Information in
Computer Systems," Proceedings of the Ieee, vol. 63, pp.
1278-1308,1975.
D. A. Wagner, "Janus: an Approach for Confnement of
Untrusted Applications," University of Califoria at
Berkeley 1999.
277