There is a saying in cyber security that there are only 3 types of systems. Those that have been hacked, those that will be hacked and those that don’t know they’ve been hacked. So it’s a matter of time before your brand-new system falls under one of these 3 categories. How can we fight this gloomy fate?
I think a lot of people would agree that the best tool is awareness. Being aware of what can go wrong and having an idea of popular methods of attack. This can go a long way in the effort of making your system harder to penetrate. Bellow you can find some information about attacks identified in the scope of OAuth 2.0 threat model analysis. You can find the details here.
It’s not exactly a bed time story. I admit. But hopefully what I have listed below will interest you enough to familiarize yourself with other types of vulnerabilities. These types of attacks can be executed against other frameworks, systems and even your custom solutions if you are not aware enough to protect yourself from them.
Covert Redirect / Open Redirector
This attack is based on intercepting request coming from the client to authorization server and swapping redirect_uri of OAuth2 response to something else useful for an attacker. Response coming from authorisation server will often contain information that attacker can use to impersonate a client. The recommended security measure is making auth servers “allowed redirect Uris” list more restrictive. Don’t let wild cards in Uris, accept only full/complete Uris so that authorisation server will only talk to trusted clients. This prevents less experienced app developers and various custom build clients from registering *.com redirect Uris.
There are several attacks based on similar redirect logic that target clients utilising both IMPLICIT grant and CODE grant. If you want to know more about OAuth2 grants (and I think you should) please check this article. You can read about these attacks in section 3 of this IEFT document and here.
Referrer Headers
Famously misspelled “Referer” header is an automatically attached piece of information that browsers append (not in all circumstances) so that the destination site can tell where the request was sent from. Think website analytics solutions: they want to know where their audience is coming from. Simple piece of JavaScript code “document.referrer” can get you the content of this header and by extension any query string parameters that were a part of this Uri that may include for example authorization code!
Few examples of how attacker can exploit this are intercepting a request log of infected intermediate network device (headers are often stored in request logs) or injecting a link or a malicious advert on the client website. If user clicks this link or an add – the attacker who of course is in control of the destination server may easily intercept referrer header information.
Countermeasure for this type of vulnerability is adding rel=”noreferrer” attribute to links or making authorization codes one-time use. You can also add a meta attribute to a whole website like so <meta name=”referrer” content=” no-referrer”> and finally you could use the “url fragment” – given the standard RFC2616 (chapter 14.36) the fragment identifier (the last and optional part of the url after the # mark character) is not included in the referrer header.
You can find more information on the Referrer header here.
Browser History
When user is redirected via links from one site to another, there is a chance that this url will get stored in a browser history. If attacker has access to the device, he can retrieve this url and obtain access_code. This could happen on a PC infected by a malware that scans history for specific forms of urls. We can prevent this by using short expiry times for authorization codes, using one time authorization codes or by using OAuth2 Form-Post response mode. This way all the vulnerable information is encoded and passed in the body of the POST method which is not stored in the browser history.
More information on the Form Post Response Mode can be found here.
Clickjacking
It is basically creating a website, any kind of content and name – doesn’t have to be related to the website targeted by this attack. This website will have a transparent malicious iframe loaded on top of its content. This malicious iframe may contain “OAuth2 authorize access” page. If by any luck user is logged in the OAuth2 provider, this action may trigger OAuth2 provider to grant attacker access to some protected resource.
This attack compromised among others Twitter, Facebook and PayPal. There is a way to protect your OAuth2 provider from this. You need to add an X-FRAME-OPTIONS header to responses send to the client. This will tell browser that it should not allow request to be processed in context of any iframe.
As you can see attackers are very cleaver in exploiting http architecture and design choices of browser designers so you have to be equally informed about all sorts of attack techniques in order, not to land your client on the news. So please read as much as you can! Knowing 75% of security features of some framework like OAuth2 can be more dangerous than not knowing anything at all. With partial knowledge comes false sense of confidence which can be extremely harmful to businesses!
Finally, I tend to finish my articles with a quote, so here is one for today:
Any sufficiently advanced bug is indistinguishable from a feature. — Rich Kulawiec, with apologies to Arthur C. Clarke
Hope you enjoyed the read and as always leave your comments bellow.