Oauth is one of the most popular and widely used open standards for authorization. Most of the big players in field of IT like Facebook, Google, Yahoo, Twitter and many more use different variants of oauth for providing secure access to resources hosted on their respected servers. Thanks to oauth only now there are thousands of third party apps getting developed for various social networking sites.
That being said, there are certain security issues while implementing oauth which might compromise user data as well as third party app developer’s data. So here in this article we will study some of the issues, scenarios where any attacker can exploit any weak link in security and measures to improve security in oauth implementations.
Brief Introduction and Terminologies: Oauth is an open-web specification for organizations to access protected resources on each other’s web sites. This is achieved by allowing users to grant a third-party application access to their protected content without having to provide that application with their credentials (i.e. username/password). Oauth is complementary to OpenID protocol, which deals with authentication. In order to understand complete oauth flow one can check the link http://tools.ietf.org/html/rfc6749 and read latest oauth specs.
Here are some of the terms used in oauth:
- Resource Server or the Resource Provider is a web site or web services API where User keeps his/her protected data.
- Authorization Server is the server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
- User or the Resource Owner is a member of the Resource Provider, wanting to share certain resources with a third-party app.
- Client or Consumer Application is typically a web-based or mobile application that wants to access User’s Protected Resources.
- Client Credentials are the consumer key and consumer secret used to authenticate the Client.
- Tokens are the access token generated by server after request from client using which a client app access certain portion of user data.
Now we will have a look about the security challenges related to oauth2. It is important to note that like most other protocols, OAuth does not provide native security nor does it guarantee the privacy of protected data. It relies on the implementer of OAuth, and other protocols such as SSL, to protect the exchange of data among parties. So most of the challenges are not due to protocol itself but because of its implementation and use.
- Phishing and Lack of server trust: Oauth is mainly about validating the client (using client id/secret) but there is no well-defined mechanism to validate authenticity of server during connection. So essentially, through phishing or other exploits (like DNS or ARP spoofing), user requests can be directed to a malicious Server where the User can receive malicious or misleading payloads. This could adversely impact the Users, but also the Client and Server in terms of their credibility and bottom-line.
Solution: As recommended approach the authorization and resource servers should be on HTTPs (i.e. using TLS/SSL) with certs being issued from a trusted authority. Apart from that, the clients who register themselves as third party app developers should ideally provide redirect uri on https instead of http. However, having servers on https alone doesn’t solve the purpose. Oauth1 had signatures while making calls to servers, which was removed in oauth2 in favor of using secure (https) connections. But even HTTPS alone cant help prevent phishing attacks because anyone can get an SSL certificate and show the secure icon in the browser. The fact you are using a secure channel doesn’t mean the entity on the other side is good. It just means that no one else can listen in on it (just the bad guys). If a client sends their bearer token to the wrong place, even over HTTPS, it’s game over. So its basically left on clients who need to be educated enough to make sure they are registering and calling right server. Also, servers should not issue secrets for clients without proper security clients. Most of the oauth flows don’t ask for end user username/password so client apps should avoid asking for such info from users while trying to get consent.
- SQL Injection: In oauth flows, authorization servers as well as resource servers are required to keep third party apps data as well as user data. Along with that they also need to store authorization codes/access tokens along with their scope, time duration and other related information. An attacker may try to obtain application data, user data or access tokens from server’s database by gaining access to the database or launching a SQL injection attack.
Solution: Its highly recommended that all type of credentials are stored in encrypted way or with hash in database. Also, there should be proper validations done to take care of SQL injection related threats.
- Redirector Related Issues: As part of third party app registration process on the authorization server the app developer is required to provide a redirect uri. This is the end point where tokens/auth codes are being sent after user consent. An attacker could use the redirection URI parameter to abuse the authorization server as an open redirector. An open redirector is an endpoint using a parameter to automatically redirect a user-agent to the location specified by the parameter value without any validation.
Solution: In order to counter open redirector issue the authorization server should always make developers register complete redirect uri (and not a part) and it should always be validated on request. While validation the redirect uri in request parameter should be exactly same as the one provided during app registration. Also, if redirect uri is not valid or missing in the request, then the error messages should not be redirected to the registered redirect uri for that client app.
- CSRF Attack: Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the User. An attacker could authorize an authorization code to their own protected resources on an authorization server. He then aborts the redirect flow back to the client on his device and tricks the victim into executing the redirect back to the client. The client receives the redirect, fetches the token(s) from the authorization server and associates thvictim’s client session with the resources accessible using the token.
Solution: This CSRF vulnerability was found in various sites including Facebook. In order to avoid such attacks a client must send a state parameter while sending requests to auth server. The client should utilize the “state” request parameter to send the authorization server a value that binds the request to the user-agent’s authenticated state (e.g. a hash of the session cookie used to authenticate the user-agent) when making an authorization request. Once authorization has been obtained from the end-user, the authorization server redirects the end-user’s user-agent back to the client with the required binding value contained in the “state” parameter. Also, clients as well as end users should be educated about not following untrusted urls or clicking on untrusted links.
- Impersonating Resource Owner: A normal authorization flow normally involves a request to authorization end point, then user verification/aurthentication( in few cases of user is not logged in ), then user consent to grant access for his protected resource and finally creation of code and/ or access token depending upon flow. A malicious client might embed a hidden HTML user agent, interpret the HTML forms sent by the authorization server, and automatically send the corresponding form post requests. As a pre-requisite, the attacker must be able to execute the authorization process in the context of an already authenticated session of the resource owner with the authorization server.
Solution: In order to counter such issues, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. For example it can embed password authentication and user consent in a single form, or can make use of CAPTCHA or one time password authentication ( by sending PIN to registered mobile number of user) if required.