Access control vulnerabilities - gachikuku/portswigger GitHub Wiki

This lab has an unprotected admin panel.
Solve the lab by deleting the user carlos.

• Solution

  ffuf -u 'https://<uuid>.web-security-academy.net/FUZZ' \
       -w wordlist/SecLists/Fuzzing/fuzz-Bo0oM.txt
  
  ...
  
  robots.txt              [Status: 200, Size: 45, Words: 3, Lines: 3, Duration: 72ms]

  Looking at the /robots.txt endpoint we get Disallow: /administrator-panel.
  After accessing the admin panel we are able to delete poor carlos.

This lab has an unprotected admin panel. It's located at an unpredictable location, but the location is disclosed somewhere in the application.
Solve the lab by accessing the admin panel, and using it to delete the user carlos.

• Solution

  Checking source view-source:https://<uuid>.web-security-academy.net/.
  We get an interisting endpoint /admin-7eqvdh and poor carlos gets deleted.

This lab has an admin panel at /admin, which identifies administrators using a forgeable cookie.
Solve the lab by accessing the admin panel and using it to delete the user carlos.
You can log in to your own account using the following credentials: wiener:peter

• Solution

  1. Log on with wiener:peter.
  2. Chrome: ⌘ ⌥ I, Application panel, cookies section we notice a cookie with a boolean.
  3. Setting Admin, from false to true under the currect session cookie
     and refreshing ⌘+R we get to access the Admin panel and delete carlos.

This lab has an admin panel at /admin. It's only accessible to logged-in users with a roleid of 2.
Solve the lab by accessing the admin panel and using it to delete the user carlos.
You can log in to your own account using the following credentials: wiener:peter

• Solution

  1. Log in with wiener:peter.
  2. Use Burp to intercept the Update email functionality.
  3. Observe the POST request made. Replay (r) it for further investigation.
  4. Copy the json fields from Response to Request and set the roleid to 2 as described in the lab description.
  5. Refresh the page, and Admin panel is available. Delete poor carlos.

This lab has a horizontal privilege escalation vulnerability on the user account page.
To solve the lab, obtain the API key for the user carlos and submit it as the solution.
You can log in to your own account using the following credentials: wiener:peter

• Solution

  1. Log in with wiener:peter.
  2. Notice the url parameter id is set to wiener. Change it to carlos.
  3. Sumbit carlos's API Key.

This lab has a horizontal privilege escalation vulnerability on the user account page, but identifies users with GUIDs.
To solve the lab, find the GUID for carlos, then submit his API key as the solution.
You can log in to your own account using the following credentials: wiener:peter

• Solution

  1. Log in with wiener:peter.
  2. Browse each blog post.
  3. We come across a blog post which carlos has made. When clicking on his name, his GUID is disclosed in the URL.
  4. Browse back to My account and use carlos's GUID in the url's id parementer in place of wiener's
  5. Retrieve and submit carlos's API key.

This lab contains an access control vulnerability where sensitive information is leaked in the body of a redirect response.
To solve the lab, obtain the API key for the user carlos and submit it as the solution.
You can log in to your own account using the following credentials: wiener:peter

• Solution

  1. Log in with wiener:peter.
  2. Change the id parementer to carlos. Intercept before sumbiting.
  3. Replay (r) the request. Observe the code 302 Found. Look through the Response.
  4. Sumbit carlos's api key from the redirected Response.

NOTE:
carlos's api key is briefly leaked during the redirection.
Without an interception with a repeater for each Request, the leaked data would have been missed.

This lab has user account page that contains the current user's existing password, prefilled in a masked input.
To solve the lab, retrieve the administrator's password, then use it to delete the user carlos.
You can log in to your own account using the following credentials: wiener:peter

• Solution

  1. Log in with wiener:peter.
  2. Fuzz the id paremeter.

  ffuf -u 'https://uuid.web-security-academy.net/my-account?id=FUZZ' \
       -w wordlist/SecLists/Fuzzing/fuzz-Bo0oM.txt -fc 302
  
  ...
  
  administrator           [Status: 200, Size: 3825, Words: 1526, Lines: 71, Duration: 103ms]

  3. Use administrator in the id paramenter and sumbit.
  4. Password is masked. View-source ⌘ ⌥ U and find the value of the masked password.
  5. Log out, and login with the admin's credentials. Browse to Admin panel and delete carlos.

This lab stores user chat logs directly on the server's file system, and retrieves them using static URLs.
Solve the lab by finding the password for the user carlos, and logging into their account.

• Solution

  1. Head over to Live chat functionality. Intercept before View transcript.
  2. After couple Requests, there is a GET method for downloading transcripts incrementally.
  3. Change the number in the GET Request endpoint.
  4. View downloaded file and log in as carlos.

NOTE:
There may be a need to change more than just one Request.

This website has an unauthenticated admin panel at /admin, but a front-end system has been configured to block external access to that path. However, the back-end application is built on a framework that supports the X-Original-URL header.
To solve the lab, access the admin panel and delete the user carlos.

• Solution

  1. Read up on OWASP for Testing for Bypassing Authorization Schema
  2. Common mistake is when error missing username is found the attacker is adding the query to data INSTEAD on the URL.