Open source security software has had a rough 2014 so far. Flaws in GnuTLS and the OpenSSL cryptographic library cast doubt on the common assertion that projects with code that can be viewed and debugged by the developer community are inherently more secure than proprietary solutions. Still, despite these revelations, open source development is going to be a core component of cybersecurity for the foreseeable future, as it leverages a tremendous range of technical knowledge and skill and is highly economical, to boot.
That said, there needs to be renewed attention toward ensuring that open source projects are secure and that their stewards have the resources they need to make code as secure as possible. Heartbleed alone, which affected a wide swath of all Web servers, should have been impetus enough to rethink open source development, but now there's the added impact of security flaws in certain business implementations of both OAuth and OpenID. These authorization and identity protocols are used by some of the most prominent Web companies, including Google, Microsoft, GitHub, PayPal and Yahoo.
"The vulnerability could lead to open redirect attacks to both clients and providers of OAuth 2.0 or OpenID," stated mathematics Ph.D. candidate Wang Jing, who discovered the issues, according to Dark Reading. "Almost all major OAuth 2.0 and OpenID providers are affected, such as Facebook, Google, Yahoo, LinkedIn, Microsoft, PayPal, GitHub, QQ, Taobao, Weibo, VK, Mail.Ru, Sohu, etc."
Unlike Heartbleed, which was quickly patched with updated code and reissued SSL certificates, these exploits are more technically challenging and their effects could linger for some time. In theory, creating and strictly enforcing a whitelist for the scores of third-party applications that integrate with OAuth and OpenID would ameliorate the new security concerns, but in reality it is virtually impossible to ensure consistency in how these protocols are used.
What's the problem with OAuth and OpenID implementations?
The problem is not inherent in OAuth or OpenID, but in how some organizations have implemented these standards. Essentially, users may be at risk from malicious parties that use legitimate companies' API keys to extract sensitive information.
Last month, before Wang's findings were made public, LinkedIn engineer Shikha Sehgal advised software makers currently using LinkedIn APIs to register their application redirect URLs with LinkedIn to optimize security and improve OAuth 2.0 compliance. Sehgal stressed the importance that each "OAuth 2.0 authorization request matches a URL you've provided to us in advance."
If there is no match, then it is possible that anyone logging in could be redirected to harmful sites that are instruments in phishing campaigns. For example, users would click on a link and then be prompted to authorize an application. The efficacy of this approach is heightened by usage of the actual site address rather than a fake one created only for phishing.
If they choose to do so, then items such as their email addresses, names and birthdays would be yielded to the phisher rather than the Web property being mimicked. Further damage could be caused at the websites to which the open-redirects sent them.
Flaws are not new, but organizations fall short in addressing them
All of these dangers are well documented, and the OAuth and OpenID standards have been codified with security recommendations for anyone who implements them. Unfortunately, many of these suggestions are ignored or contradicted.
Features such as whitelists that limit the domains to which open-redirects can point have been made into optional – rather than core – features on sites such as Facebook. Some developers also add access tokens to HTTP requests, but attackers can inject JavaScript to remove them and log into the site as the user.
In addition to these whitelist and token issues, there is the underlying problem of how developers set up authentication for Web applications and clients. Dark Reading contributor Mathew Schwartz noted that a lot of applications grant a Web browsers access based on its user's previous authorization of it, a practice known as implicit flow.
However, this technique is not well suited to handling open-redirect manipulation and should, in many instances, be replaced by code flow, a process that requires additional API calls. Service providers such as Deutsche Telekom have demonstrated that code flow can mitigate risk from malicious redirects.
The OAuth and OpenID flaws and the overall outlook for Web security
Why are so many implementations of OAuth and OpenID riddled with vulnerabilities? Part of the issue is that the third-party websites that utilize these protocols may have little incentive to invest in cybersecurity.
From their perspectives, the platforms through which users are being authenticated – Facebook, Google et al – could be seen as being responsible for allowing cybercriminals to co-opt their authority and appearance in order to trick end-users. On top of that, practices such as code flow can incur new costs for organizations that may be financially constrained and/or unwilling to be saddled with additional financial burdens.
There's also the issue of how any changes to the status quo could impact user experience. Individuals may develop negative perceptions of major Web companies' services and the third-party sites that integrate with them.
"While I can't be 100 percent certain, I could have sworn I've seen a report of a very similar if not identical vulnerability in OAuth. It would appear this issue is essentially a known WONTFIX," stated WhiteHat Security CEO Jeremiah Grossman, according to CNET. "This is to say, it's not easy to fix and any effective remedies would negatively impact the user experience. Just another example that Web security is fundamentally broken and the powers that be have little incentive to address the inherent flaws."
It is also worth noting that OAuth and OpenID are open standards, and as such are naturally prone to being modified by organizations to meet their respective needs. But while many contributors to and users of these projects (and similar ones such as OpenSSL) have gained significant revenue from them, they have refrained from providing much financial support to these same efforts.
Dr. Dobb's editor-in-chief Andrew Binstock recently looked at this issue in the context of Heartbleed and bemoaned the lack of monetary contributions by some major implementers of open source software. With the OAuth and OpenID issues, it is worth taking a similar line of thought toward security in open source projects, so that developers, organizations and end-users can have the safest experiences possible.
