Second-Order and Asynchronous Injection
Trace data across storage, queues, exports, and later interpreters so delayed behavior can be reproduced without guessing which component executed it.
Every step requires authorization. Review side effects before running commands against a live system.
Define the boundary before the test.
- Preconditions
- Current scope, observed technology, reachable feature, controlled identities or data, and a recovery plan.
- Expected evidence
- One observable response, state, or callback that distinguishes the hypothesis from normal behavior.
- Negative control
- The same action with the security-sensitive variable removed, replaced, or bound to its rightful owner.
- False-positive checks
- Cache, retry, race, reflection, proxy rewriting, stale sessions, and unrelated asynchronous activity.
- Chain gate
- Record the proven primitive and the next missing prerequisite. Do not expand impact until scope and authorization still permit the next step.
Draw the data lifecycle
Model source, validation, storage, normalization, queue, worker, export, viewer, and sink. Include scheduled jobs, moderation, ticket routing, notifications, analytics, CSV exports, PDF generation, backups, and synchronization to downstream services.
source -> storage -> transform -> queue -> recall -> interpreterAssign canaries to each stage
Use a different inert alphanumeric marker for each field and transformation hypothesis. Record the controlled object ID and timestamps. A returned canary shows where data traveled and how it changed before any interpreter-specific test is justified.
SOI017_PROFILE_NAME_STAGE1Trigger one recall path
Use your own account, object, export, preview, or approved test workflow to recall the stored data. Do not rely on an unsuspecting employee or customer to activate it. Save the request or action that caused the recall.
Choose the sink-specific discriminator
After observing the transformed context, choose one bounded discriminator: harmless markup for an HTML renderer, a unique callback for a URL fetcher, a non-mutating syntax error for a query parser, or a callback-only execution marker where explicitly allowed. Do not mix interpreters in one payload.
Account for delayed and repeated work
Correlate worker retries, cron schedules, queue redelivery, caches, and export regeneration. Keep one unsubmitted token and one stored marker whose sensitive delimiter is encoded. Repeated callbacks from the same job are one event pattern, not multiple affected users.
Clean up and report the chain
Delete or neutralize controlled records, confirm the callback stops when feasible, and report each proven edge separately. Mark storage, recall, interpretation, viewer privilege, and impact as observed or inferred.
Common guidance
- A delayed callback is valuable only when the submission and recall paths are both documented.
- Second-order behavior often crosses teams and services. Do not attribute a callback to the front-end request without the lifecycle evidence.
- Prefer one controlled object with several staged canaries over many objects with reused payloads.
- Keep the final claim at the weakest proven link if later chain edges remain untested.
Mapped workflow tools
References
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/14-Testing_for_Incubated_Vulnerability ↗
- https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting ↗
- https://portswigger.net/knowledgebase/papers/huntingasynchronousvulnerabilities.pdf ↗
Version history: normalized permanent page created 2026-08-20.