akrish

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.

I started working again on another website which I may talk more about later, and while doing this, I noticed that I’m a lot more paranoid about security vulnerabilities than I used to be. I used to care more about functionality and usability than security, but after watching cs155 lectures and reading a lot of security papers last semester, I find it a lot more interesting to think about attacks and build my site to defend against these attacks.

I don’t want to write a lot about why I’m interested in security, but I probably should and think I will later on. I wanted to present a vulnerability that I heard about yesterday and after thinking about, I’m pretty sure that most rookie web developers (like myself) aren’t aware of the dangers here.

So I think a lot of people are familiar with packet sniffing. A packet sniffer is a tool that can intercept and try to decipher network traffic. With wireless networks, this doesn’t even require any hardware or any modifications to the router firmware. My computer can intercept any packet on the same wireless network using tools like WireShark.

And this is what I can do as a packet sniffer. I can intercept packets on my wireless network, read them and look at them for important information like email addresses, credit card numbers, passwords etc. So lets say that you are logging into some not-secure site; you provide your email account and password, and you notice that you’re logged in. I, the malicious packet sniffer, intercept the packet containing your http request, and now I have your email address and your password. Once I know this, I can try using it (or some permutations of it) to log into your email account, Facebook account, or even your online banking service. Yeah kinda scary…

So how do I prevent this attack? I can’t prevent you from intercepting the packet (at least not without some fundamental change in how wireless works, an area that I’m not familiar with so I won’t talk about it). But I can prevent you from being able to interpret the packet. If I encrypt the packet, then depending on encryption scheme you probably won’t be able to decrypt and read the content of the packet. Which brings us to SSL…

To prevent packet sniffers from stealing information, as a web developer, you need to be serving your pages of SSL. As a consumer, I can tell wether my pages is served over SSL by looking at a bunch of features of browsers. Mozilla has a lock/certificate on some pages, safari has a lock in the url bar etc.

SSL uses public-key encryption, so basically the server gives the client a public key which the client must use to encrypt all data that is sent to the server. The server maintains a private key, that no one else knows about, and it uses this key to decrypt whatever was sent from the client. Since as a packet sniffer, I don’t know the private key, there’s no way for me to decrypt your packet and steal your information.

At the same time, this encryption/decryption process introduces a lot of intense computation in serving what could be fairly simple pages. So not all pages should be served over SSL, just the ones with sensitive information. For example, most online banking systems are server entirely over SSL, but at Facebook, only the login page is.

There are a lot more details about SSL; if you want to know more, there’s plenty of information on wikipedia or you can ask me.

So most large web services do consider security and encrypt their traffic appropriately and that’s not really my concern. My issue is with kids like me (or me a year ago) developing websites without knowing or caring enough about security. These websites are unknowingly compromising my information and I have a serious problem with that. Especially since a lot of people don’t have hard enough passwords and tend to use similar (or even the same) passwords for multiple sites. It wouldn’t be hard to steal your whole online identity just because you made an account at what you thought was a pretty legitimate website.

And the solution to this is just to make sure that people know that security is a serious issue that all web developers need to know about and understand. Awareness about web vulnerabilities needs to be increased (both to developers and users). It’s also important that users know when they’re pages are served over SSL or more importantly when they aren’t (look for the lock).

My intention in writing this was to do my part in increasing awareness; hopefully I’ve saved at least one person from a lot of grief.

Edit 8/10/08: An article got posted yesterday in the new york times that kind of relates to this. It talks more long term solutions to the whole password problem. Something called Identity cards that are maintained on your local machine and of course cryptographic protocols. Read it here.