What is Cross-Site Scripting (XSS)?

In the world of technology which is constantly growing and improving comes with increased risks and security vulnerabilities that those with malicious intent seek to take advantage. Cross-Site Scripting (XSS) is one such method which is primarily used in web-applications to allow the attacker to inject client-side scripts onto web pages. This type of attack is called code injection. Unsuspecting users then view these web pages which then give the attacker a means of bypassing authorization for access controls. One such access control is the same-origin policy which follows that a script running on a web page is allowed to run on the same web page only if they are both of the same origin (URI scheme, hostname, and port number). Typically, this would prevent a malicious script from one web page to go to another web page and access sensitive data and information; however, XSS bypasses this by taking advantage of security flaws in web applications' servers or plug-in systems. Once the attacker has successfully taken advantage of one of these vulnerabilities and compromised the site, unsuspecting victims have basically granted the script the same level of permissions they would have given to the site, such as access to cookies. This would then allow the attacker to view any sensitive information a user might be inputting onto the site ranging from passwords to credit card information. The website's page content, session cookies, and browser-maintained information would all be accessible by the attacker at this point.

Types of Cross-Site Scripting

Since the term's creation back in the year 2000, it's meaning has somewhat expanded in more recent years. Originally, it was used to refer to the act of loading a 3rd party web application with some piece of JavaScript code; that is, taking advantage of a non-persistent XSS vulnerability. Since then, the term has expanded to include persistent and non-JavaScript vectors such as VBScript, ActiveX, Flash, and even HTML. As such, most have classified the flaws associated with two types; persistent and non-persistent XSS flaws.

The persistent XSS flaw, sometimes called, the stored XSS flaw, occurs when the data is saved by the web server and then displayed on the web page as if everything was fine because the web page does not use HTML escaping. The compromised data is usually stored and displayed permanently on the web-page, hence the name and why this type is the more destructive of the two. For example, if users populated online forums or message board and while they might have provided their profiles with their full details, they might restrict some of that information from being visible to others. This does, however, mean that the information is still stored on the server. An attacker could join a forum and implement their script in a clever way on their profile, encased in the <script> tag so that it doesn't appear on their profile when others visit it. Then, when unsuspecting people visit our attacker's profile, their script is run automatically and sends all of their information from their very own computer directly to the attacker's server. Throughout the entire process, the user is oblivious to the entire process while their information is being divulged without their consent. Web sites such as online message boards, forums, and social media are actually the main targets of these exploitations. Even Twitter and Facebook were quite riddled with them in their earliest stages.

The non-persistent XSS flaw, or the reflected XSS flaw, is more basic and common than its counterpart and occurs when data is inputted and is being used in without being sanitized. This is more commonly found when the data is used for HTTP query parameters such as a form submission. As HTML files are flat in nature and structure with a mixture of control statements, formatting, and actual web-content, user inputted data needs to be validated to avoid possible code injection. For example, any web application which uses a search function typically accepts the user input and displays it once again; word-for-word, on the results web page. As such, if the user input is not properly validated and rejects HTML keywords, it is very likely to be injected as HTML. This is typically done from a neutral website or an email which is typically a URL which looks harmless and leads to a trustworthy website. Unfortunately, however, somewhere on the website will have the script and if the website suffers from this XSS flaw, the unsuspecting user will execute the script the moment they open the URL.

While these two types are most dominant and common classifications of XSS vulnerabilities, it doesn't just stop there as it can be further broken down into traditional vulnerabilities (server-side XSS flaws, as those discussed above) and DOM-based vulnerabilities as well. As time progressed, users preferred web applications with user experience in mind and thus, there was an increased in using applications which fulfilled this; applications which typically used JavaScript on the client-side and pulled data on-demand from the server using AJAX. While this would be processing, an attacker could take advantage of this through the same methods of a non-persistent XSS attack; and thus, DOM-based cross-site scripting came into being. In this scenario, the code never reaches the server and is instead reflected by the JavaScript; meaning, it all happens entirely on the client-side.

Some other notable mentions of XSS flaws are Self-XSS and Mutated XSS. In the case of the former, this is done through social engineering to trick a victim into executing the malicious script on their own. It's technically not an XSS vulnerability as it relies on tricking an individual through social engineering, it still carries with it the same risk as the aforementioned XSS vulnerabilities. Mutated XSS (mXSS) is when the attacker's code injection looks safe to the browser but is then changed in some way by the browser. This method is difficult to identify and therefore; sanitize, and could be something as simple as the browser adding closing quotation marks to an unclosed parameter.

Preventative Measures

Thankfully, there exists some measures which can be put in place through good practice and at the forefront of the list is output encoding and input escaping. Basically, this would be achieved through the process of using the suited escaping scheme depending on where the untrusted string needs to be within an HTML file. This includes HTML entity encoding, JavaScript escaping, CSS escaping, and URL encoding. These methods go a long way for preventing XSS vulnerabilities for web applications which don't accept rich data although; using an security encoding library might be better as oppose to using HTML entity encoding on the 5 XML keywords (quotation mark, ampersand, apostrophe, less-than sign, and greater-than sign) which is usually recommended.

Another method is using an HTML sanitizer or sanitization engine, something which is usually done by email applications and forums which allow the use of limited HTML markup. These engines typically function by blacklisting certain HTML markup which have a higher risk of being malicious (such as <script>, <link>, and <iframe>). Admittedly, however, this method still has some flaws as not all possible keywords are accounted for (<img src="javascript:doSomethingEvil()"> could bypass most of these engines, for example).

There also exists measures which do not focus on content-filtering such as adding additional security when using cookie-based user authentication. As session cookies are the primary use of many web applications for verification between HTTP requests, many web applications tie the user's IP Address to a cookie so that only that person can access the cookie. This process mitigates the threat of XSS attack; especially if the attacker is only after that cookie; however, this becomes less effective in scenarios of the attacker being behind the same network address translated (NATed) IP Address or web proxy as the target, or if the victim changes their mobile IP Address (MIP).

Another method is simply disabling scripts on the web application altogether. Granted, AJAX and Web2.0 developers will require JavaScript to run their web applications, but there does exist some which can be operated without the need. In these scenarios, users could disable their web browser from running scripts altogether and therefore; even if a malicious script is unescaped and entered onto the web page, the script could not run as there are no XSS vulnerabilities on the user's browser. Some browsers developed built-in functionality and add-ons which encapsulate this by allowing configuration to disable scripts on a per-domain basis. The reason it is done in this way is because if scripting is on by default, it would only block compromised websites only after discovering they are compromised; meaning, the script would've already been executed and it would be already too late. Some plugins even go a step further, such as Mozilla Firefox's NoScript add-on which adds further XSS security measures. The main drawback of this method, however, is that by blocking all scripts on a website, its functionality and responsiveness will be significantly reduced as client-side scripting is usually much faster than server-side scripting. Another flaw is that most users are not knowledgeable in the area and therefore; do not know how to do it, but the biggest flaw is that some websites cannot function without client-side scripting; meaning, with this method, a user would not be able to access every website freely.

As always, as the world of technology is constantly growing, there are emerging technologies which seek to help prevent XSS threats as well. At the moment, there are three classes of these: the Content Security Policy which provides a standardized method for website owners to declare approved origins of all website content, JavaScript sandbox tools such as Angular.js, and auto-escaping templates. As growth in the technology space continues, these three classes of prevention are sure to grow and improve as well with due time, but for now, the best thing to do is to make use of the current methods available.