Testing Authenticated Flows

The Authentication Problem

Most web applications require login. When you test authenticated functionality, every request must include a valid session token. If the session expires during a long Intruder attack or Scanner run, all subsequent requests return 401/403 and your results are garbage. Session handling rules solve this by automatically detecting expired sessions and re-authenticating.

How Sessions Work in Burp

When you log in through Burp Proxy, the server returns a session cookie (e.g., session=abc123). This cookie is stored in your browser and sent with every subsequent request. Burp sees this cookie in the proxy traffic and can use it in other tools (Repeater, Intruder, Scanner) by configuring session handling.

Configuring Session Handling Rules

Go to Project options > Sessions > Session Handling Rules. Click Add to create a new rule:

1. Rule name — e.g., "Re-authenticate on 401"
2. Rule actions — Add action: "Run a macro"
3. Macro — Record or select a macro that performs the login
4. Scope — Define which URLs this rule applies to

What is a Macro?

A macro is a sequence of requests that Burp can replay. For authentication, you record a macro that:

1. Sends a POST to /login with username and password
2. Receives the session cookie in the response

When Burp detects a failed request (e.g., 401 response), it runs the macro to get a fresh session cookie, then retries the original request with the new cookie.

Recording a Login Macro

1. Go to Project options > Sessions > Macros and click Add
2. In the macro recorder, select the login request from your proxy history
3. Configure the macro to extract the session cookie from the response:
   • Click "Configure item"
   • Add a custom parameter location: find Set-Cookie: session= in the response
   • Define the parameter name and value extraction
4. Save the macro

Testing with Multiple User Roles

To test authorization, you need at least two user accounts with different privilege levels (e.g., regular user and admin). Log in as each user through Burp Proxy, then use the session handling rules to switch between them.

In Intruder or Scanner, you can configure the session handling rule to use a specific user's macro. This lets you test whether a regular user can access admin functionality by replaying admin requests with a regular user's session cookie.

Horizontal vs Vertical Privilege Escalation

Authorization vulnerabilities come in two forms:

• Horizontal — A user can access another user's resources at the same privilege level (e.g., user A can view user B's documents)
• Vertical — A user can access functionality reserved for higher privilege levels (e.g., a regular user can access admin panels)

Testing Horizontal Privilege Escalation

1. Capture requests as User A — Log in as a regular user, browse the application, and capture requests in Burp Proxy.
2. Identify object references — Look for parameters that reference other users' resources: /api/documents/1001, /api/users/5/profile, /api/orders/2001
3. Switch to User B's session — Configure Burp to use User B's session cookie.
4. Replay User A's requests — Send the captured requests with User B's session. If the server returns User A's data, horizontal privilege escalation exists.

Testing Vertical Privilege Escalation

1. Capture admin requests — Log in as an admin, capture requests to admin-only endpoints: /admin/users, /admin/settings, /admin/delete-user
2. Switch to regular user's session — Configure Burp to use a regular user's session cookie.
3. Replay admin requests — Send the admin requests with the regular user's session. If the server processes them, vertical privilege escalation exists.

Using Burp's Role-Based Testing

Burp's User settings (Project options > Sessions > Users) let you define multiple users with different session handling rules. You can:

• Define User A with a macro that logs in as a regular user
• Define User B with a macro that logs in as an admin
• Configure Intruder or Scanner to iterate through users

This automates the process of testing each endpoint with each user role.

Practical Example: IDOR in a Multi-Tenant App

You are testing a project management app. You have two accounts: alice (regular user) and bob (regular user). Both are in different workspaces.

1. Log in as Alice, capture: GET /api/workspace/5/projects
2. Switch to Bob's session
3. Replay: GET /api/workspace/5/projects
4. If Bob sees Alice's workspace projects, horizontal IDOR is confirmed

Now test vertical:

1. Log in as admin, capture: GET /admin/all-workspaces
2. Switch to Alice's session
3. Replay: GET /admin/all-workspaces
4. If Alice sees all workspaces, vertical privilege escalation is confirmed

Common Authorization Flaws to Test

• Missing function-level access control — Endpoint exists but does not check if the user's role permits access
• Insecure direct object references (IDOR) — Parameter references another user's object without ownership verification
• Path traversal via authorization — /api/users/1/file accessible by user 2 by changing the ID
• HTTP method manipulation — GET returns 403 but POST or PUT succeeds
• Header-based authorization — X-Admin: true header grants admin access

Handling Complex Login Flows

Not all logins are simple POST requests. Some applications use:

• Multi-step authentication — Username first, then password, then OTP
• CSRF tokens — Login form requires a CSRF token from a previous page
• OAuth flows — Redirect to identity provider, callback with code
• CAPTCHA — Automated solving required (or disabled in staging)

For multi-step logins, record a macro that includes all steps:

1. GET /login (to obtain CSRF token)
2. POST /login with credentials and CSRF token
3. POST /login/otp with one-time password

Extracting Tokens from Macro Responses

When a macro performs login, you need to extract the session token from the response and use it in subsequent requests. In the macro configuration:

1. Select the login request in the macro
2. Click "Configure item"
3. Add a Custom parameter location in the response:
   • Parameter name: session_id
   • Location: Find Set-Cookie: session= in response headers
   • Value: Extract the cookie value

Burp automatically uses this extracted parameter in all requests within the macro and in the session handling rule.

Session Handling Rule Actions

A session handling rule can perform multiple actions when a session expires:

1. Run a macro — Re-authenticate
2. Set a specific cookie or parameter — Manually provide a session token
3. Prompt for input — Ask the tester to manually log in

For automated testing, "Run a macro" is the most reliable. For manual testing, "Prompt for input" gives you control.

Testing Session Expiry Behavior

Applications handle session expiry differently:

• Hard expiry — Session invalidated after timeout; re-login required
• Sliding expiry — Session extended on each request; expires after inactivity
• Refresh tokens — Access token expires but refresh token obtains new access token

Test each scenario:

1. Start an Intruder attack with a valid session
2. Wait for the session to expire mid-attack
3. Observe whether Burp's session handling rule re-authenticates automatically
4. If not, the attack results after expiry are invalid — re-run with a fresh session

Practical Tip: Staging Environment Testing

Always test authenticated flows against a staging environment first. Production systems may:

• Rate-limit login attempts (locking your test accounts)
• Trigger security alerts on repeated authentication
• Have shorter session timeouts that interfere with testing

Staging environments typically have relaxed security controls and longer session timeouts, making automated testing more reliable.