Stored XSS, explained: How to prevent stored XSS in your app (2022)

Web applications are one of the most targeted assets these days because they’re both open to the internet and have a larger attack surface. Attackers find various ways to hack web applications. And among all of those techniques, some make it to the OWASP Top Ten list of security risks. Cross-site scripting (XSS) has been one of the consistent toppers of this list, and in this post, we’ll discuss in detail one variant of cross-site scripting—stored XSS.

What is stored XSS?

XSS is a technique of injecting malicious code into a vulnerable web application. Unlike other attacks, the goal however isn’t to run it on your server, but on your users’ browsers! Depending on the attacker’s creativity and skills, this malicious code can steal sensitive information from a user, impersonate a user, or even perform some actions on behalf of the user. A couple of examples of how XSS could be dangerous are as follows:

  • Stealing session and cookie details of an admin user that could be used to get access to the admin account.
  • Having the malicious code make a financial transaction from a victim’s account to the attacker’s account.

Based on the nature of the technique (and not on the outcome), XSS can be categorized into multiple types:

  1. Reflected XSS
  2. Stored XSS
  3. DOM-based XSS

For this post, let’s stick to stored XSS.

In stored XSS, the malicious code is stored on the server of the application. Stored XSS is possible only when the application is designed to store user input. The attacker would inject the code through requests to the application. After receiving this data, the application may then store the malicious code on the server or in a database. Hence the name stored XSS.

(Video) Stored Cross-Site Scripting (Stored XSS) Explained

How stored XSS works

Let’s take an example of online forums—something like Stack Overflow. Such applications let users post content on the application, and then serve it to other users. Suppose an attacker finds out that such an application is vulnerable to stored XSS in a comment field; the attacker can then inject their malicious payload into the application. After this, every time a user visits this web page or content, the application would fetch this data from the database and display it to the user. And while doing so, the application would serve the malicious code to the user.

Stored XSS, explained: How to prevent stored XSS in your app (1)

Let’s say that an attacker wants to steal session cookies from all users visiting a page. The attacker would first craft a malicious code that would get the cookie details from a browser and send it to the attacker. Then the attacker would inject this malicious code into the vulnerable application on their target page in the form of a comment. The vulnerable application would store the comment along with the malicious code. Now, whenever any user visits the targeted page, the content of the page along with the comment from the attacker and the malicious code are sent to the user’s browser, where it becomes a standard XSS. When the browser is rendering the page, it will run the malicious code, steal cookies from the user, and send them to the attacker.

And that’s how an attacker can use stored XSS to achieve their malicious goals.

Why stored XSS matters

Out of the three types of XSS, attackers are most interested by stored XSS. The reason for that is that the reach of the malicious code through stored XSS is enormous. It takes fewer resources to target a larger number of victims. And once the malicious code is in place, its effect is continuous. If stored XSS isn’t identified and mitigated, the malicious code will keep doing its job for a ton of users and can go on for decades.

Another advantage of stored XSS is that even if infected, users have no way to know they should be careful. For example, Facebook is a well-established platform. It’s been around for a long time and has developed a factor of trust within users. You wouldn’t think a lot before opening a post on Facebook because you believe it can be trusted. But you would think twice before opening a link to/from an unknown application/email (like in the case of reflected XSS) just because you don’t know if it’s safe. If such well-established applications are vulnerable to stored XSS, it makes it even easier for the attackers to lengthen their victim list.

(Video) Cross-Site Scripting Explained with Examples and How to Prevent XSS with Content Security Policy

These reasons make stored XSS vulnerability a jackpot for attackers. Hence, it’s critical for organizations to implement measures to avoid stored XSS.

How to avoid XSS vulnerabilities in your code

Stored XSS are all about getting a malicious parameter reflected to the user. So the straightforward approach to avoid XSS vulnerabilities is to sanitize user data and handle inputs safely. Let’s look at an example and understand how sanitizing data would mitigate XSS.

