DoI: 10.1145/1461928.1461949
Building Secure Web Applications
with Automatic Partitioning
By Stephen Chong, Jed Liu, Andrew C. Myers, Xin Qi, K. Vikram, Lantian Zheng, and Xin Zheng
abstract
Swift is a new, principled approach to building Web applications that are secure by construction. Modern Web applications typically implement some functionality as client-side
JavaScript code, for improved interactivity. Moving code
and data to the client can create security vulnerabilities, but
currently there are no good methods for deciding when it is
secure to do so.
Swift automatically partitions application code while providing assurance that the resulting placement is secure and
efficient. Application code is written as Java-like code annotated with information flow policies that specify the confidentiality and integrity of Web application information. The
compiler uses these policies to automatically partition the
program into JavaScript code running in the client browser
and Java code running on the server. To improve interactive performance, code and data are placed on the client.
However, security-critical code and data are always placed
on the server. The compiler may also automatically replicate
code across the client and server, to obtain both security and
performance.
1. IntRoDuCtIon
Web applications are client–server applications in which a
Web browser provides the user interface. They are a critical part of our infrastructure, used for banking and financial management, email, online shopping and auctions,
social networking, and much more. The security of information manipulated by these systems is crucial, and yet
these systems are not being implemented with adequate
security assurance. Indeed, 69% of all Internet vulnerabilities are said to be related to Web applications. The
20
problem is that with current implementation methods,
it is difficult to know whether an application adequately
enforces the confidentiality or integrity of the information
it manipulates.
Recent trends in Web application design have exacerbated the security problem. To provide a rich, responsive
user interface, application functionality is moving into
client-side JavaScript6 code that executes within the Web
browser. JavaScript code is able to manipulate user interface
components and can store information persistently on the
client side by encoding it as cookies. These Web applications
are distributed applications, in which client- and server-side
code exchange protocol messages represented as HTTP
requests and responses. In addition, most browsers allow
JavaScript code to issue its own HT TP requests, a functionality used in the Ajax development approach (Asynchronous
JavaScript and XML).
With application code and data split across differently
trusted tiers, the developer faces a difficult question: when
is it secure to place code and data on the client? All things
being equal, the developer would usually prefer to run
code and store data on the client, avoiding server load and
client–server communication latency. But moving information or computation to the client can easily create security
vulnerabilities.
For example, suppose we want to implement a simple
Web application in which the user has three chances to
guess a secret number between 1 and 10, and wins if a guess
is correct. Even this simple application has subtleties. There
is a confidentiality requirement: the user should not learn
the secret until after the guesses are complete. There are
integrity requirements, too: the comparison of the guess
and the secret should be computed in a trustworthy way, and
the number of guesses must also be counted correctly.
The guessing application could be implemented almost
entirely as client-side JavaScript code, which would make
the user interface very responsive and would offload the
most work from the server. But it would be insecure: a client with a modified browser could peek at the true number,
take extra guesses, or simply lie about whether a guess was
correct. On the other hand, suppose guesses that are not
valid numbers between 1 and 10 do not count against the
user. Then it is secure and indeed preferable to perform the
bounds check on the client side. Currently, Web application
developers lack principled ways to make decisions about
where code and data can be securely placed.
The Swift system is a new way to write Web applications
that are secure by construction. Applications are written in a
higher-level programming language in which information
security requirements are explicitly exposed as declarative
annotations. The compiler uses these security annotations
to decide where code and data in the system can be placed
securely. Developing programs in this way ensures that the
resulting distributed application protects the confidentiality and integrity of information. The general enforcement of
information integrity also guards against common vulnerabilities such as SQL injection and cross-site scripting.
Swift applications are not only more secure, they are also
easier to write: control and data do not need to be explicitly
transferred between client and server through the awkward
extra-linguistic mechanism of HTTP requests. Automatic
placement has a performance benefit as well. Currently,
A previous version of this paper was published in
Proceedings of the 21st ACM Symposium on Operating
System Principles (October 2007).
febrUary 2009 | vol. 52 | no. 2 | CommunICatIons of the aCm
79