> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qaos.machdel.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Session Management
> Issues related to how sessions are created, stored, and transmitted — including token exposure, weak entropy, and missing cookie security flags.
Session management vulnerabilities allow attackers to steal or forge session tokens, hijacking authenticated user sessions without knowing the user's password.
***
## session-id-in-url
Critical
**What it is**
Session identifiers appear in the URL as query parameters (e.g., `?sessionid=abc123`, `;jsessionid=xyz`), making them visible in browser history, server logs, referrer headers, and shared links.
**Why it matters**
A URL containing a session ID can be:
* Leaked through the HTTP `Referer` header to third-party sites
* Stored in browser history and accessible to other users of the same machine
* Captured in server access logs
* Accidentally shared in a screenshot or copy-pasted link
Any of these scenarios results in session hijacking without any active attack.
**How QAOS detects it**
The agent inspects the current URL after every navigation for parameters that resemble session identifiers: `sessionid`, `session`, `sid`, `token`, `jsessionid`, `PHPSESSID`, and similar patterns.
**Examples**
```
https://app.example.com/dashboard?sessionid=abc123def456
https://app.example.com/page;jsessionid=ABCDEFG1234567
https://app.example.com/home?sid=user_9876token
```
**How to fix**
Store session identifiers exclusively in cookies with the `HttpOnly` and `Secure` flags set. Never pass session tokens through URLs. If you inherit a legacy system that uses URL-based sessions, migrate to cookie-based sessions and implement `SameSite=Strict` or `SameSite=Lax`.
***
## session-id-in-hidden-field
High
**What it is**
Session identifiers are embedded in hidden form fields or client-accessible DOM elements (e.g., ``), making them readable by any JavaScript on the page.
**Why it matters**
Hidden form fields are part of the DOM and accessible via JavaScript just like any other element. An XSS vulnerability anywhere on the page can extract the session ID from a hidden field and exfiltrate it to an attacker-controlled server.
**How QAOS detects it**
The agent scans the DOM for hidden input fields and client-side metadata whose names or values match session identifier patterns (`session_id`, `token`, `auth`, `sid`, etc.).
**Examples**
```html theme={null}
```
**How to fix**
Never embed session identifiers in the DOM. Store session state server-side and reference it exclusively through `HttpOnly` cookies that JavaScript cannot read. If you need to pass a CSRF token through a form field, use a separate, purpose-limited CSRF token rather than the session ID itself.
***
## session-id-reused-after-authentication
High
**What it is**
The session identifier is not rotated when a user logs in — the same session ID that existed before authentication is used for the authenticated session. This creates a session fixation vulnerability.
**Why it matters**
In a session fixation attack, an attacker plants a known session ID in the victim's browser (e.g., via a malicious link or XSS). If the application reuses that session ID after login, the attacker's known ID becomes authenticated and they gain access to the victim's account.
**How QAOS detects it**
The agent captures the session cookie value before login, completes the authentication flow, then compares the session cookie value afterwards. If the value is unchanged, session fixation is possible.
**How to fix**
Issue a fresh session ID immediately after successful authentication:
```python theme={null}
# FastAPI / Starlette — invalidate old session, create new one
request.session.clear()
request.session["user_id"] = user.id
# The framework issues a new session cookie automatically
# Express.js with express-session
req.session.regenerate((err) => {
req.session.userId = user.id
})
```
***
## missing-session-invalidation
High
**What it is**
Logging out does not invalidate the server-side session. The session cookie remains valid after sign-out, allowing a user (or attacker who captured the cookie) to continue using the authenticated session.
**Why it matters**
If a user logs out on a shared computer, or if their session cookie was previously stolen, the attacker retains access indefinitely. Proper session invalidation is the only way to guarantee that a logout actually ends the session.
**How QAOS detects it**
The agent captures the session cookie, performs a logout, then attempts to access authenticated pages using the captured cookie. If access is still granted, session invalidation is missing.
**How to fix**
Invalidate the server-side session on logout — deleting the session record from the store, not just clearing the cookie client-side:
```python theme={null}
# FastAPI / Starlette
request.session.clear() # removes session data server-side
# Express.js
req.session.destroy((err) => {
res.clearCookie('connect.sid')
res.redirect('/login')
})
```
Clearing the cookie on the client is not sufficient — the server must reject the session ID even if the client sends it.