Let’s say an application has an input form field where it accepts user input, stores it, and then displays it back when requested. For example, if the user input is Tony, the application would store the string Tony in its data store, and when this data is requested, it would display Tony.

If the application was written using PHP, the line to display data would look something like this:

echo "<h2>" . $name . "</h2>";

(Video) What is Stored XSS - Web App Vulnerabilities - Part -(2-2)

Here, $name would hold the data fetch from storage—i.e., Tony.

This line of code when rendered would look something like this:

"<h2> Tony </h2>"

Now let’s say that instead of giving Tony as input, the attacker gave <script>alert("XSS")</script> as input. The input isn’t just a regular string; it’s a malicious code. When this script is rendered on the browser when requested, it would look something like this:

echo "<h2> <script>alert("XSS")</script> </h2>";

(Video) OWASP Attacks and their Prevention || Cross Site Scripting || Stored XSS Attack

In this case, the browser would consider the script tags as part of the response and execute the code. The reason the malicious code executes was that the input wasn’t sanitized.

You have multiple ways to prevent an XSS, as discussed here. The most efficient of them are as follows:

  • Using HTML encoding
  • Applying appropriate response headers
  • Using an Auto-Escaping Template System

How to block XSS attacks in real time

HTML encoding and other mitigations work, but it’s easy to forget them somewhere in your legacy code. A response to this is to add a dynamic protection that will scan for exploitation attempts. This way even if a hole exists, the attacker won’t be able to take advantage of it.

Web application firewalls (WAFs) have become popular over the years for web application security. You can use a WAF to detect and prevent XSS attacks in real time. WAFs can analyze traffic metrics such as sessions, packet size, and various patterns and then decide whether to block or allow the traffic. But the problem with WAFs is they’re only as good as the database of signatures. You can’t possibly have all attack signatures in your database (your app is unique after all!). By the time you add 100 patterns, there are 1,000 new ones, and the ones you have each generate some amount of noise. WAFs provide great attack detection for applications, and they’re one of the essential methods of boosting security. But WAFs alone aren’t enough. To have the best protection against XSS, you need to go beyond hardcoded logic and WAFs.

This is where Sqreen comes in. Sqreen gives you more visibility into your application. And in cybersecurity, more visibility means staying one step ahead. Using Sqreen, you can run the basic and most popular XSS checks and decide what to do with malicious detection. Sqreen provides multi-layer protection for your application, and its runtime application self-protection (RASP) examines application behavior to prevent exploits in real time.

(Video) How To Prevent The Most Common Cross Site Scripting Attack

Need a complete security package for your application? You can sign up for a free Sqreen trial here.

This post was written by Omkar Hiremath. Omkar is a cybersecurity analyst who is enthusiastic about cybersecurity, ethical hacking, data science, and Python. He’s a part time bug bounty hunter and is keenly interested in vulnerability and malware analysis.

FAQs

What can you do with stored XSS? ›

Stored XSS, also known as Type-1 or Persistent XSS attacks, typically rely on unsanitized user input points for scripts permanently stored on the target servers. Since these attacks allow malicious users to control how the browser executes a script, they can typically facilitate a complete user account takeover.

Is encoding enough to prevent XSS? ›

Encoding is probably the most important line of XSS defense, but it is not sufficient to prevent XSS vulnerabilities in every context. You should also validate input as strictly as possible at the point when it is first received from a user.

What is XSS stored attack? ›

Stored XSS, also known as persistent XSS, is the more damaging of the two. It occurs when a malicious script is injected directly into a vulnerable web application. Reflected XSS involves the reflecting of a malicious script off of a web application, onto a user's browser.

Where is stored XSS stored? ›

Stored XSS Attacks

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. The victim then retrieves the malicious script from the server when it requests the stored information.

Where is XSS stored? ›

Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser.

Which function is used to prevent XSS injection attacks? ›

The surest way to prevent XSS attacks is to distrust user input. All user input rendered as part of HTML output should be treated as untrusted, whether it is from an authenticated user or not.

