Would XSS in the local storage be considered "Stored"

Question

I am wondering what kind of category cross-site-scripting would be if it's injected in the local storage. Would it be "stored", "reflected" or maybe something else?

An example of what I mean:

• I found a website that is vulnerable for reflected XSS (lets refer to it as vulnerable.com).
• Using this reflected XSS I edit some JSON in the localStorage.
  • I changed a part of the JSON to this: "imgUrl":"https://vulnerable.com/products/some-product.jpg\" onload=\"alert(1)",
• When the user restarts the browser and opens vulnerable.com, an alert will popup.

---

OWASP states that it's not "stored" (source):

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc.

But OWASP also states that it's not "reflected" (source):

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.

Is there anyone who knows?

Answer 1

Updating my answer based on information @AviD provided (Thank You! I learnt something new).

From the OWASP XSS page:

For years, most people thought of these (Stored, Reflected, DOM) as three different types of XSS, but in reality, they overlap. You can have both Stored and Reflected DOM Based XSS. You can also have Stored and Reflected Non-DOM Based XSS too, but that’s confusing, so to help clarify things, starting about mid 2012, the research community proposed and started using two new terms to help organize the types of XSS that can occur:

• Server XSS
• Client XSS

It does not look like a Stored Server XSS based on what you've described. If the data in the local storage is not sent to the server in every request (or specific requests) and it is not "reflected" back in the HTTP response from the server, it should not be considered a Reflected Server XSS.

In this case, the payload (JS) is being stored on the client (browser) in the local storage, it should be considered as a Client Stored XSS (again, I agree with @AviD here). Now if this payload was merely inserted back in the DOM and not being stored on the client (browser), it should have been a case of a Client Reflected XSS.

Just a small note on Self XSS - something not mentioned on OWASP site: If you are only able to change that on your own browser and you cannot "remotely" trick this JS code insertion in some other user browser's local storage, for example: by asking them to click on a URL, I'd consider it as a Self XSS. Attackers tend to exploit Self XSS mostly through scams like posting/sharing malicious payloads on social media network and asking users to paste them in their browser JS consoles to see some magic happen.

Answer 2

Actually, there are not just 2 classes (or even 3) of XSS - Stored, Reflected and DOM-based - there are 4, along 2 different independent axis:

• Stored / Reflected
• Server / Client

(And so called DOM-based XSS is really just a subset of Client XSS.)

So in your case, it is simply Stored Client XSS.

See e.g. Types of Cross Site Scripting on OWASP:

Given that both Server XSS and Client XSS can be Stored or Reflected, this new terminology results in a simple, clean, 2 x 2 matrix with Client & Server XSS on one axis, and Stored and Reflected XSS on the other axis as depicted here