Into the symmetry

Sure they are , if you do not user Firefox (even the last  version) or if you do not use iOs 6.1 or some older version of IE they are really safe :) In the last few days I got the pleasure to be in touch with the github security guys . I must admit I am really impressed about how security is important for Github and how much serious they take it (they embrace and leverage all the new security features supported by modern browsers, Content Security Policy included ). Moreover they are really fast on reply and really friendly so kudos to them. From the other hand I was a bit surprised on how the "handled" a couple of issues I did report. Now the fact I did not get a bounty doesn't play any role on my opinion (apparently both issues I reported were well known by them). The thing that does surprise me instead is the fact that even that those are well known issues are not yet fixed (if ever). But no more words just fact... The first issue I reported is the following....

Well well well, hacking time again :) No much time for big explanation but few weeks ago I was using a little variant of Lassie come home to potentially steal a valid Facebook's access token. In a nutshell reading a blog post of how the great Egor Homakov did hack Github  ( see Bug 1. Bypass of redirect_uri validation with /../ ) I though how about Facebook :) ?. Well here is what I found, I have copied a part of my report to Facebook security : The redirect_uri in the https://graph.facebook.com/oauth/authorize is not validated correctly. I can bypass the redirect_uri validation with /.\.\../. This might result on stealing the authorization code of a Facebook registered OAuth Client. As an example I would use Parse.com (that is owned by Facebook). In https://parse.com/account there is the chance to link an account with Facebook. Now the correct request is: https://www.facebook.com/dialog/oauth?response_type=code&client_id=506576959379594&redirect_uri=https%3A%2...

Leaving apart some FUDs I think that RFC 6749 (aka The OAuth 2.0 Authorization Framework) has proven to be a really great  "tool" so far. One of the limitation of this spec though is that the 2 main flows Authorization Code Grant and Implicit Grant work reasonably well if there is some sort of human interaction and the user agent is available. What if one or both of these requirement are missing? One easy alternative would be to use the Resource Owner Password Credentials Grant flow. This would require the OAuth client to know the Resource Owner password. That is exactly why OAuth has been designed namely to avoid such situation. Another, more tempting, alternative would be to use a refresh token (that never expires). The best choice though IMHO is to use "tools" from another specification from the becoming-big OAuth specification family :) The specification I am referring to is  the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and A...

Trying to continue the OAuth2 attacks saga started few months ago I am going to introduce a new kind of 'attack' named (by me, continuing the movie's name old tradition :D) 'The Postman Always Rings Twice'. I hope the reason of this name will be clear soon. In a nutshell the section 4.1.3 of the OAuth 2 core specification aka RFC 6749 says: The client MUST NOT use the authorization code  more than once.  If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. Now this is a really simple claim, but it turned out that two major providers as Facebook and Google violated it, until I did report the 'violation'. For this Facebook decided to reward me with a bug bounty (a while ago) and Google (only) with an honorable mention :(. Now you might wonder what is so dangerous on violating section 4.1.3 of the spec? Hopeful...

As the OAuth 2 framework is becoming more and more used I thought it would be useful to share some of the most common attacks. It is important to highlight that the attacks I am going to introduce today are not issues in the specification per se but rather possible implementation issues. The first document to look at when you try to secure one OAuth 2 implementation is the OAuth 2.0 Threat Model but this is way not enough. In order to have a safe implementation it is important to understand what is OAuth about and to be involved in the "OAuthsphere" (OAuth mailing list, blogs, etc), In this blog post I will try to show two of the most common attacks that I have renamed  ' The Devil Wears Prada' and 'Lassie Come Home'. Let's see. Firstly the actors: The Actors The Devil Wears Prada The first time I read about this potential issue was in one of John Bradley's blog post . This issue is also known as " confused deputy problem ...

Getting some inspiration from this dialog about OAuth 1.0 I thought it would be nice to have something similar for OAuth 2.0 The Actors   The R.O. shows intent Alice (R.O.): hey, Bob , I would like you to be able to access the profile pictures from my Facebook account so you can print for me a nice photo album. Bob (client): no problem, I know how we can do it. All I need is you getting me an Authorization Code from Facebook. The R.O. obtain an authorization code Alice (R.O.): hey Mark, www.printondemand.biz wants an Authorization Code Mark (server): are you sure you want to give this code to www.printondemand.biz ? this will allow it to get all profile pictures from your profile. Alice (R.O.): yes it is ok. Mark (server): ok I am sending you over to www.printondemand.biz The R.O. is redirected to the client Alice (R.O.): hey Bob here we go, this is the Authorization Code Bob (client): thanks The client exchange the Authorization Code for an Acce...

Lately I have been more and more involved with OAuth (at work and in my spare time with Apache Amber ) so before I forget some lessons learned I decided to put them here. First reminder to self:  OAuth is NOT an authentication protocol. It is an access delegation protocol. I hope this is clear to all the OAuth developers/implementators. Should you use OAuth for authenticate in your application/website you'd better be careful (specially if you use the client side flow aka implicit grant). If you wonder why give a look here and here . Risk: "access_token phishing" attack Mitigation : Use Open ID Connect or API like https://graph.facebook.com/app?access_token=YOUR_TOKEN To be continued... P.S. little off topic Apache Amber is now linked also from http://oauth.net/2/