Is escaping enough for XSS? ›

The short answer is no, it's not enough. The long answer is it depends on the context of where the user data goes. In an attribute it definitely will not be safe. In the body of certain tags, etc...

Does input validation prevent XSS? ›

Input validation is a technique that provides security to certain forms of data, specific to certain attacks and cannot be reliably applied as a general security rule. Input validation should not be used as the primary method of preventing XSS, SQL Injection and other attacks.

Which of the following is the most effective defense against reflected stored XSS? ›

XSS attack prevention. Developers should validate user input -- sources -- and encode the output -- sinks -- to prevent DOM-based XSS attacks. The input source property is where the DOM reads from, and the source is where the attacker can inject malicious code to exploit the XSS vulnerability.

What are the two primary defenses against XSS attacks? ›

4 Answers
  • Specifying a charset. ...
  • HTML escaping. ...
  • Other types of escaping. ...
  • Validating URLs and CSS values. ...
  • Not allowing user-provided HTML. ...
  • Preventing DOM-based XSS.
28 Jun 2010

Which of the following is one of the most effective ways to prevent cross-site scripting XSS flaws in software applications? ›

Which of the following is most effective to prevent Cross Site Scripting flaws in software applications? Use digital certificates to authenticate a server prior to sending data.

How are stored XSS payloads usually stored on a website? ›

Typical Entry Points for Stored XSS

Stored XSS requires user supplied input to be stored by the application (making it persistent) and rendered within the page.

What is XSS attack with example? ›

Examples of reflected cross-site scripting attacks include when an attacker stores malicious script in the data sent from a website's search or contact form. A typical example of reflected cross-site scripting is a search form, where visitors sends their search query to the server, and only they see the result.

Does stored XSS require user interaction? ›

Both vulnerabilities do require that the user visits a malicious/compromised site, but they do not necessarily require user interaction. Persistent XSS vulnerabilities store the user input and include it later outputs (e.g. a posting in a forum).

Is stored XSS critical? ›

Stored XSS is often considered a high or critical risk.

Is stored XSS server side? ›

Cross-site scripting (XSS) is one of the most dangerous vulnerabilities in web applications. It is a client-side script injection technique that attackers can use to steal information or send malicious requests to a server.

What is XSS and how it works? ›

Cross site scripting (XSS) is an attack in which an attacker injects malicious executable scripts into the code of a trusted application or website. Attackers often initiate an XSS attack by sending a malicious link to a user and enticing the user to click it.

What is the difference between reflected XSS and stored XSS? ›

What is the difference between reflected XSS and stored XSS? Reflected XSS arises when an application takes some input from an HTTP request and embeds that input into the immediate response in an unsafe way. With stored XSS, the application instead stores the input and embeds it into a later response in an unsafe way.

What is XSS and its types? ›

Types of XSS: Stored XSS, Reflected XSS and DOM-based XSS. Cross-site Scripting attacks (XSS) can be used by attackers to undermine application security in many ways. It is most often used to steal session cookies, which allows the attacker to impersonate the victim.

What is the main cause of XSS vulnerabilities? ›

The root cause of XSS vulnerabilities is when a web application uses untrusted input without performing proper validation first. If a web server embeds user input in a page's HTML code before sending it to the client, then malicious input could enable the execution of attacker-controlled code within the user's browser.

How can injection attacks be prevented? ›

How to prevent SQL injection attacks. Avoid placing user-provided input directly into SQL statements. Prefer prepared statements and parameterized queries, which are much safer. Stored procedures are also usually safer than dynamic SQL.

What is used to prevent injection attacks? ›

The only sure way to prevent SQL Injection attacks is input validation and parametrized queries including prepared statements. The application code should never use the input directly. The developer must sanitize all input, not only web form inputs such as login forms.

Does Chrome prevent XSS? ›

Bookmark this question. Show activity on this post. Is it possible to temporarily disable the XSS protection found in modern browsers for testing purposes? However, it appears that both Chrome and Firefox are preventing the XSS popup.

