Into the symmetry

tl;dr I found an  XSRF in the OAuth implementation of Redhat Keycloak Gatekeeper . This would be a bit worse for people using Gatekeeper to protect their Kubernetes Dashboard (especially in Microsof Azure). The Issue in Keycloak Gatekeeper Keycloak Gatekeeper is an OpenID Proxy service for Keycloak , an Identity and Access Management solution developed and opensourced by RedHat (now IBM).  Solutions like this are often used to protect things like Kubernetes Dashboard (unless you want to do like Tesla and expose your Kubernetes Dashboard unauthenticated to the internet ) and this (for the record) is why I came across to the issue. I will postpone a deeper analysis of the Kubernetes Dashboard to a future post. The issue is dead simple and I already talked about this several times . This was also  defined by Egor Homakov as the the Most Common OAuth2 Vulnerability (and it looks he was right :p) . Basically the Keycloak Gatekeeper   developers forgot to...

tl;dr   Facebook Groups offers the option to upload files directly from the Dropbox account. This integration is done using the OAuth 2.0 protocol and suffered from a variant of the classic OAuth CSRF (defined by Egor Homakov as the the Most Common OAuth2 Vulnerability ),  see video below: Introduction  Facebook Groups offers the option to upload files directly from the Dropbox account: This will allow to surf via browser the Dropbox account  and post a specific file to the group.  This integration is done using a variant of the OAuth 2.0 protocol seen in this blog many many times . But once more, OAuth is an access delegation protocol standardized under the IETF umbrella . A typical OAuth flow would look like: From “OAuth 2 In Action” by Justin Richer and Antonio Sanso, Copyrights 2017 Usually the client initiates the OAuth flow in the following way: From “OAuth 2 In Action” by Justin Richer and Antonio Sa...

If you bought the book I have been writing with Justin Richer namely OAuth 2 in Action you might have noticed that we will never got tired to stress out how much important the redirect_uri is in the OAuth 2 universe. Failing to understand this (rather simple) concept might  lead to disasters. The redirect_uri is really central in the two most common OAuth flows ( authorization code and implicit grant ). I have blogged about redirect_uri related vulnerability several times and both in OAuth client and OAuth server context.  Developing an OAuth client is notoriously easier to develop compare to the server counter part. Said that the OAuth client implementer should still take care and master some concepts.  If I would be limited to give a single warning for OAuth client implementer this would be  If you are building an OAuth client,   Thou shall register a redirect_uri as much as specific as you can or simply less formally " The registe...

In a previous blogpost we have already analyzed a token hijack on one OAuth integration between some Microsoft and Google service and seen what went wrong. Now it is time to see yet another integration between Microsoft and xxxx (unluckily I can't disclose the name of the other company due the fact the haven't still fixed a related issue...) and see some fallacy. But before to focus on the attack we might need a bit of introduction. HTTP referrer An HTTP referrer (misspelled as referer in the spec) is a special HTTP header field that browsers (and http clients in general) attach when surfing from a page to another. In this way the new webpage can see where the request originated. One extra thing to point out is that as per section 15.1.3 (Encoding Sensitive Information in URI's) of HTTP RFC [RFC 2616]: Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. This is summarized ...

Here we go again.... I have already blogged about (OAuth) token hijacks [1] [2] , but hey, things happens and re-happens :) In the past I had mainly focused my attention on Authorization Servers weakness. As the cited Facebook's vulnerable regex pattern matching for redirect_uri. It turns out that also OAuth client can screw things up and leak token (or authorization codes). So here is the tl;dr: If you are building an OAuth client,   Thou shall register a redirect_uri as much as specific as you can i.e. if your OAuth client callback is https://yourouauthclient.com/oauth/oauthprovider/callback then DO register https://yourouauthclient.com/oauth/oauthprovider/callback   NOT JUST h ttps://yourouauthclient.com/ or https://yourouauthclient.com/oauth The main reason behind this is that sometimes Authorization Server (AS) use exotic and unexpected redirect_uri validation policies. As mentioned in some previous post the ONLY safe validation method the Auth...

Heya, back to my favourite topics namely OAuth . I have previously discussed about common  OAuth 2 Implementation Vulnerabilities but now it is time (maybe) to list those and order them based on their criticality. #5 The Postman Always Rings Twice  I have introduced this 'attack' in last year post . This is for provider implementer , it is not extremely severe but, hey, is better to follow the spec. Specifically 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. It turned out that even Facebook and Google did it wrong ... :) #4 Match Point To all OAuth Providers be sure to follow section 4.1.3 of the spec in particular ...if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if...

Usually my (not too many :( ) posts are written for a technical audience (not t o o big :( ). This time, given the fact October is Cyber Security Month I will try to put some effort to try to explain how you can keep yourself away from annoyances. Well the rule of thumb is actually extremely simple and can be resumed with a simple sentence:  Beware what you click Let me repeate it: "beware what you click" :) Just following this simple rule you can avoid 90% of scam/viruses and phishing attacks . But lets do a step back. Assuming you know already what is a computer's virus let me explain what is a phishing attack. Phishing scam uses legitimate-looking websites to trick a victim into sharing their username, password or other  sensitive information. Pishers will design their sites to look exactly like e.g. the website of your mail provider, your bank, credit card issuer, or another financial institution. The hope is that you won't realize you...

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 ...