The primary defense against cross site scripting attacks in web applications is the use of sanitization, the practice of filtering untrusted inputs. We analyze sanitizer use in a shipping web application with over 400,00 lines of code, one of the largest applications studied to date. Our analysis reveals two novel problems: inconsistent sanitization and inconsistent multiple sanitization. We formally define these problems and propose SCRIPTGARD: a system for preventing such problems automatically matching the correct sanitizer with the correct browser context. While command injection techniques are the subject of intense prior research, none of the previous approaches consider both server and browser context, none of them achieve the same degree of precision, and many other mitigation techniques require major changes to server side code. Our approach, in contrast, can be incrementally retrofitted to legacy systems. We show how to provide an aid to testers during development. Finally we sketch how SCRIPTGARD can be used as a runtime mitigation technique. 1.

Abstract. Web applications have become important services in our daily lives. Millions of users use web applications to obtain information, perform financial transactions, have fun, socialize, and communicate. Unfortunately, web applications are also frequently targeted by attackers. Recent data from SANS institute estimates that up to 60 % of Internet attacks target web applications. In this paper, we perform an empirical analysis of a large number of web vulnerability reports with the aim of understanding how input validation flaws have evolved in the last decade. In particular, we are interested in finding out if developers are more aware of web security problems today than they used to be in the past. Our results suggest that the complexity of the attacks have not changed significantly and that many web problems are still simple in nature. Hence, despite awareness programs provided by organizations such as MITRE, SANS Institute and OWASP, application developers seem to be either not aware of these classes of vulnerabilities, or unable to implement effective countermeasures. Therefore, we believe that there is a growing need for languages and application platforms that attack the root of the problem and secure applications by design. 1

Web applications often use HTML templates to separate the webpage presentation from its underlying business logic and objects. This is now the de facto standard programming model for Web application development. This paper proposes a novel implementation for existing server-side template engines, FlyingTemplate, for (a) reduced bandwidth consumption in Web application servers, and (b) off-loading HTML generation tasks to Web clients. Instead of producing a fully-generated HTML page, the proposed template engine produces a skeletal script which includes only the dynamic values of the template parameters and the bootstrap code that runs on a Web browser at the client side. It retrieves a client-side template engine and the payload templates separately. With the goals of efficiency, implementation

Rich Internet applications are becoming increasingly distributed, as demonstrated by the popularity of AJAX/Web 2.0 applications such as Hotmail, Google Maps, Facebook, and many others. A typical multi-tier AJAX application consists of a server component implemented in Java J2EE, PHP or ASP.NET and a client-side component executing in JavaScript. The resulting application is more performant and responsive because computation is moved closer to the client, and thus avoids unnecessary network round trips for frequent user actions. However, once a portion of the code is moved to the client, a malicious user can easily subvert the client side of the computation and potentially jeopardize sensitive server state. In this paper we propose RIPLEY, a system that uses replicated execution to automatically preserve the integrity of a distributed computation. RIPLEY replicates a copy of the client-side computation on the trusted server tier. Every client-side event is transferred to the replica of the client for execution. RIPLEY observes results of the computation, both as computed on the client-side and on the server side using the replica of the client-side code. Any discrepancy is flagged as a potential violation of computational integrity. Our evaluation of RIP-LEY on five complex and representative AJAX applications suggests that RIPLEY is a promising method for building secure distributed web applications. 2 1

Rich Internet applications are becoming increasingly distributed, as demonstrated by the popularity of AJAX or Web 2.0 applications such as Facebook, Google Maps, Hotmail and many others. A typical multi-tier AJAX application consists, at the least, of a serverside component implemented in Java J2EE, PHP or ASP.NET and a client-side component running JavaScript. The resulting application is more responsive because computation has moved closer to the client, avoiding unnecessary network round trips for frequent user actions. However, once a portion of the code has moved to the client, a malicious user can subvert the client side of the computation, jeopardizing the integrity of the server-side state. In this paper we propose RIPLEY, a system that uses replicated execution to automatically preserve the integrity of a distributed computation. RIP-LEY replicates a copy of the client-side computation on the trusted server tier. Every client-side event is transferred to the replica of the client for execution. RIPLEY observes results of the computation, both as computed on the client-side and on the server side using the replica of the client-side code. Any discrepancy is flagged as a potential violation of computational integrity. We built RIPLEY on top of Volta, a distributing compiler that translates.NET applications into JavaScript, effectively providing a measure of security by construction for Volta applications. We have evaluated the RIPLEY approach on five representative AJAX applications built in Volta and also on Hotmail, a large widely-used AJAX application. Our results so far suggest that RIPLEY provides a promising strategy for building secure distributed web applications, which places minimal burden on the application developer at the cost of a low performance overhead.

Rich Internet applications are becoming increasingly distributed, as demonstrated by the popularity of AJAX/Web 2.0 applications such as Hotmail, Google Maps, Facebook, and many others. A typical multi-tier AJAX application consists of a server component implemented in Java J2EE, PHP or ASP.NET and a client-side component executing in JavaScript. The resulting application is more performant and responsive because computation is moved closer to the client, and thus avoids unnecessary network round trips for frequent user actions. However, once a portion of the code is moved to the client, a malicious user can easily subvert the client side of the computation and potentially jeopardize sensitive server state. In this paper we propose RIPLEY, a system that uses replicated execution to automatically preserve the integrity of a distributed computation. RIPLEY replicates a copy of the client-side computation on the trusted server tier. Every client-side event is transferred to the replica of the client for execution. RIPLEY observes results of the computation, both as computed on the client-side and on the server side using the replica of the client-side code. Any discrepancy is flagged as a potential violation of computational integrity. Our evaluation of RIP-LEY on five complex and representative AJAX applications suggests that RIPLEY is a promising method for building secure distributed web applications.

Web applications have become an integral part of the daily lives of millions of users. Unfortunately, web applications are also frequently targeted by attackers, and attacks such as XSS and SQL injection are still common. In this paper, we present an empirical study of more than 7000 input validation vulnerabilities with the aim of gaining deeper insights into how these common web vulnerabilities can be prevented. In particular, we focus on the relationship between the specific programming language used to develop web applications and the vulnerabilities that are commonly reported. Our findings suggest that most SQL injection and a significant number of XSS vulnerabilities can be prevented using straight-forward validation mechanisms based on common data types. We elaborate on these common data types, and discuss how support could be provided in web application frameworks. Categories and Subject Descriptors D.2.0 [Software Engineering]: General—protection mechanisms;