TL;DR
Log an valid login
POSTrequest sending
Learning Material
Due to the dangers introduced by sending access tokens via the browser, the implicit grant type is mainly recommended for single-page applications. However, it is also often used in classic client-server web applications because of its relative simplicity.
In this flow, the access token is sent from the OAuth service to the client application via the user’s browser as a URL fragment. The client application then accesses the token using JavaScript. The trouble is, if the application wants to maintain the session after the user closes the page, it needs to store the current user data (normally a user ID and the access token) somewhere.
To solve this problem, the client application will often submit this data to the server in a POST request and then assign the user a session cookie, effectively logging them in. This request is roughly equivalent to the form submission request that might be sent as part of a classic, password-based login. However, in this scenario, the server does not have any secrets or passwords to compare with the submitted data, which means that it is implicitly trusted.
In the implicit flow, this POST request is exposed to attackers via their browser. As a result, this behavior can lead to a serious vulnerability if the client application doesn’t properly check that the access token matches the other data in the request. In this case, an attacker can simply change the parameters sent to the server to impersonate any user.
Lab
This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the client application makes it possible for an attacker to log in to other users’ accounts without knowing their password.
To solve the lab, log in to Carlos’s account. His email address is carlos@carlos-montoya.net.
You can log in with your own social media account using the following credentials: wiener:peter.
Write-up
Deployed the lab, used the credentials while logging requests flow and added the OAuth URL to the scope. After using the Oauth authentication with the wiener:peter credentials, I’ve crawled over the requests sent until I found these ones
Since it is an Apprentice lab, I simply tried to replace the email and username and replay the request.
The server is not linking token to accounts which allow anyone to connect if they already have a valid account. Sending this request solved the lab.