Collin Jackson is an assistant research professor at CyLab and INI. He is based at the Carnegie Mellon Silicon Valley campus. His research focuses on the security of browsers and web applications.
[ email ]
posted by Richard Power
CyLab Chronicles: The story of your experiment in running a "Flash Ad" is a fascinating one. And what the data revealed offers a meaningful insight into the type of door to door, alley to alley battle going on in the shadow realm of cyber security. Briefly, recount what you did and what the numbers looked like.
We worked with Adobe to get the vulnerability fixed in the latest version of Flash Player. However, it's only a matter of time before new vulnerabilities are found, and it takes a long time before everyone updates to the latest version. I think ad networks will remain a potential platform for attacks unless steps are taken to control the content that can be displayed in ads. On the plus side, ad networks are also a great platform for web security research, because I can use them to measure browser security policies from a large sample of users.
CyLab Chronicles: Tell us about Cross-Site Request Forgery (CSRF) attacks. What is lacking in current defenses? What issues are you exploring in your research?
Jackson: In a CSRF attack, a malicious site instructs a victim’s browser to send a network request to an honest site, such as your bank. The bank site is confused into accepting the request, because it doesn't know that the request came from the malicious site. This allows the malicious site to make changes to your bank account, such as initiating a transfer. There a few different defenses for CSRF attacks, but none of them are really satisfactory. The HTTP "Referer" header reveals the source of the requests, but it's often blocked for privacy. You can set custom headers that can't be spoofed, but this only works for sites that are using cutting-edge AJAX techniques for everything and are limited to a single domain. Finally, there are secret token approaches, which are hard to use and often miss certain types of attacks.
One solution we've been exploring is combining the Referer header with browser encryption to reduce the likelihood that privacy blocking will occur. We've also been working on a new "Origin" header that has better privacy properties than the Referer header, so it's less likely to be blocked. The Origin header has been deployed in Safari and Google Chrome.
CyLab Chronicles: Tell us a little bit about Frame Isolation and Frame Communication. What did you find lacking in frame navigation policy? How do you address cross-window and same window attacks? What problem does your secure protocol for fragment identifier messaging address? What did you fix in the new postMessage() API?
Jackson: Frames allow you to compose together several HTML documents on a single page. They're a nice way to isolate third-party content, but there needs to be a security policy to decide who can decide who can navigate a frame (i.e. who cause the frame to display a new document). For example, Google puts their login form in a frame, so an attacker who navigates that frame can show you a spoofed login form and steal your Google password. The browser needs to prevent the attacker from navigating that login frame. We examined the frame navigation policies of the existing browsers and found that they were all over the map -- there wasn't a consensus among the vendors what the policy should be. So we worked together with web standards bodies to deploy a consistent policy that prevents these attacks. You can now only navigate a child frame if it's a descendant of a frame you control.
We also looked at the effect of frame navigation on client-side messaging protocols that sites can use to communicate with each other through your browser. Malicious navigation could be used to compromise the authentication of the fragment identifier messaging, and it could be used to compromise the confidentiality of the newer postMessage API. We made some tweaks to those protocols to harden them against unexpected navigation.
CyLab Chronicles: In regard to your current browser research, the Web application platform is, as you say, ubiquitous, interactive, easy to update and powerful. I would add it is also something that has evolved swiftly and spread pervasively, and is, because of the features you mention, both irresistible and unstoppable. But, of course, this is technology and technology is always a two-edged sword. So tell us about the two categories of threats you are looking at, i.e., malicious servers and network attacks.
Jackson: One of the reasons the Web has been so successful is that it allows you to safely interact with web applications written by anyone — even someone they do not fully trust. The availability of cheap web hosting and advertising has made it easier than ever for malicious servers to get introduced to victims, and the browser is largely what keeps those attackers at arms length. For example, a web site you visit shouldn't be able to make unauthorized changes to your computer or read your private data. There's a lot of engineering effort that goes into browsers to make sure that your local system is protected from web sites you visit, and that the blog site you're viewing in one tab isn't able to access the bank site you've got running in another tab. But there is still plenty of room for improvement, and new vulnerabilities are discovered every day.
Besides protecting you from malicious web sites, browsers are also responsible for keeping you safe from network attackers. When you're using the wireless network at Starbucks, for example, someone nearby might try to listen in on your web traffic or even hijack your session. Browser encryption (HTTPS) is supposed to protect against these types of attacks, but it's hardly ever used. Even worse, if you go to a web site that appears to be using no encryption, there's no way to tell whether the web site owner is being negligent or there's someone listening in. There are also a number of security problems with sites that do go the extra mile and turn on encryption. I've been working on tools to try to make it easier to use correctly.
CyLab Chronicles: How do you assess the commercial or communal impact of your research? Is there a measure of the impact?
Jackson: It's easy to come up with new ideas for web security, but getting them deployed is another story. If the proposal breaks existing web functionality, users won't be able to browse to their favorite sites and browser vendors will be reluctant to adopt the proposal. This is why it's so important to assess the compatibility impact of changes to browser security policies. It's also helpful to get the proposal reviewed by one of the web standards working groups to ensure that all the browser vendors are on board and they will implement it the same way. We went through this process to change postMessage and the browser frame navigation policy, for example, and I'm happy to say that our proposals were adopted by all the major vendors.
See all CyLab Chronicles articles