What is cross-site scripting?¶

The practical answer¶

Cross-site scripting, often called XSS, is a vulnerability that allows attacker-controlled script or content to run in another user’s browser within the context of a trusted web application.

The key evidential caution¶

The dangerous assumption is that finding script input proves another user executed it.

It does not.

The script may be:

Key points¶

• reflected immediately in a response
• stored by the application and shown later
• executed through client-side application logic
• blocked or sanitised
• viewed only by the person who submitted it

An attacker may use XSS to:

• steal session information
• alter displayed content
• redirect users
• capture input
• perform actions as the user
• deliver further malicious content

What investigators should establish¶

Investigators should establish:

Key points¶

• where the input entered the application
• whether it was stored or reflected
• which users received it
• whether their browsers executed it
• what account or session context applied
• what actions or data followed

Application logs may show submission.

Browser, security and session records may be needed to show execution and impact.

Evidential limits¶

Do not assume that a vulnerable page means every visitor was affected.

Likewise, the presence of an XSS payload does not identify who authored or deployed it.

Stored XSS may remain in the application and affect users long after the original submission. Preserve the stored object, publication history and affected user sessions. Reflected XSS may require a specially crafted link and may affect only users who opened it. Those routes should not be merged.

Operational takeaway¶

Prove submission, delivery, browser execution and resulting user or session impact separately before concluding that cross-site scripting caused compromise.