session-security-testing

Session Security Testing (Chinese Version)

When to Use

When you need to design security tests or review preparation around session creation, fixation, expiration, revocation, concurrency, and cross-device boundaries.
When you need to deliver a reviewable initial version when materials are incomplete, and clearly state assumptions, gaps, and Human decisions.
When you need to distinguish static security evidence, planned validation, and execution that has already occurred.

Default output is Markdown, organized by security risk, evidence, and priority.
When the user requests table, CSV, JSON, or ticket format, retain the same finding fields and evidence status.
Before output enters an automated process, first confirm the schema, enum values, and required fields.

First read prompts/session-security-testing.md, and execute the input audit, coverage checklist, and output contract.
Extract scope, environment, version, roles, data, dependencies, constraints, and available evidence.
Build reviewable scenarios around session creation, fixation, expiration, revocation, concurrency, and cross-device boundaries, distinguishing known facts, inferences, and candidate validation.
For each item, record impact, priority, responsible role, closure conditions, and validation method.
When information is insufficient, deliver a limited initial version, and do not write risk assumptions as vulnerability confirmation or security pass.

Each execution must read prompts/session-security-testing.md.
When evaluation is needed, read evals/eval.yaml and the matching evals/cases/.
Only read references/, examples/, scripts/, or output-formats.md when the directory exists and the task requires it.

First identify mechanisms such as Cookie/opaque session/access+refresh token, and list creation, post-authentication rotation, fixation, idle/absolute expiration, revocation, logout, and multi-device contracts.
Deliver a credential lifecycle and privilege state timeline by mechanism; a successful logout response does not automatically prove that old credentials are unusable.
When forming domain candidates, you must read and follow prompts/session-security-testing.md domain operations and determination process, retaining legitimate controls, evidence gaps, and validation actions item by item.

Only analyze session creation, fixation, expiration, revocation, concurrency, and cross-device boundaries; do not log in to systems, do not call real APIs, and do not read credentials.
Do not fabricate vulnerabilities, successful attacks, completed fixes, scan coverage, or security pass conclusions.
When evidence is lacking, mark as pending confirmation, blocked, or unassessed, and provide an isolated validation method.
Risk acceptance, exception authorization, and release decisions must be left to Human.

Completed the known, missing, conflicting, stale, out_of_scope, and assumptions audit.
Covered session security, trigger conditions, expected focus points, and evidence status.
Separated facts, inferences, recommendations, information gaps, and Human decisions.
Did not write static findings or dry-run as real attacks, absence of vulnerabilities, or release approval.

Treating a generalized security review or API contract check as a complete substitute for session security testing.
Listing only attack names without writing applicability, evidence, expected results, and closure conditions.
When information is insufficient, directly determine that it is safe, or read real credentials for the sake of completeness.

Start with high-impact, hard-to-detect, privilege-sensitive, or data-sensitive paths.
Use sanitized materials, least privilege, isolated environments, and rollback-capable validation recommendations.
Enable another engineer to review each security conclusion based on its source and boundaries.