How common are XSS vulnerabilities? ›

Cross-site scripting (often shortened to XSS) is a common security vulnerability that is more prevalent in web applications. It's estimated that more than 60% of web applications are susceptible to XSS attacks, which eventually account for more than 30% of all web application attacks.

Is XSS still a threat? ›

Despite their longstanding reputation as a significant infosec problem, XSS attacks have remained a constant of the OWASP Top 10 Web Application Security Risks year after year and still make headlines.

Does XSS steal data? ›

A cross-site scripting attack is mostly executed to steal cookies, hijack users' sessions, and compromise accounts. Threat actors can then impersonate you, exploit your data, and even access your device's geolocation, microphone, webcam, files, etc. An XSS attack isn't just an end user threat, though.

What Should data validation prevent? ›

Users are not copying or filling data - Data validation is designed to show messages and prevent invalid entries only when users type data directly in a cell. When data is copied or filled, the messages do not appear.

Which of the following filtering techniques prevents all cross-site scripting XSS vulnerabilities? ›

Which of the following filtering techniques prevents all cross-site scripting (XSS) vulnerabilities? vulnerabilities? A. Enable magic_quotes_gpc .

What can Attackers do with XSS vulnerability? ›

Stealing Cookies Using XSS

The attacker injects a payload into the website's database by submitting a vulnerable form with malicious JavaScript content. The victim requests the web page from the web server. The web server serves the victim's browser the page with attacker's payload as part of the HTML body.

Which security header defend against cross-site scripting? ›

The X-XSS-Protection header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it.

Can XSS access local storage? ›

XSS attacks inject malicious scripts into web applications, and unfortunately, both LocalStorage and SessionStorage are vulnerable to XSS attacks. XSS attacks can be used to get data from storage objects and add malicious scripts to the data stored.

Is XSS one of the common web application attacks? ›

Cross-site scripting (XSS)

According to the Open Web Application Security Project, XSS was the seventh most common Web app vulnerability in 2017. These attacks succeed if the Web app does not employ enough validation or encoding.

Which is the most common type of XSS attack? ›

Non-persistent (reflected) XSS is the most common type of cross-site scripting. In this type of attack, the injected malicious script is "reflected" off the web server as a response that includes some or all of the input sent to the server as part of the request.

What is basic XSS? ›

Cross-site scripting attacks, also called XSS attacks, are a type of injection attack that injects malicious code into otherwise safe websites. An attacker will use a flaw in a target web application to send some kind of malicious code, most commonly client-side JavaScript, to an end user.

Can XSS be prevented without modifying the source code? ›

One of the most common XSS attacks is the theft of cookies (especially session ids). The HttpOnly flag was created to mitigate this threat by ensuring that Cookie values cannot be accessed by client side scripts like JavaScript. This is accomplished by simply appending " ; HttpOnly " to a cookie value.

What can you steal with XSS? ›

Stealing cookies is a traditional way to exploit XSS. Most web applications use cookies for session handling. You can exploit cross-site scripting vulnerabilities to send the victim's cookies to your own domain, then manually inject the cookies into the browser and impersonate the victim.

Is stored XSS critical? ›

Stored XSS is often considered a high or critical risk.

Can XSS be used to steal cookies? ›

Cookie Theft

This generally happens when the site has a vulnerability and the attacker uses something known as cross-site scripting (XSS) to exploit that vulnerability.

Can XSS payloads be stored in a database? ›

Stored XSS (Persistent XSS)

An attacker uses Stored XSS to inject malicious content (referred to as the payload), most often JavaScript code, into the target application. If there is no input validation, this malicious code is permanently stored (persisted) by the target application, for example within a database.

What is the main cause of XSS vulnerabilities? ›

The root cause of XSS vulnerabilities is when a web application uses untrusted input without performing proper validation first. If a web server embeds user input in a page's HTML code before sending it to the client, then malicious input could enable the execution of attacker-controlled code within the user's browser.

