End to end Web Application Security
Web applications are important, ubiquitous distributed systems whose current security relies primarily on server-side mechanisms. This paper makes the end-toend argument that the client and server must collaborate to achieve security goals, to eliminate common security exploits, and to secure the emerging class of rich, crossdomain Web applications referred to as Web 2.0. In order to support end-to-end security, Web clients must be enhanced. We introduce Mutation-Event Transforms: an easy-to-use client-side mechanism that can enforce even ﬁne-grained, application-speciﬁc security policies, and whose implementation requires only straightforward changes to existing Web browsers. We give numerous examples of attractive, new security policies that demonstrate the advantages of end-to-end Web application security and of our proposed mechanism.
Web applications provide end users with client access to server functionality through a set of Web pages. These pages often contain script code to be executed dynamically within the client Web browser. Most Web applications aim to enforce simple, intuitive security policies, such as, for Web-based email, disallowing any scripts in untrusted email messages. Even so, Web applications are currently subject to a plethora of successful attacks, such as cross-site scripting, cookie theft, session riding, browser hijacking, and the recent self-propagating worms in Web-based email and. Indeed, according to surveys, security issues in Web applications are the most commonly reported vulnerabilities on the Internet . The problems of Web application security are only becoming worse with the recent trends towards richer, “Web 2.0” applications. These applications enable new avenues of attacks by making use of complex, asynchronous client-side scripts, and by combining services across Web application domains . However, the shift towards Web 2.0 also presents an opportunity for enhanced security enforcement, since new mechanisms are again being added to popular Web browsers. Therefore, we believe it is time to rethink the fundamentals of Web application security. It is our position that the client Web browsers must be given a greater role in enforcing application security policies. In this paper, we support our position with examples and a simple end-to-end argument: constraints on client behavior are enforced most reliably at the client. We also propose Mutation-Event Transforms: a novel, ﬂexible mechanism for client-side security policy enforcement.
1.1 Motivating Attacks
Of the current attacks on Web applications, those based on script injection are by far the most prominent. For example, script injection is used in cross-site scripting  and Web application worms [2, 24]. A script injection vulnerability may be present whenever a Web application includes data of uncertain origin in its Web pages; a third-party comment on a blog page is an example of such untrusted data. In a typical attack, malicious data with surreptitiously embedded scripts is included in requests to a benign Web application server; later, the server may include that data, and those scripts, in Web pages it returns to unsuspecting users. Since Web browsers execute scripts on a page with Web application authority, these returned scripts can give attackers control over the users’ Web application activities [1, 22]. Script injection attacks typically affect non-malicious users and succeed without compromising Web application servers or networks. For example, in 2005, the selfpropagating Samy worm on MySpace used script injection to infect over a million users . As a MySpace user viewed the MySpace page of another, infected user, the worm script would execute and send a page update request to the server, causing the worm script to be included also on the viewing user’s page. In an attempt to prevent script injection, most Web application servers try to carefully ﬁlter out scripts from untrusted data. Unfortunately, such data sanitization is highly error prone (see Section 2.1). For example, the Samy worm evaded ﬁltering, in part, by the unexpected placement of a newline character . Script injection is just one means of attack: there are many ways to exploit Web applications by presenting them with attacker-chosen data. As we demonstrate in this paper, end-to-end Web application security is not only a reliable means to prevent these attacks. Our proposals for enhanced, client-side security enforcement also form a simple, ﬂexible foundation for the general security of Web applications, including future, more complex Web 2.0 applications.2 The Case for End-to-end Defenses In general, it is often best to establish systems guarantees at the point where they are needed, with an end-to-end check, rather than with earlier, piecemeal checks . This end-to-end argument applies directly to Web application security. Although security policies should be determined and speciﬁed at the server, enforcement of policies about Web client behavior should be guaranteed at the client. The corresponding server-side checks are difﬁcult to perform and, in practice, incomplete in ways that enable attacks.
2.1 Server-side Defenses and their Limitations
Web applications must consider the possibility of malicious attackers that craft arbitrary messages, and counter this threat through server-side mechanisms. However, to date, Web application development has focused only on methodologies and tools for server-side security enforcement (for instance, see [11, 13]). At most, non-malicious Web clients have been assumed to enforce a rudimentary “same origin” security policy . Web clients are not even informed of simple Web application invariants, such as “no scripts in the email message portion of a page”, since clients are not trusted to enforce security policies. This focus on centralized server-side security mechanisms is shortsighted: server-side enforcement has difﬁ- culties constraining even simple client behavior. For example, to enforce “no scripts”, the server must correctly model complex, dynamic client activities such as string manipulation, and take into account all possible client features and bugs. This entails server consideration of a myriad different tags, encodings, and operators for comments and quoting . Server-side removal of scripts is especially difﬁcult for Web applications that wish to allow visual formatting or other data richer than simple text. As shown below, there are many non-obvious means of causing code execution, including within formatting tags:
At the same time, the majority of users are not malicious, and would enable client-side enforcement to avoid exploits such as cross-site scripting and Web-based worms. Even if only benign users with enhanced clients might perform security enforcement, those users would be protected, and all users would beneﬁt from fewer attacks on the Web application. Unfortunately, there are many obstacles to the adoption of new, enhanced security mechanisms in popular Web browsers. Even when such enhancements are practical and easy to implement, they may not be deployed widely. Therefore, to increase its chance of widespread adoption, a Web client security mechanism should be practical, simple, and ﬂexible, and be able to enforce multiple, attractive policies on client behavior. 3 New Client-side Security Mechanisms In this paper we propose enhancing Web clients with new security mechanisms that can not only prevent existing attacks, but are able to enforce all security policies based on monitoring client behavior. In particular, our new mechanisms support policies that range from disallowing use of certain Web client features (e.g., IFRAMEs or OBJECTs) to ﬁne-grained, application-speciﬁc invariants such as taint-based policies that regulate the ﬂow of credit-card information input by the user.