Cross-Site Scripting, or XSS, is one of the most common vulnerabilities that threaten web applications today. It is so prevalent in modern application that it has been consistently named as one of the OWASP top ten vulnerabilities. Today, we’ll dive into what XSS vulnerabilities are, what stored XSS — the most dangerous type of XSS — are, and how to prevent them.
XSS is when an attacker can execute malicious scripts on a victim’s browser.
A lot of the time, applications use user input to construct web pages. And if that application cannot tell the difference between user input and the legitimate code that makes up a web page, attackers can submit input in the format of executable scripts and get that executed by the victim’s browser.
There are three main kinds of XSS: stored XSS, reflected XSS, and DOM XSS. The difference between these cross-site scripting flaws is how the malicious code is delivered to the victim. Today, we’ll focus on the most dangerous type of cross-site scripting: stored-XSS.
Stored XSS is when the XSS payload, or the malicious script, is stored on a server before being retrieved by the victim’s browser.
For example, let’s say an internet forum lets users post comments. When a user submits a comment to a post, that user input is rendered onto the webpage served to anyone who views that blog post. Normally, users would submit text comments like these:
Vickie: Thanks for this great post! Ben: I think this topic is more... Jo: Appreciate the discussion, in this case...
But now, what if an attacker submits a comment like this one?
<script>alert("XSS by Vickie");</script>
During a stored XSS attack, attackers save their malicious scripts on the target application’s server and wait for victims to access it. Every time users access the page, the malicious script executes in their browser. Stored XSS tends to be the most dangerous type of XSS because attackers can attack many victims with a single payload. And during a stored XSS attack, all the user has to do to become a victim is to view a page with the embedded payload, whereas reflected and DOM XSS usually require the victim to click a malicious link.
So how could you prevent XSS?
First of all, remember that you should never trust user-submitted input! To prevent XSS, you should make sure that user-submitted input doesn’t contain dangerous characters that might influence the way browsers interpret the information on your webpage. You can do that by implementing robust input validation and output escaping.
You can validate user input and reject input that might contain malicious payloads. For example, user input containing the string “” is a good indicator that the input contains an XSS payload. In this case, you could block the request. Although, keep in mind that it’s better to be strict and explicitly allow a limited set of characters, such as alphanumerics, instead of disallowing known malicious strings because attackers can often bypass these protections by triggering XSS in a different way.
You can also escape special characters in a user’s input before rendering it on a webpage. Escaping means encoding special characters so that they are interpreted literally instead of as a special character by the pro-
There are also ways you can limit the damage an attacker can cause if an XSS bug does happen. To prevent attackers from stealing user cookies via XSS attacks, you should also set the HttpOnly flag on sensitive cookies on your site. Finally, you can instruct the browser to execute only scripts from a list of sources by using the Content-Security-Policy HTTP response header.
But what can you do about the XSS vulnerabilities that already exist in your code? You can detect them by scanning your code with a static analysis (SAST) tool and fix them with one of the strategies I mentioned in this post. Code analysis or static analysis can identify the points in your application where XSS protection is missing and is the most efficient way of uncovering XSS in your applications. ShiftLeft’s static analysis tool NG-SAST can find the cross-site scripting bugs in your code and help you fix them. Learn more by visiting us here.
Thanks for reading! What is the most challenging part of developing secure software for you? I’d love to know. Feel free to connect on Twitter @vickieli7 .