Why do hackers use XSS? ›

Because XSS can allow untrusted users to execute code in the browser of trusted users and access some types of data, such as session cookies, an XSS vulnerability may allow an attacker to take data from users and dynamically include it in web pages and take control of a site or an application if an administrative or a ...

What are the two primary defenses against XSS attacks? ›

4 Answers
  • Specifying a charset. ...
  • HTML escaping. ...
  • Other types of escaping. ...
  • Validating URLs and CSS values. ...
  • Not allowing user-provided HTML. ...
  • Preventing DOM-based XSS.
28 Jun 2010

How are stored XSS payloads usually stored on a website? ›

Typical Entry Points for Stored XSS

Stored XSS requires user supplied input to be stored by the application (making it persistent) and rendered within the page.

Does stored XSS require user interaction? ›

Both vulnerabilities do require that the user visits a malicious/compromised site, but they do not necessarily require user interaction. Persistent XSS vulnerabilities store the user input and include it later outputs (e.g. a posting in a forum).

What is the difference between XSS stored and XSS reflected? ›

What is the difference between reflected XSS and stored XSS? Reflected XSS arises when an application takes some input from an HTTP request and embeds that input into the immediate response in an unsafe way. With stored XSS, the application instead stores the input and embeds it into a later response in an unsafe way.

Does Chrome protect from XSS? ›

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.

What is an example of XSS? ›

Examples of reflected cross-site scripting attacks include when an attacker stores malicious script in the data sent from a website's search or contact form. A typical example of reflected cross-site scripting is a search form, where visitors sends their search query to the server, and only they see the result.

Which function is used to prevent XSS injection attacks? ›

The surest way to prevent XSS attacks is to distrust user input. All user input rendered as part of HTML output should be treated as untrusted, whether it is from an authenticated user or not.

Is stored XSS server side? ›

Cross-site scripting (XSS) is one of the most dangerous vulnerabilities in web applications. It is a client-side script injection technique that attackers can use to steal information or send malicious requests to a server.

Can XSS access local storage? ›

XSS attacks inject malicious scripts into web applications, and unfortunately, both LocalStorage and SessionStorage are vulnerable to XSS attacks. XSS attacks can be used to get data from storage objects and add malicious scripts to the data stored.

Can content security policy prevent XSS? ›

What is CSP (content security policy)? CSP is a browser security mechanism that aims to mitigate XSS and some other attacks. It works by restricting the resources (such as scripts and images) that a page can load and restricting whether a page can be framed by other pages.

Videos

1. Cross-Site Scripting Lab Breakdown: Stored XSS into HTML context with nothing encoded
(Seven Seas Security)
2. Stored XSS Simplified!
(intigriti)
3. Stored XSS in iOS Outlook ($3000)
(kyaw mt)
4. Content Security Policy explained | how to protect against Cross Site Scripting (XSS)
(productioncoder)
5. 12 - XSS (Stored) (low/med/high) - Damn Vulnerable Web Application (DVWA)
(CryptoCat)
6. Cross Site Scripting (Stored XSS) | XSS Stored - Low,Medium,High | DVWA | Bug Bounty | Stored XSS
(Hacking With NSK)

Top Articles

You might also like

Latest Posts

Article information

Author: Cheryll Lueilwitz

Last Updated: 11/18/2022

Views: 5740

Rating: 4.3 / 5 (74 voted)

Reviews: 89% of readers found this page helpful

Author information

Name: Cheryll Lueilwitz

Birthday: 1997-12-23

Address: 4653 O'Kon Hill, Lake Juanstad, AR 65469

Phone: +494124489301

Job: Marketing Representative

Hobby: Reading, Ice skating, Foraging, BASE jumping, Hiking, Skateboarding, Kayaking

Introduction: My name is Cheryll Lueilwitz, I am a sparkling, clean, super, lucky, joyous, outstanding, lucky person who loves writing and wants to share my knowledge and understanding with you.