> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/cybersecurity-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-access-control-labs/lab-11.md).

# lab-11

## Multi-Step Process with No Access Control on One Step

**Difficulty:** Practitioner

### Lab Description

This lab has an admin panel with a flawed multi-step process for changing a user's role.

**Credentials (admin):** `administrator:admin`\
**Credentials (attacker):** `wiener:peter`

**Objective:** Exploit the flawed access controls to promote `wiener` to administrator.

### Root Cause

Any multi-step feature — such as role updates, email changes, or password resets — should verify permissions at every step. The correct flow looks like this:

```
Request
    ↓
Check Permission
    ↓
Allowed?
    ↓
Yes
    ↓
Perform Action
```

In vulnerable applications, developers verify the first step or two but skip the check on the final confirmation step, assuming a user can only reach step 3 after passing steps 1 and 2. An attacker can analyse the steps on their own account, then skip directly to the unprotected final step with a different user's session. This can lead to unauthorised role changes, email/password takeovers, and full account compromise.

The vulnerable flow looks like this:

```
Step 1
Permission Check
    ↓
Step 2
Permission Check
    ↓
Step 3
NO Permission Check
    ↓
Action Executed
```

### Exploitation

Log in as `administrator:admin` and go to the admin panel. Use the **Upgrade to admin** feature on the `carlos` account and capture all requests in Burp. Observe the two-step process: the first request selects the user, and the second confirms the role change.

Now log in as `wiener:peter` and capture `wiener`'s session cookie. In Repeater, take the captured **step 2 confirmation request** (which originally targeted `carlos`), replace its session cookie with `wiener`'s session, and change the username parameter from `carlos` to `wiener`. Send the request.

The server executes the role upgrade without re-checking whether the requester has admin privileges — `wiener` is now an administrator.

The same technique applies to any other multi-step update feature such as email changes or password resets.

### Lesson Learned

Whenever you see an update feature, analyse how many steps it involves, then test whether each step independently verifies the session and permissions. An unverified final step is often the entry point for bypassing the entire access control chain.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-access-control-labs/lab-11.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.