08 Possible Security Vulnerabilities When Practicing OAuth 2 #
Hello, I am Wang Xindong.
When you learned that the topic of this lecture is security vulnerabilities in OAuth 2.0, you might wonder, “Isn’t OAuth 2.0 a security protocol designed to protect Web APIs? Why does OAuth 2.0 have its own security issues?”
First of all, OAuth 2.0 is indeed a security protocol. There’s no problem with that, but it has many usage specifications, such as using authorization codes as temporary credentials that can only be used once, and validating the redirect URI. If you don’t implement it according to these specifications, there will be security vulnerabilities.
Secondly, since OAuth 2.0 “grows” in the internet environment, it also faces common security risks on the internet, such as Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS).
Finally, in addition to these common types of attacks, OAuth 2.0 itself has security vulnerabilities that can be exploited, such as stolen authorization codes and forged redirect URIs.
Therefore, security issues are crucial when practicing OAuth 2.0. Next, I have selected 5 typical security issues. CSRF, XSS, and horizontal privilege escalation are common security risks in an internet environment, while stolen authorization codes and tampered redirect URIs are specific to OAuth 2.0. Let’s take a look at the origins of these security risks and how to deal with them together.
CSRF Attack #
The definition of CSRF, as explained in the book “OAuth 2 in Action,” is the most appropriate explanation I have come across so far: Malicious software makes the browser send requests to a website that has already authenticated the user and performs malicious operations. This is known as a Cross-Site Request Forgery (CSRF) attack.
It is one of the most common attacks on the internet. When we implement OAuth 2.0, we are essentially building an application for the internet. Therefore, OAuth 2.0 is also susceptible to this attack. Next, I will explain this attack type using a case study.
There is a software A, which we will use as the attacker. We have the developer of software A follow the normal process of using GeekTime. After the attacker has been granted authorization and obtained the authorization code value codeA, it immediately presses the pause button and doesn’t proceed further. So, what does it want to do? Let’s continue reading.
At this point, there is a third-party software B, such as our web version of GeekTime, which will play the role of the victim. Of course, the ultimate victim is the user, and we will use the web version of GeekTime as the object of the attack by software A.
The callback URL that GeekTime uses to receive the authorization code is https://time.geekbang.org/callback. User G has already logged in to the GeekTime platform and has authorized GeekTime, meaning that User G already has a login session on the GeekTime platform.
If at this time, the attacker software A constructs a malicious webpage on its own website:
<html>
<img src ="https://time.geekbang.org/callback?code=codeA">
</html>
If User G is tricked by attacker software A into clicking on this malicious page, then the result is that GeekTime continues the OAuth 2.0 process using the codeA value. This completes the process of a CSRF attack, as shown in the following figure:
Figure 1 CSRF Attack Process
If we use OAuth 2.0 for authentication, it can have serious consequences because User G’s authorization context with GeekTime is tied to the attacker software A’s authorization context. To explain the harm that this binding of two contexts can cause, let’s use GeekTime as an example again.
Suppose GeekTime offers a feature to link user accounts with WeChat accounts, meaning that users can log in using their GeekTime account and then link it to their WeChat account for future logins. When linking the WeChat account, WeChat consults with you to authorize GeekTime to access your personal information on WeChat. This is where the OAuth 2.0 authorization process comes into play.
If attacker software A, using its own GeekTime account, has previously performed the linking operation mentioned above, meaning the attacker can now log in to GeekTime using their WeChat account, there may come a day when software A wants to “do something” and constructs an attack page after initiating an authorization request. The simulated code contained within that page is as I described above, which is used to trick user G into clicking on it.
If user G has already logged in to GeekTime using their GeekTime account and is in the process of linking their WeChat account, if they happen to click on the malicious page planted by attacker A, then the subsequent exchange of the authorization access token and the information obtained through that access token will all belong to attacker software A.
This means that user G has linked their GeekTime account with attacker software A’s WeChat account. As a result, software A can subsequently log in to user G’s GeekTime account using its own WeChat account. The consequences of this can be imagined.
So how can we avoid these types of attacks? The method is actually quite simple and is also suggested in OAuth 2.0, which is to use the state parameter, a random value parameter.
Using the previous scenario as an example, when GeekTime requests an authorization code, it includes a state parameter value that it generates itself. The authorization service must also return this random state value along with the authorization code according to the rules. When GeekTime receives the authorization code, it performs a verification check on the state parameter value on its side. If they match, the process continues; otherwise, it directly rejects the subsequent process.
In this case, if software A wants to launch a CSRF attack again, it must construct a separate state value, which is not easy to forge. This is a random value that follows the recommendation of having an extremely low probability of being “guessed.” For example, generating a combination of 6 alphanumeric characters would have a lower probability of being “guessed” compared to generating a 6-digit numeric value. Thus, by using the state parameter, software B achieves a basic protection against cross-site request forgery.
Let’s summarize again. This attack process essentially replaces the authorization code value of software B with the attacker software A’s authorization code value codeA.
Next, I will show you another common type of security attack on the internet, known as XSS attack.
XSS Attack #
The main method of XSS attack is to inject malicious scripts into the input of the request. Attackers can use injected malicious scripts to perform malicious actions, such as collecting data. As of June 23, 2020, if you check the ranking of security vulnerabilities on OWASP (an open-source web application security project), XSS is still on the TOP10 list, making it “renowned”.
There are many introductions to XSS on the internet, but I recommend you take a look at the article “XSS Attack Analysis and Defense Techniques”. It provides a clear analysis of the principles and defense methods of XSS. Today, let’s focus on how it “works” in the OAuth 2.0 process.
When a request arrives at the protected resource service, the system needs to perform verification, such as verifying the legitimacy of third-party software identity and the access token. If these pieces of information cannot be verified, the protected resource service will return an error message.
Figure 2: XSS attack process
In most cases, the protected resource service echoes back the input content, such as “app_id invalid” or “access_token invalid”. This is when XSS attackers can seize the opportunity. Imagine if an attacker injects some malicious JavaScript code that collects user data. If the protected resource service directly returns this code to the user’s page and the user triggers it, they will be vulnerable to attack.
Therefore, the protected resource service needs to fix these types of XSS vulnerabilities. The specific remediation methods are similar to other websites’ defenses against XSS, and the simplest method is to escape and filter illegal information, such as escaping any content that contains