Nasty Security Flaw In OAuth, OpenID 18
jones_supa writes: "A notable security vulnerability has been discovered which impacts both OAuth and OpenID, which are software packages that provide a secure delegated access to websites. Wang Jing, a Ph.D student at the Nanyang Technological University in Singapore, discovered that the 'Covert Redirect' flaw can masquerade as a login popup based on an affected site's domain. Covert Redirect is based on a well-known exploit parameter. For example, someone clicking on a malicious phishing link will get a popup window in Facebook, asking them to authorize the app. Instead of using a fake domain name that's similar to trick users, the Covert Redirect flaw uses the real site address for authentication. If a user chooses to authorize the login, personal data will be released to the attacker instead of to the legitimate website. Wang did already warn a handful of tech giants about the vulnerability, but they mostly dodged the issue. In all honesty, it is not trivial to fix, and any effective remedies would negatively impact the user experience. Users who wish to avoid any potential loss of data should be careful about clicking links that immediately ask you to log in to Facebook or Google, and be aware of this redirection attack."
Not an inherent problem. (Score:5, Informative)
Ehh...
First of all, this isn't new. Hell, it's in the RFC [ietf.org]. In fact, the RFC specifically details and recommends protecting against it in [ietf.org] several [ietf.org] places [ietf.org].
This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.
The service providers are supposed [ietf.org] to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.
So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.
That said, if they performed some meager sanitization, it could go a long way to improve the situation.
Re:I thought everyone knew this (Score:5, Informative)
Oh snap, I just realized where this would get people real hard. Paypal. You click a link to buy with Paypal, but they send you to a PaypalURL to login, but keep your data... Yah, that one could bite. I guess it really is a good heads up. I'll no longer use anyone's paypal links unless I highly trust the site. Thankfully I at least have the 2nd factor security authentication, but not everyone has that.
I solve that problem by not linking my Paypal to a bank account. If someone hacks my paypal account, they can......use their own credit card to pay someone.
Not linking Paypal to a bank account solves a lot of other problems too, where Paypal is known to be the rogue actor.