What is XSS?
“Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites.” -OWASP. This can happen when there are inputs from users that are unchecked. An attacker can inject a XSS attack by submitting valid code through user input forms, therefore altering the code of the program. There are different types of XSS attacks and strategies for how to protect against them. The categorization and description of different XSS has been a somewhat contentious point of discussion over the years and there are varied conventions and preferences for how to accurately refer to different types of XSS. As Ryan Oberfelder describes in his blog Describing XSS: The story hidden in time, “descriptions of XSS are living concepts, editable and expandable to uphold present understandings.” We will explore several of these distinctions in this blog.
Cross site scripting was first given this name in 1999 when a group of Microsoft security engineers recognized this type of attack, and later that year published an article naming it as Cross Site Scripting(XSS). The distinctions in cross site scripting at that point were Reflected and Stored. In 2005, DOM Based attacks were identified as a potential third sort of XSS. Later still the distinctions were a bit fuzzy and nowadays XSS can also be distinguished by Client vs Server side attacks.
REFLECTED XSS (Non-Persisted):
Reflected XSS is when malicious data from a user is sent to the server via a request and then is immediately returned as generated html with the malicious data included. For example, this could be in a hidden url including valid (but malicious) javascript code inside the url. When the malicious data gets back to the user via request and is loaded on the browser, it “weaponizes the injected code”. That code as an example could make another request containing user info to a site run by the malicious user to steal data about users. The following are examples from Oberfelder’s blog:
If this site,
utilizes a personal greeting with a link formatted like this,
a potential attack could look like this: 
STORED XSS (Persisted):
Stored (or Persisted) XSS attacks are when the malicious data is stored on a server and then passed to every user who interacts with the site via HTTP response. In other words, “The payload [is] stored and injected over and over, affecting anyone who requested certain pages”, Oberfelder. If we again go back to our example links, what if that same site 
has a Create New User functionality using this link 
.
This site would need to have input form for the user data. If an attackers for example made a username looking like this, 
that again when stored to the server could pull the user data via cookie and send it directly to the attacker. Depending on where in the site this attack is targeted and if there is access to a list of usernames for example, it could affect many users. “The key difference between reflected and stored XSS is that a stored XSS vulnerability enables attacks that are self-contained within the application itself.” -PortSwigger. Stored XSS attacks can generally affect many more people than reflected attacks.
DOM BASED XSS:
Dom based XSS attacks occur when information from one part of the DOM is written to another part of the DOM. we’ll return to Oberfelder’s example. Perhaps our example site 
has a footer element which is customized for the user and “appended dynamically”. If this link,
was sent to a user, it could again compromise the user’s info. This from the attackers perspective seems very much like a reflected attack but they are considered distinct by many because of the difference in strategy to prevent these attacks.
Server XSS vs Client XSS:
In 2012 the “research community” reorganized thoughts around how to describe the different cross site scripting attacks and came up with these distinctions. Server XSS are considered attacks where the problematic data is included in a HTTP response from the server. This could be reflected or could be stored data and therefor does not fit squarely into one of the original categories specified. “There are many different varieties of stored cross-site scripting. The location of the stored data within the application's response determines what type of payload is required to exploit it and might also affect the impact of the vulnerability.” -PortSwigger. Server vs Client distinctions deal more with where the origin of “payload” of the attack is stored.
How to Protect Against XSS Attacks:
The Open Web Application Security Project (OWASP) is a non-profit foundation, founded in 2001, dedicated to security improvements in software development.OWASP has detailed resources and “cheatsheets” detailing specific recommendations for protecting from specific types of attacks. However, they specify that generally a “White Listing” approach is generally a better more effective strategy than “Black Listing”. White listing is in essence, disallowing everything that is not specifically allowed. The top two rules that OWASP recommends developers to follow are the following:
- Never Insert Untrusted Data Except in Allowed Locations
- HTML Encode Before Inserting Untrusted Data into HTML Element Content
There are many more rules listed by OWASP that developers can explore to determine their security needs. Ultimately they recommend using a “security-focused encoding library” to ensure that the security rules are followed accurately. The technicality and implementation of the recommended rules will vary from situation to situation, but in short, a developer should limit the number of entry points that attackers can use, and protect those entry points using security libraries. Escaping alone is not enough to provide strong and stable security, however it can be a useful tool.
In conclusion, security can be a tricky business but especially when dealing with lots of user inputted data, it is a necessary concern.
Sources:
OWASP: https://owasp.org/www-community/attacks/xss/
https://owasp.org/www-community/Types_of_Cross-Site_Scripting
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#rule-0-never-insert-untrusted-data-except-in-allowed-locations
PortSwigger: https://portswigger.net/web-security/cross-site-scripting/stored
Ryan Oberfelder, Describing XSS: https://medium.com/@ryoberfelder/describing-xss-the-story-hidden-in-time-80c3600ffe81
Top comments (0)