{"id":14295,"date":"2021-03-19T07:59:00","date_gmt":"2021-03-19T11:59:00","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=14295"},"modified":"2021-03-18T17:47:46","modified_gmt":"2021-03-18T21:47:46","slug":"the-ultimate-guide-to-stored-xss-attacks","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/the-ultimate-guide-to-stored-xss-attacks\/","title":{"rendered":"The Ultimate Guide to Stored XSS Attacks"},"content":{"rendered":"\n

Stored XSS Attacks, Also Known as Persistent XSS Attacks, Are the Type With the Farthest Reach and Highest Potential Damage<\/h2>\n\n\n\n

Recently, we took a closer look at one of the items on the OWASP Top 10 Vulnerability List<\/a> \u2013 cross-site scripting (XSS). In that post, we covered the basics of XSS attacks<\/a> and performed a quick overview on each of the various types of XSS. Today, we\u2019re going to continue our series on XSS and do a deep dive on one of those specific types of XSS attack \u2013 Stored XSS, also commonly referred to as Persistent XSS.<\/p>\n\n\n\n

Stored XSS can end up being the most dangerous type of XSS attack because of the way they\u2019re carried out. Which scenario results in the most overall damage \u2013 a) a bad guy targets every single person that visits an ATM via a card scanner that\u2019s planted within the machine, or b) he instead sneaks up behind a single, particular person and watches as he enters their PIN. The former scenario would end up having a broader and more severe effect because the hacking device (the card scanner) is stored on the ATM, and thus every single person that accesses is potentially a victim.<\/p>\n\n\n\n

Stored XSS works in a similar manner. The attack vector ends up being permanently stored (hence the name) on the website\u2019s server, and anyone that accesses the page thus becomes susceptible to the affects of the malicious code that lives there. Persistent XSS attacks are therefore such a significant threat because they can have such a wide-ranging reach and do not require a social engineering phase (like Reflected XSS attacks do, which we\u2019ll cover in our next installment of this series) to get users to take a specific action like clicking a link.<\/p>\n\n\n\n

So, how exactly do Stored XSS attacks work? What are the consequences of a successful attack? What does a real-world attack scenario look like? And most importantly, how can you protect against them?<\/p>\n\n\n\n

Let\u2019s hash it out.<\/span><\/p>\n\n\n\n

How Do Stored XSS Attacks Work?<\/h2>\n\n\n\n

Persistent cross-site scripting attacks are able to occur when sites or web applications allow user input but don\u2019t properly sanitize or restrict the contents of it. This allows for malicious code to be entered as input, which is then stored on the server and displayed to unsuspecting site visitors.<\/p>\n\n\n\n

For example, if a hacker was able to include a malicious script when posting a comment on a popular blog, every person who read that blog article would be exposed to the malicious script. The attacker\u2019s code is incorrectly treated as valid input by the site in question and doesn\u2019t get properly encoded as a result.<\/p>\n\n\n\n

\"\"
An example of a text input field that could potentially be vulnerable to a Stored XSS attack.<\/em><\/figcaption><\/figure><\/div>\n\n\n\n

Now that the malicious code has a persistent presence on the target site, it will be executed every time a visitor accesses the page. The browser allows it because its same-origin policy is being circumvented \u2013 it would normally block the code but doesn\u2019t in this case because it\u2019s seemingly coming from a valid page. And to make matters worse, the stored nature of the script means that it subsequently gets served to every single user that triggers the script execution on the compromised page.<\/p>\n\n\n\n

Text input fields are the most common place for the injection to occur, but locations that don\u2019t normally contain scripts (like image tags or event attributes) are also prime targets. Any element that isn\u2019t subject to input validation, encoding, or filtering can possibly be taken advantage of by an attacker.<\/p>\n\n\n\n

Stored XSS is relatively easy for hackers to pull off because all they have to do after finding a vulnerable site is simply inject their evil code and sit back and wait for victims to pay it a visit (hackers will sometimes actively promote their handiwork via spam messages or social media posts, though). Locating the target site itself is the hardest part of the process. The kinds of vulnerabilities required don\u2019t exactly grow on trees and preventing them is usually one of the top priorities for administrators of at-risk sites.<\/p>\n\n\n\n

The process for finding a vulnerable target usually goes as follows:<\/p>\n\n\n\n

  1. An attacker finds a website that may be vulnerable<\/li>
  2. They test it by attempting to store a script on the server and exploit the vulnerability<\/li>
  3. They navigate to the page that would deliver the malicious code<\/li>
  4. They check to see if the script executes<\/li><\/ol>\n\n\n\n

    This is most often a manual process, however automated tools do exist that are capable of automatically and remotely injecting scripts.<\/p>\n\n\n\n

    Not only does an attacker need to find a weakness that allows for permanent script embedding, but they also need to find a website with sufficient traffic in order to make it worth their while.<\/p>\n\n\n\n

    The Primary Targets of Stored XSS Attacks<\/h3>\n\n\n\n

    Pretty much any site that allows for the sharing of content by users is a potential target for Persistent XSS attacks. Think anywhere that has comment fields or text boxes for user inputs, and any sites where that input is then stored and displayed to other users. Typical targets include:<\/p>\n\n\n\n