BEEP: Browser-Enforced Embedded Policies

Trevor Jim, Nikhil Swamy, and Michael Hicks

UPDATE: our paper will appear in WWW 2007 in May 2007.

» Download PDF «

BEEP is a simple, novel, and effective method for stopping script injection attacks (cross-site scripting) in web applications.

Motivation

Many web applications publish content from untrusted sources, for example, blog comments. The whole purpose of sites like Blogger, MySpace, and Flickr is to republish content provided by anyone at all. If this content contains scripts, then the script will be executed in the browser of anyone who visits the site. This is a script injection attack, and it is currently the #1 class of security vulnerabilities being reported today.

To prevent script injection, many web applications filter user content for scripts. However, due to browser incompatibilities, the desire for browsers to render even malformed web pages, and the desire of web applications to allow rich content (typographic styling, etc.), server-side filtering has been problematic. Attacks like the Samy and Yamanner worms were able to use script injection despite server-side filtering.

Our solution

We make two observations.
  1. The web browser performs perfect script detection. By definition, if the browser does not detect a script, it will not be executed when the browser renders the page.
  2. The web application developer knows exactly what scripts are needed to run the application.

Therefore, our idea is for the web application to tell the browser what scripts are allowed to run, in the form of a policy embedded in each web page, and for the browser to enforce the policy as it detects scripts in the page. We call this BEEP, for Browser-Enforced Embedded Policies.

There are many possible ways to formulate policies, communicate them to browsers, and enforce them in browsers. We have chosen to implement BEEP in a way that allows very general policies and at the same time is easy to implement. Specifically, we modify web browsers to look for a JavaScript hook function that can be provided by the web application. This hook function specifies what scripts are allowed to run, and what scripts are not allowed to run. Whenever the browser finds a script in the web page, it consults the hook function before running the script.

Why this is easy to implement: Consider what happens when a web browser finds a script while rendering a web page. Before running the script, it must first check the policy to see whether the script is approved. Since it is poised to evaluate a script, we simply modify the browser to invoke the JavaScript hook function first. If the hook function returns true, the script from the web page is approved and passed to the JavaScript evaluator; otherwise, the script does not run. This is a very small modification to the browser: we invoke the JavaScript evaluator twice instead of just once. So far, we have added BEEP to Safari, Konqueror, and Opera.

Why this is general: Web applications have the freedom to use whatever policy they like, as long as it can be implemented in JavaScript. We have implemented whitelist- and sandbox-style policies, but many variations are possible (e.g., reporting attacks back to the web site).

Download

Our paper describes the difficulties of server-side filtering, BEEP, and our implementation in much greater detail:

Defeating Script Injection Attacks with Browser-Enforced Embedded Policies, by Trevor Jim, Nikhil Swamy, and Michael Hicks. 16th International World Wide Web Conference, May 8-12, 2007. » PDF available from WWW2007 site «

An earlier version of the paper appeared as a technical report:

Defeating Script Injection Attacks with Browser-Enforced Embedded Policies, by Trevor Jim, Nikhil Swamy, and Michael Hicks. Technical Report CS-TR-4835, Department of Computer Science, University of Maryland, November 2, 2006. » Download PDF «

We have also made our browser modifications and test cases available. Get them » here «.