Stored XSS
Recapping our previous article's dive into the world of XSS basics, we covered the three main types: DOM-based, stored, and reflected XSS; we're now ready to zoom in on one particular type.
The Stored Cross-Site Scripting, also known as Persistent XSS. Don't worry if the name sounds daunting; in this article, we'll break it down into simple pieces. Imagine a puzzle – we'll assemble the parts of Stored XSS, explain it in everyday developer terms, and even walk you through a real-life example to make it crystal clear.
Definition
Stored XSS is a type of security flaw that occurs when a web application allows malicious code to be injected and stored on the server, then causing it to execute on retrieval by the user that enters an exploited website.
Malicious code then runs on the browser as it does its job by rendering the website directly from the server.
Users then fall vulnerable to having their accounts hijacked as one of the possible scenarios.
Process of stored XSS and how it works
Injection Point: The Attacker identifies a vulnerable input field on a web application. It is not recommended to have a field that accepts user input without proper sanitization, which is commonly known as "No Bueno" in good development practices. Injection points typically store user-generated content for future display to other users or validation of the user's account within the application.
Payload Injection: The attacker crafts a malicious payload, JavaScript being the go-for since it is the browser's most used language.
Let's stop for one second and think of an attacker already having found a vulnerable injection point.
What can I do to break the most havoc in here? What type of code can I inject that, on user execution, would do the most harm?
Remember that as security researchers and good developers, we must think of everything literally.
We must be aware of the weak points in our application.
I use it as a thought exercise. Stopping and thinking: It is possible for a website to be defaced or for session tokens or cookies to be stolen, leading to redirection to a malicious website. It's essential to be aware of these possibilities and remain vigilant during development.
White hat hackers usually don't want to break anything, so we go with the loyal alert(1), as we will see in our example shortly.
Content submission: The attacker submits a crafted payload through the vulnerable input field.
Payload is stored on the server as it didn't undergo any type of validation, and it is safely awaiting to be executed on retrieval; data is most likely associated with the user.
Content Retrieval: When another user (victim) accesses the page where the injected content was stored, the server retrieves the malicious payload from the server and serves it alongside legitimate content.
Browser execution: The browser renders the content, including the malicious payload, as a part of the page process. Browsers cannot distinguish between malicious and legitimate code. Their job is to run the received code, which can make the user vulnerable and compromise their security.
Impact: The Attacker gains control over the victim's session, allowing them to impersonate the victim, access their account, and perform actions on their behalf.
EXAMPLE AND PoC (Proof of concept)
Let's jump straight into our example.
On January 25, 2019, a user named giddsec submitted a report whter disclosed by hackerOne on April 1 of the same year. The vulnerability was identified on "X" (previously known as Twitter), and it could potentially lead to data theft on network reports of users.
OnThe Proof of concept shows the attacker finding the Injection point on:
Company Information >> Edit.
The attacker then submits the payload on the edit field
Information is safely saved on the server, and retrieval executes as is being rendered by the browser.
I hope this example with a brief proof of concept helps with the overall explanation of the vulnerability. It certainly did for me as I better understood and categorized this type on a more narrow understanding. Still, there are lots more to do on our path to continue learning and growing.
As users, we need to be aware of a few simple things we can do to avoid falling victim to attackers who exploit XSS on websites or applications. As developers, there are many things we can do to avoid falling into practices that would lead to Stored XSS and, as Hackers, more ways to learn where the main flaws exist.
I will continue the XSS saga as is the current topic I'm working on.
Happy bug-hunting!
References
Yaworski, P. (2019). Real-world bug hunting: A field guide to web hacking. No Starch Press.
giddsec (2019, April 1). Report 485748 Stored XSS. HackerOne. https://hackerone.com/reports/485748