This article will deal with the well-known Oauth vulnerabilities. Readers will also learn how to implement safe and secure authorization in the web application.
OAuth is a reliable protocol, but its degree of security largely depends on the awareness of web developers when implementing authorization. This makes this topic extremely important for information security professionals. They need to provide a high level of protection of accounts of their users. It is time to get acquainted with effective practitioners who will help reduce the danger of poor selling Oauth.
IntroductionOAUTH 2.0 protocol is currently widely used in various applications. Using it, a convenient user interface becomes available, easier authentication and authorization compared to traditional methods for entering the username and password. With proper and thoughtful implementation, the OAuth protocol will be safer than traditional authorization, since users do not need to share their accounting data with a third-party application to access a specific resource. Users often prefer to log in using their Google accounts, Facebook or LinkedIn, instead of creating a new account every time you need to register on some web site. Thus, the Oauth protocol greatly simplifies our lives.
In general, popular OAuth service providers are very reliable. Log in with Google or Facebook account inspires a certain sense of security, and it is correct. The protocol is carefully tested by experts. All available vulnerabilities are always quickly corrected by the developer team. However, it is worth noting that the feeling of complete safety can be false.
OAuth service providers left application developers a lot of reasons to contend the safety of their programs. In fact, the initially protected OAuth service, incorrectly implemented in the process of its installation, can become an easy target for intruders. Such preoccupacy will lead to the theft of personal data of users.
Next, you should consider the most common vulnerabilities encountered in third-party applications that implement OAuth Protocol to authorize their users. It must be remembered that the protocol itself is safe and reliable. Only after incorrect implementation, it becomes vulnerable to hacker attacks.
OAuth Tockey Theft Using the Referer headerWhen the application requests authorization on behalf of the user at the Oauth server, a person receives the code to enter and send back to the server for its subsequent check. If during the work the user will be redirected to another page, the code will be seen in the "Referer" header of the HTTP request. Thus, the code will fall on the external website, which will threaten the user data registered on the OAuth server.
Note: The Referer header is an HTTP query header, it transmits the URL host from which the request is sent.
To soften the consequences of this vulnerability, the developer must make sure that its web application does not contain any HTML injections. If the injections were detected, the attacker can easily set the image tag to its web server and find a way to redirect the user on it. Thus, he will get the opportunity to steal the code from the "Referer" header of the HTTP request.
OAUTH Tockey Theft Using the Redirect_uri parameterThe application initiates the authorization process by sending a request to the OAuth server:
https://www.example.com/signin/authorize?[...]&redirect_uri=httpps://demo.example.com/loginsuccessful.
The query always contains the "Redirect_uri" parameter used by the Oauth server to send tokens back to the application after the user gave his consent. If the value of this parameter is not controlled or not checked, the attacker can easily change it and redirect the request to its website, where it uses a special program for processing the token and gain access to a limited resource.
https://www.example.com/signin/Authorize?[...]&redirect_uri=httpps://localhost.evil.com.
Sometimes similar URLs are blocked. The attacker can redirect the received data on the open URL, like this:
https://www.example.com/oauth20_authorize.srf?[...[&redirect_uri=httpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com.
Or this:
https://www.example.com/oauth2/authorize?[...] %irect_uri=https%3A%2F%2Fapps.facebook.com%2FatTacker%2F.
When implementing Oauth, you can never include whole domains in the white list. Only a few URLs should be added to "redirect_uri" not redirected a request to Open Redirect.
Forgery of cross-line requestsForgery of an intersight request may occur when an attacker succeeds in making the victim to click on his link and, thus, to generate a request that he was not going to generate. Forgery of cross-line requests is usually softened with the CSRF token, which is associated with the user session. It helps the application to check the person of a person who sent the request. The "STATE" parameter in the OAuth protocol serves as CSRF token.
It is worth viewing how the CSRF attack is carried out on Oauth and as the "State" parameter can be used to mitigate the effects of vulnerability.
Hacker opens a web application and launches the authorization process to access the service provider using Oauth. The application requests a service provider to access that needs to be provided. Hacker will be redirected to the service provider website, where you usually need to enter your username and password to authorize access. Instead, the hacker catches and prevents this request and saves its URL. Hacker somehow causes the victim to open this URL. If the victim entered the service provider's system using its account, then its credentials will be used to issue an authorization code. The authorization code exchanges access to the access token. Now the Hacker account in the application is authorized. It can access the victim's account.
So, how can I prevent this situation using the "State" parameter?
The application must create a value that is somehow based on the source account (for example, use the user session hash key). It is not so important what it is, the main thing is that the value is unique and generated using private information about the original user. It is assigned to the "State" parameter.
This value is transmitted to the service provider when redirecting. Now the hacker invites the victim to open the URL, which he retained.
The authorization code is issued and sent back to the client in the session along with the "State" parameter.
The client generates a parameter value based on a session information and compares it with the "State" value, which was sent back from the authorization request to the service provider. This value does not match the "state" parameter in the query, since it has been generated only on the basis of information about the current session. As a result, the obtained value is not accepted by the system.
Other vulnerabilities detected when implementing Oauth include the ability to perform XSS (cross-site scripting) using the "Redirect_uri" parameter, the OAUTH Private Key setting (the key can sometimes be obtained when decompiling a mobile application) and Authorization Code Rule Violation (when the authorization code can To be used more than once to issue multiple access tokens). These vulnerabilities are less common than those described above, but it does not make them less dangerous. The developer should know all the necessary practices to ensure reliable operation of its web application.
The author of the translated article: Simon Saliba.
Important! Information solely for academic purposes. Please comply with legislation and do not apply this information for illegal purposes.
More interesting material on cisoclub.ru. Subscribe to us: Facebook | Vk | Twitter | Instagram | Telegram | Zen | Messenger | Icq new | YouTube | Pulse.