skip to content

In a ZAP context, what does the configured session-management method do to each outgoing request?

level: middleimportance: should knowfreq 42%

answer

  1. two settings, not one, per context
  2. three hooks on every session type
  3. three in core, two from an add-on
  4. a new context starts cookie-based
  5. one core type carries nothing

basics

~10 s

A context's session-management method rewrites every outgoing request so it looks like it came from the logged-in user. Core ships cookie-based, HTTP-auth and script-based types, and the HTTP-auth one deliberately carries nothing at all.

solid answer

~40 s

A context has two separate settings: an authentication method that performs the login, and a session-management method that carries the result of that login onto every later request. The session method implements three hooks — `extractWebSession` pulls session state out of a message, `processMessageToMatchSession` stamps it onto an outgoing request, and `clearWebSessionIdentifiers` strips it back out. Core ships three types. `cookie` keeps a per-user cookie jar and replays it, `script` hands both hooks to a script, and `http` is a deliberate no-op: its `processMessageToMatchSession` body is empty, because HTTP authentication re-sends credentials on every request and there is no session state to carry. A freshly created context starts cookie-based. The `authhelper` add-on supplies two more types, `headers` and `autodetect`, for targets that carry a token in a header instead.

code

yaml · 3 lines
yaml
# env.contexts[].sessionManagement
sessionManagement:
  method: http     # a no-op: nothing is carried between requests

go deeper

for a junior

Remember that logging in and staying logged in are two different settings on a context. Naming the three core session types and saying which one a new context starts with is enough at this level.

for a middle

Explain the three hooks a session type implements and what each core type actually stamps onto a request — including that the HTTP-auth type stamps nothing, and why that is correct rather than a bug.

for a senior

Show that you choose the type from what the login response hands back, and that you know the add-on dependency turns two of the five plan values into a deployment concern for lean images.

for a principal

Own the standard: which session type each class of target gets, which add-ons a scanning image must therefore carry, and how a team detects the silent failure mode where the wrong type still produces a clean-looking run.

## Two settings, not one A context in this tool holds an **authentication method** and a **session-management method**, and they answer different questions. The authentication method answers *how do I log in*. The session-management method answers *how do I keep looking logged in on every request after that*. A scan sends thousands of requests; exactly one of them is the login. Everything else depends on the session method doing its job. The pair is easy to conflate because a plan declares them next to each other under the same context, and because a broken login and a broken session carry look identical from the outside — an authenticated crawl that only ever sees the public pages. ## The contract Every type implements the same small interface, and reading it is the fastest way to understand what the tool can and cannot do here: | hook | when it runs | what it is for | |---|---|---| | `extractWebSession` | after a response arrives | lift whatever identifies the session out of the message | | `processMessageToMatchSession` | before a request goes out | stamp the stored session onto the request | | `clearWebSessionIdentifiers` | when a request must look anonymous | strip the session tokens back out | (A fourth member is a plain factory for an empty session object, and a fifth reports the type over the control API; neither decides anything.) Note what is **not** in that list: nothing decides whether the session is still valid. That is a separate object again, the context's verification method, and it is what turns a dead session into a re-login. ## The three core types | plan value | what it carries | notes | |---|---|---| | `cookie` | a per-user cookie jar, replayed on each request | the default for a new context | | `http` | **nothing** | the hook body is empty | | `script` | whatever a script decides | both hooks are delegated | The `http` row surprises people, and it is worth understanding rather than memorising. Its own source comment says sessions are *managed through continuous authentication*: with HTTP authentication the credentials ride on every single request, so there is no server-issued session artefact to store and replay. `processMessageToMatchSession` and `clearWebSessionIdentifiers` are both empty methods, and the session object it hands out is blank. Choosing `http` because the target speaks HTTP is a category error — the choice is about what the target hands you back after a login, not about the protocol. The `cookie` type is the one most people mean when they say the scanner is logged in. It keeps a cookie store per user, adds those cookies to each outgoing request, and — when it strips session identifiers — asks the core HTTP-sessions extension which cookie names count as session tokens. If that extension is not enabled it logs that it will remove nothing and returns, which is a quiet failure worth knowing about. ## The two the `authhelper` add-on adds Two more types exist, and **neither is in core**: - `headers` — carries an arbitrary set of request headers, each value a template filled from tokens observed during the login. This is what a bearer-token or custom-header API needs, because a cookie jar has nothing to replay. - `autodetect` — a placeholder. Its message hook is empty too, so a context left on `autodetect` carries nothing until a passive rule shipped by the same add-on spots the session tokens in recorded traffic and **replaces the context's session method** with a configured `headers` one. Because the substitution is done by a passive rule, `autodetect` only works while traffic is being recorded and the passive engine — which ships as the `pscan` add-on — is running and has drained its queue. A plan that names `headers` or `autodetect` without the `authhelper` add-on installed does not fall back to anything: the automation add-on looks the type up by a hard-coded numeric identifier, finds nothing, and raises a plan error. ## Why a pipeline reader should care 1. **Pick the type from what the login returns.** A `Set-Cookie` means `cookie`; an `Authorization` header or a JSON token body means `headers`; HTTP authentication means `http`, which is to say nothing is carried and that is correct. 2. **`http` and `autodetect` both carry nothing**, but for opposite reasons — one because there is nothing to carry, one because it has not decided yet. 3. **The add-on dependency is a hard one.** Two of the five values a plan accepts come from an add-on, so a plan that runs on a workstation can fail on a lean image. 4. **Getting this wrong is silent.** A wrong session type does not error; the crawl simply never leaves the unauthenticated surface, and the run still finishes and still reports.

  • Which of the five session-management values a plan accepts are not in core, and what happens without the add-on?
    `headers` and `autodetect` are supplied by the `authhelper` add-on. The automation add-on resolves them by a hard-coded numeric type identifier; if the add-on is absent the lookup returns nothing and the plan raises an environment error rather than falling back to cookies.
  • What makes `autodetect` different from simply choosing `headers`?
    `autodetect` carries nothing itself — its message hook is empty. A passive rule from the same add-on watches recorded traffic, works out which headers and cookies carry the session, and swaps the context over to a configured `headers` method. It therefore needs the passive engine running and traffic recorded.
  • Does the session-management method decide when to log in again?
    No. It only stamps and strips session state. Deciding that the session has died is the context's verification method, and the re-login is driven by the HTTP sender reacting to that verdict. Session carrying and session checking are separate objects with separate settings.

saying these in an interview costs you the question

  • Thinks the session is always tracked with cookies
  • Says header-based session management is part of core
  • Expects the `http` session type to store a token
  • Confuses the session-management method with the login method
  • Assumes `autodetect` carries the session by itself