There were these headlines yesterday, for example in CNET, about a serious security flaw in OAuth & OpenID, with garish graphics claiming that Google and Facebook and Yahoo and, well, every other website you ever heard of, was vulnerable. I’ve been digging a bit and I still don’t know if there’s a there there; at the moment I think not. But I was left nauseated by the amateur-hour reporting.
The Heartbleed Connection · Heartbleed turned up earlier this spring, it was serious and scary and easily demonstrable and easy to understand; it had a cool name and a snazzy Web site with an eye-grabbing logo, and boy, did it get the world’s attention. I know people who were sort of disgusted with the slick packaging and logo-brandishing, but I was fine with that. What is marketing for if you can’t use it to help warn the world about bad problems?
Back to Covert Redirect · It’s got a logo! It’s got a Web presence. Oh good, let’s look there and figure out what the problem is. Um, nope, it’s just arm-waving. Oh look, there’s a link labeled “Reference” which leads to a another link labeled “Covert Redirect”, which leads back to the main page; oh no, wait, it just looks like the main page. Well, there are details, sort of, here’s the drill-down on Facebook. I understand OAuth pretty well and it’s really hard to figure out what’s being claimed.
I’m wondering what steps CNET took to validate this story, aside from checking out that yeah, there’s a web site with a fancy logo.
Fortunately John Bradley, one of the key architects of OAuth, did manage to spelunk through the narrative and gives us Covert Redirect and its real impact on OAuth and OpenID Connect His write-up isn’t accessible to non-OAuth-geeks, and I haven’t independently verified it myself, but I tend to trust John’s take on this stuff.
Possibly he’s figured out a workable exploit for Facebook’s federated-sign-in setup, but I can’t be sure yet.
Like John, I totally couldn’t figure out how the guy trumpeting the bug had managed to work around OAuth’s requirement to register redirect URIs. It seems to require an implementation that isn’t actually OAuth2-compliant (to be fair to Facebook, they’ve never claimed to do OAuth 2), plus some weird browser hackery to let server-side code get at #-fragments, plus the user has to cut-and-paste to attack themselves.
The guy reporting the attack has all these links which supposedly exhibit it working on the New York Times and GoDaddy and Amazon and so on; none of them do anything surprising when I click them.
But maybe not · Maybe John is wrong, and maybe there is a real vulnerability here, and if so, it deserves attention. I’ll keep an eye on this, and I’d encourage the guy reporting this to get help from someone with better communication skills.
If anyone has actual comprehensible verifiable technical research on this subject, please shout; I’ll update this post and pass the word on social-media channels.
And I’d encourage allegedly-tech-oriented publications to require a little more proof than a web presence and a logo before they start shrieking about vulnerabilities.
Comment feed for ongoing:
From: W^L+ (May 03 2014, at 11:05)
The only thing I've seen besides "OAuth & OpenID == BAD" is http://dannythorpe.com/2014/05/02/tech-analysis-of-serious-security-flaw-in-oauth-openid-discovered/
If that's all there is, I'd agree with you (and Danny) that this is much ado about nothing.
[link]
From: John Cowan (May 03 2014, at 19:52)
That would be "its real impact". 25 pedantry points to me!
[link]
From: Gavin B. (May 05 2014, at 00:01)
El Reg to the rescue:
http://www.theregister.co.uk/2014/05/05/covert_redirect_is_overt_hype_more_heartbleat_than_heartbleed/
@migueldeicaza Web sites dumb enough to implement an open redirect have lots of security problems. Less than 1% of web, IMO.
— Danny Thorpe (@danny_thorpe) May 3, 2014
[link]