Everything You Need to Know About Cross-Site Scripting Attacks

Loading…

February 12, 2021 0

XSS Attacks Are One of the Most Common Type and Pose Major Risks to Both Your Users and Website – Learn What They Are and How to Protect Yourself

Editor’s note: This is the first in a series of articles on XSS attacks. We’re starting this week with a broad overview of Cross-Site Scripting and will continue in the next few months with more detailed deep-dives on the specific types of XSS attacks. Stay tuned!

When you imagine a cyberattack, what do you think of, exactly? Many of us will conjure up images of a hacker gaining access to our machine and running rampant once inside. Or perhaps you’ll picture a web application being directly targeted via SQL injection or a similar attack vector. However, one of the most common types of website vulnerabilities targets the visitors of a website instead. We’re talking about Cross-Site Scripting (XSS) attacks, which occur when hackers execute malicious code within the victim’s browser.

Just how common are XSS attacks? For starters they’re a prominent item on the OWASP Top 10 Vulnerabilities list. Since 2014, Cross-Site Scripting vulnerabilities have been the most common type discovered on websites:

And if that’s not enough, Positive Technologies found in their 2019 report that over two-thirds of all sites they tested contained XSS vulnerabilities:

XSS attacks can be extremely dangerous to both your visitors and your website. Cross-site scripting attacks target their victims indiscriminately, making them all the more effective for attackers. The hackers simply exploit an XSS vulnerability in the site, which then allows malicious scripts to ultimately be run on the user’s machine. Anyone that visits the site or clicks the links will unsuspectingly be exposed.

So, what are cross-site scripting attacks and how do they work? What are the different types? How can you prevent them? And if you’ve been hacked with an XSS attack, how do you fix your website?

Let’s hash it out.

What Are XSS Attacks?

Cross-site scripting attacks happen when an attacker executes a malicious piece of code within a user’s browser. It’s important to remember that the hacker isn’t actually taking over the website at all, rather they are injecting their code as an element of the website itself. That’s how the code ends up being executed – the browser is tricked into it and thinks it’s just another piece of the website.

The kind of sites that are most vulnerable to XSS attacks are those that allow user input on their pages. We’re talking message boards, forums, site search features, and any page that allows user comments. If the right precautions aren’t taken, then XSS attacks can occur in:

• JavaScript
• VBScript
• ActiveX
• Flash
• CSS

The severity of the XSS attacks can vary widely depending on the website itself and the contents of the malicious code. Regardless though, the outcome is never good. Cross-site scripting attacks are most commonly used for:

• Taking over user accounts
• Trick users into giving out personal data
• Capturing login credentials
• Stealing session cookies
• Defacing websites
• Injecting trojans

How Do XSS Attacks Work?

JavaScript is most often used to carry out XSS attacks. The attacker first finds a vulnerability within a website that will allow for the script to be executed, and then they inject it. These scripts are called “client-side” scripts because they are performed on the “client” or user’s end of things, as opposed to a “server-side” script that would run on the website’s server.

More specifically, these “client-side” scripts run on the user’s browser when the compromised page is loaded. Because of this, sensitive information can be gathered from the session, which hackers can use in a wide variety of ways. This ranges from simply targeting individual users to get information of value from their accounts to targeting administrators and ultimately taking over the entire website.

The injected code itself can also have a wide range of functionality. Some attackers will target users with ads or phishing prompts, while others will be more subtle and design their code to work behind the scenes. The capabilities that hackers now posses is downright alarming. The following pop-up seems perfectly legit, doesn’t it?

But it’s actually a fake, created by a social engineering tool called BeEF that is free and open-source.

What Are the Different Types of XSS Attacks?

While there isn’t a standard classification of cross-site scripting attacks, it’s generally accepted that there are two main categories:

• Non-persistent XSS attacks (also referred to as reflected XSS attacks)
• Persistent XSS attacks (also referred to as stored XSS attacks)

There are a few other less common types that sometimes get their own classification depending on who you’re talking to. They are:

• DOM-based XSS attacks
• Self-XSS attacks
• Mutated XSS (mXSS) attacks

