I just came back from WWW 2010 where I presented a research project I’ve been working on for the majority of my undergraduate years. The project is about building web applications with high level security properties that can be verified in a code review. This post is about the project and why I think it’s really cool.
I’d like to start off by convincing you that we need web applications with verifiable high-level security properties. First, what is a high level security property? It’s an application-specific guarantee about the privacy and integrity of user data maintained by the application. For example, as a user of an online banking application, I’d like some assurance that I cannot lose money unless I have authorized a transaction. I’d also like some guarantee that only I can view my account balances and transaction histories. These are high-level properties regarding the integrity and privacy of my data. And these are the kinds of guarantees that we want with our web applications; it’s not enough to just defend an app from XSS and CSRF.
Since these properties can be violated by the application itself (as opposed to external attackers), we have to make sure that the application does not violate them. This requires a code review. Unfortunately, with state-of-the-art technologies, and with sophisticated, complex applications, these code review are incredibly challenging. I would argue that they are infeasible. Why? Because verifying that a high-level property is achieved involves an exhaustive review of the application. With current application architectures, every object has the privileges necessary to violate whatever security property we’re interested in. In order guarantee that the application satisfies a property, we therefore have to make sure that the entire application does not violate it. Since applications are enormous, this is very challenging.
My project looked at making these code review easier by partitioning an application into components and granting only specific privileges to each component. Partitioning an application and exposing limited privileges facilitates a code review because now only parts of the application have the privileges needed to violate any particular security property. Auditors may not even have to look at certain application modules because they can guarantee a priori that those modules cannot violate the properties we are interested in.
All we’re doing here is bringing the idea of least privilege to web applications. We used an object capability approach to achieving least privilege in application components. Our goal was to confine each application component to a reduced-privilege context. We took a multi-faceted approach. First, we prevented application components from constructing additional privilege. We did this by requiring that applications are written in an object-capability language (in our case Joe-E). Second, we prevented the application from maintaining state outside of a semi-persistent session object (By semi-persistent, I mean that it lives in memory but is maintained across multiple HTTP requests). Combined, these two properties imply that all privileges to user data and resources must reside within the session object. Finally, we use wrapper objects to expose only a subset of the session object to each application component. This effectively confines each application component into a reduced-privilege context.
In terms of implementation, we built Capsules, a prototype framework that extends the Java Servlet Framework with these ideas. As mentioned, we require that applications are written in Joe-E, an object capability subset of Java. We use several Joe-E features to achieve the three aspects of our approach. First, Joe-E prevents objects from constructing privileges from scratch. Secondly, Joe-E allows us to declare application components (called Servlets) as immutable, which, in short, means that they cannot maintain state. Finally, Joe-E allows us to construct wrapper objects that actually encapsulate their internal state, so that Servlets must go through the interfaces exposed by the wrapper rather than using reflection to obtain a reference to the underlying session object. In this way, Joe-E helps us establish these reduced-privilege contexts.
We also conducted an evaluation of this framework by building a simple web mail application and verifying that the application maintains the privacy and integrity of user mailboxes. In this analysis, we discovered that there were several application components that we could completely ignore, simply because they had no way to violate the privacy and integrity properties. While our application was simple, we believe that this kind of analysis will also apply to more sophisticated applications, making it more practical to review these kinds of high-level properties.
So that’s a overview of the Capsules project. I’ve ommited most of the technical details so that I could concisely convey the main points. If you are interested, I encourage you to read our paper or see the slides for my talk (although I don’t think the slides will be very helpful apart from the pretty pictures). Finally, please feel free to contact me if you have questions or are interested in talking to me about the project.