OWASP Top 10 2017 – A7 Cross-site Scripting (XSS)

Jun 16, 2017

How to Resolve and Prevent XSS

Cross-site scripting (XSS) occurs when an attacker injects malicious script, like JavaScript, into your web browser which compromises an infected web site. When the user inputs data into the visited web site, the malicious code routes that input data to the attacker. Such XSS vulnerability resides in any place where the user can input data: a URL, a form, even a social media post. It is not only a home user threat. XSS can seriously damage your company because attack code can be written in endless ways causing more than rerouted and stolen data. It can create internal and external end-user issues that can cripple your site’s ability to generate revenue.

Kinds of Malicious XSS

JavaScript by nature is a dynamic, interpretative coding language that instructs something to run on your browser. XSS, therefore, can be somewhat innocuous if tapped into by the user. For example, the XSS vulnerability may be nothing more than taking you to an annoying web site. On the flip side, XSS vulnerabilities that hijack your site’s cookies, count keystrokes or phish for sensitive information, can be a platform for more damaging attacks like destroying customer order information, creating destructive user experiences, and ruining the business-to-customer relationship.

Here’s an example of how it happens:

You go to an XSS-injected web site and begin to fill out a form. The malicious code interprets your input, exploits, and executes the XSS vulnerability giving the attacker the desired information or data.

The code can be written and injected in a myriad of ways depending on the needs and creativity of the attacker. It can send the user blatant message or it can work behind the scenes unbeknownst to the victim. The bottom line is that malicious XSS is not to be trifled with and needs to be resolved by the individual end-user or by the infiltrated company.

The Three XSS Types

As noted, XSS takes three players to execute an injected script: the website, the user (victim), and the attacker. The attack can come from the server-side code or the client-side code.

Persistent (stored) XSS originates with the website database. This is a server-side attack and runs unbeknownst to the user. This is arguably the most damaging XSS code.
Reflected XSS (think echo) is brought on by victim request, that is, the user is often tricked into the malicious vulnerability. This is a server-side attack. This is the most common XSS code and is used in phishing schemes and social networks to gather insecure information.
DOM-based is non-HTML (rather Document Object Model) XSS that is a client-sided attack only. It is a mix of persistent and reflected XSS in that the legitimate script is run first before the malicious script is executed and sent to the attacker.

Inlay terms, XSS is a very common attack vector that can affect your servers and your clients. It can be benignly annoying by overtly leading you to an insecure page. Or, it can be quite dangerous, impacting your enterprise to the point of not only expensive financial recovery but your company’s reputation.

What XSS Can Do To Your Business

You are a target for XSS if you generate your revenue online or are part of large online communities like social media and entertainment and news sites. XSS attackers taking the time to design malicious code with the intent to inflict damage on your company are going to want the maximum return on their investment in the form of both internal and external damage.

Internal damage includes downtime caused by investigating, testing and resolving XSS issues. This leads to loss of employee productivity which means lost revenue for every minute of downtime. So if you are a 24/7 online company, you could calculate your lost revenue by the following equation:

Revenue loss = annual revenue/525,000 * t (minutes of downtime)

As you can see, downtime minutes count toward lost revenue, lost inventory, repair time, internal and external damage creating lost business opportunities, issues with public relations, brand, and reputation.

Resolving and Preventing XSS Attacks

Resolving XSS attacks is not a cut-and-dried process. The issue lies in the flexibility of the XSS code and the mindset of the attacker. Everything depends on how the malicious code injection is worded, interpreted by the browser, and executed. It is imperative to utilize all automated updates and patches to thwart unseen vulnerabilities. Once they are discovered, however, resolution takes some finesse and thoughtful coding to rid the exploitation. But the best resolution lies in prevention.

The best way to prevent XSS attacks is to provide secure input handling on both the server and client-side code. Web developers can prevent XSS by encoding and validation. Most of the time, encoding is enough to prevent XSS by having the browser interpret user input as data, not malicious code. When encoding is not enough, validation prevents XSS by filtering user input so that the browser construes the input as code and not malicious commands.

When encoding and validation together are not enough to completely neutralize XSS vulnerability, Content Security Policy alleviates risk by making sure that only trusted resources can be used by the page in question.

XSS gives attackers a foothold into your enterprise that can bring forth a plethora of legal, financial and security woes. From changing the face of your company’s web site to complete computer system hijacking, XSS is by far one of the most prevailing, risky web application vulnerabilities today.

Learn more in our complete OWASP Top 10 2017 series:

Get Your FREE Demo of Kiuwan Application Security Today!

Identify and remediate vulnerabilities with fast and efficient scanning and reporting. We are compliant with all security standards and offer tailored packages to mitigate your cyber risk within the SDLC.

FREE DEMO