CNet is reporting that all OpenID and OAuth sites are vulnerable to an attack called "Covert Redirect". What is this attack, how does it work, and as an end user, how can I mitigate the risk?
This isn't a vulnerability of/in OAuth 2.0 at all. The issue has been wildly overblown and misstated by CNET and the original finder.
Here it is in a nutshell: If your web site (example.com) implements an open redirect endpoint - that is, implements a URL that will redirect the browser to any URL given in the URL parameters - AND your redirect copies URL parameters from the incoming URL to the outgoing redirect URL, then it is possible for third parties to exploit this artifact of your web site in a wide variety of nasty ways.
Worst case: evil.com is able to get the auth code originally intended for your web site (example.com) and may be able to use that auth code to extract user information from the auth provider (Google, Facebook, etc) or possibly even take control of the user's account on your web site.
Would evil.com be able to take control of the user's Google account using that access code? No, because the access code was minted for your site, example.com, and only works there.
Who's fault is it? Yours, for implementing an open redirect on your site. Don't blame Google or Facebook or others for your poor implementation.
There are a few legitimate use cases for having a redirect on your site. The biggest one is to redirect the browser after login to the web page (on your site) that the user originally requested. This only needs to redirect from your web site to pages in your web site, on your domain.
How to fix it? Have your redirect endpoint (example.com/redirect?&destination=ht.tp://foo.com...) validate the destination URL. Only allow redirects to pages on your site, in your domain.
Update: There is an open redirect issue when using Facebook for OAuth user login. When you configure your app definition on Facebook, be sure to enter your domain-specific redirect URL in the redirect field provided. Facebook allows this field to be left blank. If left blank, Facebook itself acts as an open redirect while processing user logins for your web site.
Facebook should fix this by simply not allowing the redirect URL field to be left blank.
As others have stated, this is not a new idea. Eran Hammer (one of the creators of the Oauth 1.0 spec, who resigned from the Oauth 2.0 committe) wrote a good synopsis of the vulnerability, almost 3 years ago. His description didn't get a fancy logo or any sensational media coverage.
Here is a Youtube video the original finder put together leading you through the vulnerability: https://www.youtube.com/watch?v=HUE8VbbwUms.
OpenId and OAuth both provide a field that allows a third-party site to specify a redirect when authentication has completed and is successful. For instance, you go to Good Reads, they want you to login with your Facebook account. Good Reads will tell Facebook, "hey, when the user authenticates successfully, redirect them back to http://goodreads.com." The vulnerability is that some of these third-party sites allow redirects to be specified in their URLs (http://google.com/redirect?url=http://attacker.com) and may not validate them before they redirect the user. So, an attacker could create a "Login with Facebook" link for a valid site like Good Reads and could specify the redirect url to be something like http://goodreads.com/redirect?url=http://attacker.com (assuming Good Reads did this kind of redirect), your Facebook login popup would show that Good Reads (a perfectly normal site for you to be going to) wants to authenticate with Facebook, but when you authenticate and redirect back to Good Reads, if Good Reads doesn't validate the redirect URL, you'll be immediately redirected to http://attacker.com.
The fix would be for third-parties to validate redirects, but that may take a while to happen. The other thing is, CNet has reported that attackers might be able to steal information through this little interchange, but I'm not quite sure if that is possible. Someone else can comment on the matter. But, getting a user to a bad site is probably good enough for them.
This is a form of man in the middle attack where a site can grab your OpenID credentials. It works because the sources of openID (facebook, google, etc) do not perform sufficient checks when openID queries are sent.
There's nothing you as the user can do about it, all you can do is be very wary about using Oath and openID. If a site you wouldn't expect to use openID pops up an openID window then don't allow it. If you suspect that your openID credentials have been captured go to the authentication source (facebook, google, whatever) and change it there as soon as possible.
From the website,
Covert Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT SUFFICIENT validation. This is often the of result of a website’s overconfidence in its partners.
In another word, the Covert Redirect vulnerability exists because there is not sufficient validation of the redirected URLs that belong to the domain of the partners.
So imagine I executed some form of phishing link that you opened. Let's say I pretended to be your bank. Under normal conditions, I'd have to create a spoofed domain to trick you. www.y0urb4nk.com and hope you clicked the link. With the Covert Redirect attack, an attacker exploits Oath/OpenID to use the actual bank's info to pull off the phish for me. Instead of me using y0urb4nk.com I can now use yourbank.com (the actual site) to pull of the hack. This is the flaw explained.
So in an nutshell:
attacker [ exploit oauth/openid ] generate phishing attack send vulnerability to target domain is legitimate attacker abuses this user falls for exploit and enters data now send this data to attacker instead of legit domain game over
Fix? Short term would be to stop using OpenID/Oauth until a fix is found