# Multi-Step Profiles

Multi-step profiles allow you to chain multiple scanning steps together in a sequential flow. This is essential for testing vulnerabilities that require multiple requests, such as multi-stage attacks, authentication-dependent tests, and workflows that rely on state from previous requests.

## 💡 Concept

A multi-step profile executes a sequence of **steps**, where each step is a complete scan configuration (payloads, grep patterns, insertion points). Steps are executed sequentially, and cookies/state can be shared between them.

```
Step 1: Send initial payload → Match response
  │ 🍪 (cookies carried forward)
  ▼
Step 2: Send follow-up payload → Match response
  │ 🍪 (cookies carried forward)
  ▼
Step 3: Send verification payload → Final match → 🐛 Report issue
```

## 📊 Step Structure

Each step in the `steps[]` array contains the same fields as a regular profile, plus additional multi-step-specific fields:

| Field               | Type    | Description                                                                                              |
| ------------------- | ------- | -------------------------------------------------------------------------------------------------------- |
| 🍪 `reuseCookie`    | Boolean | Carry cookies from the previous step's response                                                          |
| 📍 `insertionPoint` | String  | `"same"` to reuse the matched insertion point from the previous step, or `null` for all insertion points |

All standard profile fields are available per step: `Payloads`, `Grep`, `MatchType`, `InsertionPointType`, `RedirType`, `MaxRedir`, `Header`, `NewHeaders`, etc.

## ⚙️ How Multi-Step Execution Works

1. 1️⃣ **Step 1 executes** with its payloads and insertion points
2. ✅ If Step 1 matches, the scanner records:
   * 📍 The matching insertion point
   * 🍪 Any cookies set in the response
3. 2️⃣ **Step 2 executes** using:
   * 🍪 Cookies from Step 1 (if `reuseCookie: true`)
   * 📍 The same insertion point as Step 1 (if `insertionPoint: "same"`)
   * 🌐 Or all insertion points (if `insertionPoint: null`)
4. 🔄 This continues for all steps in the sequence
5. 🎯 **Stop-on-match**: If any step fails to match, the entire sequence stops for that insertion point

## 🍪 Cookie Reuse

When `reuseCookie: true`:

1. The response from the previous step is analyzed for `Set-Cookie` headers
2. All cookies are collected and added to the next step's request
3. This enables testing scenarios like:
   * 🔓 Login → Access protected resource
   * 🛡️ CSRF token retrieval → Use token in attack
   * 🔑 Session setup → Exploit session-dependent vulnerability

## 📍 Insertion Point Reuse

When `insertionPoint: "same"`:

* The step tests only the same insertion point that matched in the previous step
* This ensures the attack chain targets a consistent parameter across all steps
* If not set (or `null`), all configured insertion points are tested

## 📚 Example: Multi-Step Authentication Test

```json
[
  {
    "ProfileName": "Auth_Bypass_MultiStep",
    "Enabled": true,
    "Scanner": 1,
    "Author": "@researcher",
    "steps": [
      {
        "Payloads": ["true,admin"],
        "Grep": ["true,,Simple String,,Set-Cookie: session="],
        "MatchType": 2,
        "InsertionPointType": [1],
        "reuseCookie": false,
        "insertionPoint": null,
        "RedirType": 4,
        "MaxRedir": 3
      },
      {
        "Payloads": ["true,/admin/dashboard"],
        "Grep": ["true,,Simple String,,Welcome, Admin"],
        "MatchType": 1,
        "InsertionPointType": [66],
        "reuseCookie": true,
        "insertionPoint": null,
        "RedirType": 4,
        "MaxRedir": 3
      }
    ],
    "Tags": ["All", "Auth"],
    "IssueName": "Authentication Bypass",
    "IssueSeverity": "High",
    "IssueConfidence": "Firm",
    "IssueDetail": "<br/>- PAYLOAD: <br/><payload>\n<br/><br/>\n- GREP: <br/><grep>"
  }
]
```

**🔄 Flow:**

1. 1️⃣ Step 1 sends `admin` as a body parameter and checks for a session cookie
2. 2️⃣ Step 2 reuses the session cookie and requests `/admin/dashboard`, checking for admin access

## 📚 Example: CSRF Token Retrieval + Exploitation

```json
{
  "steps": [
    {
      "Payloads": ["true,GET /form"],
      "Grep": ["true,,Regex,,name=\"csrf_token\" value=\"([^\"]+)\""],
      "MatchType": 2,
      "reuseCookie": false,
      "insertionPoint": null
    },
    {
      "Payloads": ["true,<script>alert(1)</script>"],
      "Grep": ["true,,Simple String,,<script>alert(1)</script>"],
      "MatchType": 1,
      "reuseCookie": true,
      "insertionPoint": "same"
    }
  ]
}
```

## ⏱️ Time-Based Detection in Multi-Step

Multi-step profiles support time-based detection through the `checkTimeDelayGreps()` method. This enables timing attacks where:

1. 1️⃣ Step 1 sends a baseline request (no delay)
2. 2️⃣ Step 2 sends a time-delay payload
3. ⏱️ The time difference is analyzed to confirm the vulnerability

## 🎯 Stop-on-Match Behavior

Multi-step profiles have built-in stop-on-match logic per step:

* ✅ When a step matches, subsequent payloads for the same step are skipped
* ➡️ The sequence proceeds to the next step
* ❌ If a step fails to match, the entire sequence stops for that insertion point
* 🔀 This is separate from the single-step stop-on-first-match optimization

## 💡 Tips

* 📝 **Start simple** — Test each step independently as a regular profile before combining into a multi-step sequence
* 🍪 **Use cookie reuse** — Enable `reuseCookie: true` when the next step depends on session state from the previous step
* 📍 **Use insertion point reuse** — Set `insertionPoint: "same"` when the entire attack chain should target the same parameter
* 🔢 **Order matters** — Steps execute in array order; place prerequisite steps first
* 🔍 **Debug with Scanner tab** — Use the Scanner tab to see per-request details for each step


---

# Agent Instructions: 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:

```
GET https://docs.bountysecurity.ai/profiles/multi-step-profiles.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.