|
Jefferson's WheelSecurity Research at the University of Virginia |
Yuchen Zhou successfully defended his PhD thesis on Improving Security and Privacy of Integrated Web Applications! The dissertation was approved by his committee: Shuo Chen (Microsoft), Joanne Dugan, Kevin Sullivan, Westley Weimer, and Ronald Williams.
Congratulations to Yuchen Dr. Zhou!
Libra Link: Improving Security and Privacy of Integrated Web Applications.
Modern web applications make frequent use of third-party scripts, often in ways that allow scripts loaded from external servers to make unrestricted changes to the embedding page and access critical resources including private user information. Our paper describing tools to assist site administrators in understanding, monitoring, and restricting the behavior of third-party scripts embedded in their site, and what we’ve learned by using them, is now available: Yuchen Zhou and David Evans, Understanding and Monitoring Embedded Web Scripts, IEEE Symposium on Security and Privacy 2015.
Yuchen will present the paper at the Oakland conference (in San Jose) this May.
Project Site: ScriptInspector.org
UVAToday has an article about Yuchen Zhou’s work on analyzing web scripts: Giving Web Developers Tools to Protect Their Sites and Users, UVAToday, 5 February 2015.
Zhou also devised a tool that developers could use to constrain the activity of the hundreds of scripts they typically embed in a website. In the process of performing analytics or placing ads, these scripts gather user-generated information on a page and send it to their servers. There is no guaranteeing, however, that these servers are secure or that the companies offering these services are trustworthy. In other cases, scripts ostensibly offering a benign service like analytics could take over the page, replacing the site-owner’s ads with their own ads or stealing private user information from the page.
Rather than try to develop rules for every page on a site, Zhou’s tool generates a set of policies that can be applied to the site as a whole. It catalogs the elements of the site based on their content and their relationship to the structure of the page and specifies which elements can be accessed by specific scripts. “We’ve found that using a white list approach – specifying which elements a script can use rather than those it can’t – is more effective because it is easier to automatically identify public elements like an ad placeholder than sensitive information in the page,” Zhou said. The site owner can then review the policies and grant permissions accordingly.
Group alumna Adrienne Felt is in the news for reporting that Gogo in-flight wifi service is generating fake SSL certificates.
From Gogo Inflight Wi-Fi Undermines Encryption, Slate FutureTense, 5 Jan 2015:
Wi-Fi on planes is unreliable and expensive. Even worse: Service from Gogo—one of the primary providers of in-flight Internet—has a lot of strange insecurities. Google engineer Adrienne Porter Felt realized during a flight on Friday that, for Google services and possibly others, Gogo was undermining encryption meant to keep pages secure.
By Hannah Li
Single Sign-On (SSO) services are widely used in modern web applications for authentication and social networking. While implementing a SSO service for a website is moderately straightforward, building it correctly could be tough and mistakes can lead to serious security consequences. Previous research on Facebook SSO revealed several major vulnerabilities which could easily allow an attacker to obtain sensitive user information or to take full control of a user’s account. These security weaknesses can often lead to token credentials misuse.
Because of these findings, I was motivated to discover whether SSO services implemented with other versions of OAuth would exhibit the same security vulnerabilities. I analyzed Twitter SSO, which is implemented using OAuth 1.0A instead of OAuth 2 which is used by Facebook, for similar security weaknesses. I searched for vulnerabilities by building a web application implementing Twitter SSO and by examining the traffic between the client and the server for patterns and token leakages.
The four “tokens” which could be used by an attacker are the Consumer Key, Request Token, Verifier, and Access Token, which will be the focus of this analysis. For the rest of this post, Alice is the user and Mallory is the attacker.
Consumer Key. The Consumer Key and Secret are given to the application when it registers with Twitter. App developers are instructors to keep this key/secret pair secret and if exposed, to generate another key/secret pair.
Request Token. This token also comes in a key/secret pair. This temporary key is issued by Twitter to the application when Alice first requests to sign in with twitter. While the key is shown publicly in the URL, the secret should be kept private.
Verifier. The Verifier is a publicly shown key (in the URL) that Twitter issues to confirm that Alice has approved the application.
Access Token. This key/secret pair is a more permanent token that allows applications to access protected resources on behalf of Alice.
The diagram below provides a high-level description for Twitter SSO procedure, breaking up the protocol into three steps, each processing an authentication token.
The diagram below expands each of the three steps. Note that the items written on the arrows do not show a comprehensive list of parameters sent, but rather a few important ones (see Implementing Sign in with Twitter Overview and OAuth Core 1.0a for detailed documentation).
To evaluate the security of Twitter’s SSO implementation, I tried swapping all three tokens for other tokens in different combinations. I did not find any way to use these methods to gain illicit access to private, user information. There are several countermeasures associated with each token that Twitter SSO uses to prevent this type of attack.
Request Token. The Request Token must be connected to the Consumer Key and Secret and expires after the first time it is used to request an Access Token. Due to its temporary nature and correspondence with the Consumer Key and Secret, Mallory cannot exploit the system by stealing this Request Token without also knowing the Consumer Key and Secret, which should be kept secret.
Verifier. Twitter issues a different Verifier each time, thus preventing a malicious party from reusing the Verifier through an impersonation attack. Even through the Verifier is passed through the URL, like the Request Token, Mallory cannot attack the web application without also knowing the Consumer Key and Secret.
Access Token. Each Access Token is connected to a Consumer Key and Secret, which are known only to the application developer. So even if Mallory were to successfully obtain a leaked token over the traffic, she would not be able to use it to log into Alice’s account. This is verified with HuffingtonPost.com, which leaks its Access Token pair through its last message to Alice’s browser. Without this defense, Mallory could have used the leaked Access Token to issue requests to Twitter on behalf of HuffingtonPost.com and Alice.
The last precaution also proved to be useful in another serious mistake in the SSO service. Many tests found that when an application uses the Access Token to request Alice’s information or post on her behalf, Twitter does not check the Access Token Secret, as only providing the Access Token is enough to give the client permission.
This may not pose a realistic security threat because the entire Access Token key pair is typically kept secret, so in order to take advantage of this mistake, Mallory would need to find the Consumer Key and Secret as well. To make the entire system more secure, it is recommended that Twitter verify the Access Token Secret, as many keys and secrets are accidentally leaked through GitHub and even mobile applications when the developers are not careful. When Mallory has both the Access Token and Consumer Key token/secret pairs, it would be much easier to attack a web application.
Though checking the Access Token against the Consumer Key makes SSO safer to use, it has its weaknesses as well. Mobile Applications are easy to reverse engineer since the client code must be made available. If an application needs the Consumer Key to implement SSO, then there is no possible way to build a client-only secure application with SSO since the Consumer Key must be in the code. The secure approach re-routes requests through an application server, which can securely store the key and add it to the requests sent to Twitter. This adds an extra step to app building and many developers may not realize the importance in not including the Consumer Key in the application code.
A recent study from Columbia (Nicolas Viennot, Edward Garcia, and Jason Nieh. A Measurement Study of Google Play. ACM SIGMETRICS, June 2014) scanned thousands of applications in the Google Play Store for token and secret leakages, supports the conclusion that requiring a Consumer Key from the client often leads to faulty implementations. They discovered 1,477 Facebook credentials and 28,235 Twitter credentials among all the free applications when the Facebook SDK is used twice as much as the Twitter4J Library. While their explanation of the significant difference in credentials found makes sense, a more reasonable explanation is that without using a server, it is impossible to implement a Twitter SSO without including the Consumer Key in the code.
While Twitter’s implementation of SSO has security advantages for web applications, it is dangerous for mobile applications. There are two clear options an API developer could use to make an authentication protocol: either you require the server to verify the Consumer Key and Secret during each step of the procedure, or you don’t, hoping that Mallory does not gain access to key information. The latter option, however, leads to many vulnerabilities as clearly seen with Facebook SSO. The first, seemingly more secure, choice causes mobile applications to sacrifice the security of an OAuth protocol.
Our paper on automated testing of web applications has been accepted to the 2014 USENIX Security Symposium. [Update: the final version of the paper is available here.]
It describes a black-box technique for automatically scanning web sites for vulnerabilties in how they implement Facebook Single Sign-On, and results from our experiments running it on thousands of websites.
You can try the scanner at SSOScan.org.
Yuchen Zhou will present the paper at USENIX Security in San Diego, 20-22 August 2014.
Security exploits nearly always stem from attackers finding ways to violate assumptions system implementers relied upon. As a simple example, consider a classic buffer overflow attack which is possible because the implementers assumed (perhaps implicitly) that the size of some data could not exceed the buffer size, but an attacker found a way to create an input that violates that assumption.
In this work, joint with colleagues at Microsoft Research, we consider the implicit assumptions upon which secure use of single sign-on SDKs depends. Our study of three important authentication and authorization SDKs (including Facebook’s) supports the need for systematically explicating SDKs to uncover these assumptions. We found assumptions that were critical to secure use of the SDKs, but that were not clearly documented and were subtle enough to be missed by the majority of tested apps.
We advocate that a systematic explication process for uncovering these assumptions should be part of the engineering process for developing security-critical SDKs.
For details, see our paper:
Yuchen Zhou presented Protecting Private Web Content from Embedded Scripts at ESORICS in Belgium.
His talk slides are here: [PPTX] [PDF]
Our paper on side-channel analysis of web applications is now available:
Peter Chapman and David Evans. Automated Black-Box Detection of Side-Channel Vulnerabilities in Web Applications. In 18th ACM Conference on Computer and Communications Security (CCS 2011), Chicago, IL. 17-21 October 2011. [PDF, 12 pages]
The paper describes a black-box tool for detecting side-channel vulnerabilities by analyzing network traffic over repeated crawls of a web application. Our tool quantifies the severity of side-channel leaks in a web application, and gives web application developers a measure of the risk of information leakage against different types of adversaries. The frequent and highly dynamic client-server communication that is characteristic of modern web applications leaves them vulnerable to side-channel leaks where an adversary can learn about the state of the application and visitor’s choices, even over encrypted connections. Our approach provides a new way to quantify the severity of these vulnerabilities based on analyzing the results of traces of the web traffic using the Fisher criterion.
Peter will present the paper at CCS in Chicago in October.
Several of our students presented posters at the USENIX Security Symposium Poster Session.
Sang Koo (with Yan Huang and Peter Chapman)
More Efficient Secure Computation on Smartphones
Brittany Harris and Jiamin Chen
Secure Computation with Neural Networks
Austin DeVinney and Yuchen Zhou
(with Jonathan Burket, Jenny Cha, and Casey Mihaloew)
Unifying Data Policies across the Server and Client
Samee Zahur
Exploiting Public Inputs to Optimize Circuits Used in Secure Computation Protocols