Now let’s take a look at each type of XSS attack.

Non-Persistent (Reflected) XSS Attacks

Non-persistent XSS attacks are the most common variety. They happen when a malicious script gets reflected from a website to the user’s browser. It requires a vulnerability that lets user input to be immediately returned without the data being sanitized. Then, the attacker builds a corrupt link with the script attached to it and distributes it to as many people as possible. For example:

www.bankofamerica.com/login/?user=[malicious code goes here]

When the link gets clicked, the browser will load the page that contains the vulnerability. Then, the embedded script gets executed and the XSS attack is triggered. The attacker receives the extracted data, which can be things like personal information or session cookies.

Persistent (Stored) XSS Attacks

Persistent XSS attacks are the most dangerous variety because the malicious code that’s injected ends up being saved by the server and then presented to other users when they navigate to that same page. The attack vector itself can vary greatly, and in some cases the hacker doesn’t even need to have direct interaction with the page in question. Anything that gets received by the web application, such as emails, chat messages, or system logs, can be used to perform the code injection.

Self-XSS Attacks

Self-XSS attacks are more of a social engineering attack because they trick the user into executing the script themselves, for example by copying and pasting malicious code into their browser’s address bar.

Fortunately, self-XSS attacks are becoming less and less common because browsers have begun taking steps to warn users in advance. If you try pasting JavaScript into the address bar of a current version of Firefox or Chrome, for example, you’ll receive a warning of the possible dangers you’re about to potentially expose yourself to.

This usually isn’t considered a “true” XSS attack because it relies on the user rather than on a vulnerability on a particular website (the user is essentially tricked into attacking themselves). However, self-XSS attacks still pose the same danger as other types if carried out properly.

Mutated XSS (mXSS) Attacks

Mutated XSS attacks take advantage of the nature in which browsers interpret HTML. An attacker injects something that appears safe in its initial form, but becomes malicious because it gets modified and rewritten as the browser parses the markup. Mutated XSS attacks tend to be the hardest variety to detect.

DOM-Based XSS Attacks

Document Object Models (DOMs) are a part of every website and describe the components and structure of a page. As pages are loaded and scripts are run, the browser keeps updating the DOM accordingly. The difference between DOM-based XSS attacks and other types is that the malicious code is loaded into the DOM as opposed to the website. Otherwise, it works similarly to a non-persistent XSS attack.

How to Prevent XSS Attacks

It all starts in the design phase, where you’ll want to build-in security measures and employ best practices while coding. Testing is critical, and code scanning tools can help find vulnerabilities. Manual testing for stored and reflected cross-site scripting should also occur and consists of submitting inputs into all of the application’s entry points. You should also identify every location where the input is returned in HTTP responses.

Unfortunately, there isn’t one bulletproof strategy for preventing XSS attacks thanks to the wide range of applications and their varying requirements. However, there are a number of general protective measures that you should use:

• Know the limitations of your framework’s XSS protection and how to handle the exceptions
• Avoid HTML inputs, and if you must use them then make sure to employ a robust sanitizer to detect unsafe code
• Also be sure you’re sanitizing data passed in URL variables, too
• Turn off HTTP TRACE support on all webservers to prevent session hijacking
• Use HTTPOnly flags for cookies, which prevents JavaScript from reading their content
• Filter inputs immediately at the point where the input is received, and be as strict as possible about it
• Encode output data to prevent it from being interpreted as active content
• Use a Content Security Policy (CSP), which uses HTTP headers to whitelist trusted sources – but remember that you must constantly update your CSP for any new sources or dependencies

A key principle to keep in mind—never trust any data you get from the browser/user. Always assume it could have malicious code in it (and take steps to ensure it doesn’t!)

In addition to these specific technical measures, there needs to be education and awareness, as well. Developers, designers, and quality assurance should all have an understanding of the different ways that attackers can exploit XSS vulnerabilities. By coupling this with proper coding guidelines and best practices that are specific to your application environment, you should be able to effectively minimize the considerable risks that XSS attacks pose to your website.

---

Protect Your Site With CodeGuard Backup