A JISC-funded project
//The Linkey project has two main deliverables:
Here is our case study.
Download the Case Study (PDF)
Read the Case Study online (Google Doc)
We welcome comments on the Case Study and invite you to leave them here on this blog post. Alternatively, you can contact us directly.
//Last week self-proclaimed web security evangelist Egor Homakov published a blog post entitled How we hacked Facebook with OAuth2 and Chrome bugs. Naturally this led to a new round of “OAuth 2.0 is unsecure” comments on news articles that linked to the post.
If you actually read through the post however, the part of the attack that involves OAuth is this bit (emphasis from original text):
2) OAuth2 is… quite unsafe auth framework. Gigantic attack surface, all parameters are passed in URL. I will write a separate post about OAuth1 vs OAuth2 in a few weeks. Threat Model is bigger than in official docs.
In August 2012 I wrote a lot about common vulnerabilities-by-design and even proposed to fix it: OAuth2.a.We used 2 bugs: dynamic redirect_uri and dynamic response_type parameter.
response_type=code is the most secure authentication flow, because end user never sees his access_token. But response_type is basically a parameter in authorize URL. By replacing response_type=code to response_type=token,signed_request we receive both token and code on our redirect_uri.redirect_uri can be not only app’s domain, but facebook.com domain is also allowed.
In our exploit we used response_type=token,signed_request&redirect_uri=FB_PATH where FB_PATH was a specially crafted URL to disclose these values..
If an OAuth 2.0 authorisation server is correctly configured then it should, in addition to numerous other checks, ensure that there is only one value in the response_type parameter (e.g. “code” – if using the authorization code grant) and the server should store whitelisted redirect URIs for each client on the server so that attacks can’t be launched with dynamic URIs.
I suspect partly why this has happened to Facebook is because when they launched their Graph APIs back in 2010 they secured them with draft 5 of the OAuth 2.0 specification. As the specification changed over it’s 27 drafts they already had clients hardcoded with specific parameters that couldn’t be updated easily and so therefore they had to make a choice to allow the above parameters that were used in the attack to accept dynamic and non-canon values.
The OAuth 2.0 server library I’ve developed is not vulnerable to the aforementioned attack as it strictly validates and verifies every parameter that is sent to it and redirect URIs are whitelisted on the server.
//The OAuth website describes OAuth as:
An open protocol to allow secure API authorisation in a simple and standard method from desktop and web applications.
Essentially OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.
OAuth grew out of discussions between developers from Twitter and Ma.gnolia who wanted to authorise desktop applications to access their services. A working group was formed in 2007 to draft a proposal for an open standard. Developers from both Google and Yahoo also contributed to this work.
The first OAuth Core 1.0 draft was released in late 2007. In 2008 it was decided that the Internet Engineering Task Force (IETF) would adopt the specification to allow wider discussion and further standardisation work.
A minor revision (OAuth 1.0 Revision A) was published in June 2008 to fix a security hole. The OAuth 1.0 Protocol was published by the IETF OAuth Working Group in April 2010 as RFC 5849.
A number of Internet companies and services adopted OAuth 1.0 but it was considered too much of a pain in the arse to work with by developers because it involved complicated signatures being passed around and there were too many requests between clients and services.
In May 2010 work began on version 2.0 of the OAuth protocol. Version 2.0 is not backwards compatible with OAuth 1.0a and focuses on developer simplicity. It also features more flows to allow the use of OAuth in more situations, as well as extensions to the core protocol to enable interoperability with assertion based protocols such as SAML.
OAuth has been adopted by many large Internet services and companies, here are some to name a few:
We have been using OAuth 2.0 here at the University of Lincoln since late 2011 where we investigated using it for the Total ReCal project so that students here at the university could access their event data. Our implementation was based on some work I’d already been doing in the area based in my own time.
We currently have over 30 application using OAuth to interact with our data sets including the Student Union website, the staff directory, Orbital, and four 3rd year student final projects.
In October 2011 I spoke at EduServ’s Federated Access Management conference about how OAuth works and how we are using it. The slides for this presentation can be found at https://speakerdeck.com/u/alexbilbie/p/introduction-to-oauth.
During the Linkey project I’m going to be redeveloping my CodeIgniter OAuth 2.0 server to a be a framework-agnostic Composer package. I’m also going to be adding support for the bearer extension and the assertions extension.
//Microsoft Forefront Unified Access Gateway (UAG) is a piece of server side software which provides secure access to corporate networks, systems and applications. It incorporates a number of different access technologies including VPN, HTTP reverse proxies and the Microsoft-developed technologies DirectAccess and Remote Desktop Services. Remote clients can access these corporate resources through a special web site that is hosted on an IIS server which is bound to the UAG software.
UAG includes built integrations for Microsoft Exchange Server (2003, 2007 and 2010), SharePoint Server (2003, 2007 and 2010), Remote Desktop Services and Citrix Presentational Services. It also includes a technology called SSL-VPN which allows for authentication integration with most 3rd party and custom software.
UAG can use a number of different authentication sources including Active Directory, LDAP, RADIUS and SecurID. Finally it can also “speak” SAML and ADFS.
Microsoft identifies a number of benefits of using UAG:
Forefront Unified Access Gateway (UAG) is designed to provide secure remote access in a way that extends application intelligence, security and control, and ease of use. Key benefits include:
Anywhere Access
Forefront UAG makes it easier to deliver secure remote access to your applications and resources, and improve employee and partner productivity, by combining an intelligent access policy engine with a variety of connectivity options including SSL VPN and Direct Access. Forefront UAG:
Empowers employees, partners, and vendors to be productive from virtually any device or location through integrated SSL VPN capabilities.
Delivers simple and secure access optimised for applications such as SharePoint, Exchange, and Dynamics CRM.
Extends networking connectivity with Windows Direct Access to existing infrastructure and legacy applications.Integrated Security
Forefront UAG improves the security in remote access scenarios by enforcing granular access controls and policies that are tailored to the applications being published, the identity of the user, and the health status of the device being used. Forefront UAG further improves security by enabling strong authentication to applications and mitigating the risks of downloaded data from unmanaged devices. Forefront UAG:
Protects IT assets through fine-grained and built-in policies that provide access to sensitive data based on identity and endpoint health.
Easily integrates with Active Directory and enables a variety of strong authentication methods.
Limits exposure and prevent data leakage to unmanaged endpoints.Simplified Management
Forefront UAG offers a single platform through which to deliver and manage remote access. With built in policies and configurations for common applications and devices, you can gain more control, more efficient management, greater visibility, and lower total cost of ownership. Forefront UAG:
Consolidates remote access infrastructure and management.
Simplifies deployment and ongoing tasks through wizards and built-in policies.
Reduces support costs by delivering a simplified connectivity experience for users.Source: http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx
At the university we have a number of existing web based applications which will benefit from having UAG integration.
We currently have SharePoint and Exchange 2003 installations (which will soon be upgraded to 2010) which UAG can natively integrate with.
We use Blackboard Learn as our LMS and Zendesk as our support desk software, both of which have can use SAML for single sign on.
We are also looking into potentially using UAG as the access point for Windows 7 thin client access.
As UAG can use SAML to communicate with services it means that we can use the OAuth 2.0 assertions specification to create a translation framework between SAML assertions and OAuth tokens. This will extend some of the work that we’ve originally done on our OAuth server and the updated code will be published.
One of the outcomes of this project will be a case study (with open source code examples) on how UAG and an OAuth server can work together (though because we don’t know how this may work at the moment it could be that it turns out they can’t work together…) and on this blog we will document our experience.