is a stored xss possible if user input is not saved?

Question

I was wondering if a stored cross-site scripting attack is possible if the user input is not saved. If a website is vulnerable to an xss attack, can someone put in a code or something that stores a script?

Answer 1

I prefer the term "persistent" to "stored" simply because stored can be blurry as payloads can persist outside the traditional notion of storage.

• Does a reflected xss injected into cached page mean that it was stored?
• Does it matter if it is cached server side or client side?
• What about a reflected xss that manipulates a cookie which then persists to xss on another page?
• What about long lived "temporary storage" such as static function variables, session storage?
• What about if the web app doesn't store the data but the web server allows file uploads via PUT?
• What about second order bugs? I.e. the application calls an API that stores and serves user supplied data inside a javascript context?

Most vulnerabilities are context specific and asking a generic question will likely not give you an answer that applies to your situation. If you have concerns about an application I would recommend that you have the application penetration tested or subjected to a secure code review or perhaps both.

Answer 2

The question is contradictory; you can't store something without being able to, well, store something.

However, there is another type of XSS, reflective XSS, which does not require anything to be stored. An example would be a vulnerability where a URL parameter is rendered into a page in an improper way. In this case, visiting a crafted URL alone is sufficient to trigger the XSS.

Answer 3

Interestingly, I would say "yes".

For me the core difference between stored XSS (sXSS) and reflected XSS (rXSS) is in the exploitation. rXSS reflects input back for one user in the same HTTP request, while sXSS involves multiple users & multiple HTTP requests.

Difference between rXSS and sXSS

For rXSS, the user that sends the payload and the user that triggers the payload are the same.

The attack involves one HTTP request: The user sends the request with an XSS payload (usually when visiting an attacker-supplied link) & the response directly reflects that payload back.

For sXSS, there are at least two HTTP requests & two users involved. The attacker places the payload with one request, and then at a later point in time, a different user does something which results in a HTTP request which returns the payload.

sXSS example without saving input

Let's now take a live chat application as example. Normally, the chat messages are stored on the server. But that isn't strictly necessary. The server could merely relay the messages without storing them.

That scenario clearly isn't rXSS, but also doesn't store the input (depending on the definition of "stored"). I would consider it sXSS without saving user input.

It is a bit of a contrived example - not storing the messages restricts usability and isn't normally done - but it is an example.