# 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