What are Cross-Site Scripting (XSS) Attacks?

Hackers have several different methods at their disposal to gain entry to secure devices. Keylogging, password cracking, and phishing are just a few of them. However, there is one insidious method to gain entry to devices and alter data: cross-site scripting (XSS). 

If executed properly, XSS can allow hackers to alter your data, steal your data, plant viruses on your server, and more. In this article, we are going to walk through what XSS is, the different types, and various prevention strategies. 

Level Up Your Security Skills Today

Level up your security skills by getting GCIH-certified. Start preparing for the exam with the help of CBT Nuggets trainer Erik Choron’s Hacker Tools, Technique, and Incident Handling course. His training covers a lot of domains and topics that you’ll encounter on the GIAC Certified Incident Handler certification exam. It also contains practical, real-world examples to help you learn the latest security best practices. Not a CBT Nuggets subscriber? Sign up for a 7-day free trial to get a feel of what it’s like to learn IT with us. Explore all of our cybersecurity training and start learning skills that can help you keep networks and data safe!

What is Cross-Site Scripting?

Cross-site scripting is a type of attack that allows hackers to interfere with the way users interact with a website. This is done by injecting JavaScript code into a browser. This code will then execute and attempt to trick users or steal their data. In general, XSS is done with JavaScript. Generally, there are three different types of XSS attacks. They are:

• Stored XSS

• Reflected XSS

• DOM-based XSS

DOM stands for Domain Object Model and refers to the actual markup language used to render a website.

What is Stored XSS?

Stored XSS refers to malicious code being stored on the server in a database. That code then is retrieved and executed on the browser. This is a fairly common form of XSS. 

Let’s say you are running a social media site for running enthusiasts. A visitor posts their run times, favorite trails, and their top running shoes in an input box. Then the poster clicks “submit”. Here is an example: I ran 5 miles in my new Nike running shoes. I went to the state park to run. I ran the whole thing in 60 minutes. It was great!

Once the user clicks submit, anyone browsing the internet can see this post. Let’s say the next person who submits is a programmer and they use HTML markup to make their writing a little more legible. The programmer writes:

I ran <strong>2 whole miles</strong> today! I have a great routine. Every day I: 
<ul>
<li>Wake up at 6:00 AM</li>
<li>Stretch for 20 minutes</li>
<li>Run for 20 minutes</li>
</ul>

When he clicks submit, the output will look like this:

I ran 2 whole miles today! I have a great routing. Every day I:

• Wake up at 6:00 AM

• Stretch for 20 minutes

• Run for 20 minutes.

Notice the formatting. They added HTML to their entry and now it is executing on everyone’s browser when they navigate to the post. That’s a problem. 

What Can A Hacker Do With This?

If a hacker with nefarious intent saw this, they could easily add more elaborate JavaScript to an entry. So instead of just formatting the test of a jogging post, she could retrieve sensitive data from users or lure them to a website since this code is executed on everyone’s browser. The code could look something like this:

 <script>
      const button = document.createElement('button')
     button.innerText = ‘New Running Shoes on Sale!’
      button.id = ‘button hack'
     button.addEventListener('click', () => {
        // forward user to malicious website
window.open(www.hackerurl.com)
        // display their personal information.
alert(document.cookie)
      })
      document.body.appendChild(button)
    </script>

Because JavaScript doesn’t show up in the post, none of this will be visible to the public. Yet, the code will execute. This means everyone will see a popup button that says “New Running Shoes on Sale!” When they click on it, it will navigate to the hacker’s website where they can steal data. This also executes a popup of their cookie, which I just put in as an example to show they can steal personal data too.

As you can see, the possibilities are virtually endless for a bad actor using stored XSS.

What is Reflective XSS?

Reflective XSS is very similar to Stored XSS, except nothing gets stored in a database. Instead, the hacker injects JavaScript directly onto the DOM. Let’s take a look at another quick example.

Let’s say you were the owner of a video game site. The site is www.test.com. A user can put in their email, click “Search” and retrieve all of the trophies they have earned on the video game. 

Let’s say someone searches for the profile “user@user.com". If the email is not found, it says “Sorry! The profile for user@user.com is not found”. When the server redirects you to this page, the URL changes www.test.com?profile=user@user.com.

Notice that the email address you added is reflected in the DOM. Now, the hacker can type <script>alert(“show alert”)</script> instead of an email. As in the previous example, the browser will execute this. The URL will look like this: 

www.test.com?profile=<script>alert(“show alert”)</script>

Instead of just putting an alert, they could add JavaScript that will steal personal information and send it to a different server.

What is DOM XSS?

DOM XSS is a lesser-known version of XSS. Notice that the previous two forms of XSS involve the server in some way. DOM XSS is done purely within the website itself. Oftentimes, different elements of a website are generated via a JavaScript function. 

For example, a user clicks a button to hide one image and bring up another one. This image is reflected in the URL to signify which image the user is looking at. A hacker can take advantage of this by changing the URL to execute JavaScript code instead of the intended sequence of code. This can be done by adding onError(<some javascript code>) to the URL query params. 

Now that we have gone through the three types of XSS attacks, let’s go over how to prevent them. 

How Do You Prevent Cross-Site Scripting?

The key thing to remember about XSS is that it always involves a form — or some method of accessing the DOM. As we have seen from the previous example, this can also be done through query parameters in the URL as well. 

The best way to prevent XSS is to filter what users can and cannot submit in a form. For example, if a form is only supposed to have letters, then filer out any HTML characters such as <, >, :, !, etc. There shouldn’t be any characters getting to the server without your knowledge. 

The best way to do this is to create a whitelist of characters the server is allowed to consume. Apply these filters on both the server and the browser to ensure nothing is circumvented.

Make sure the data the server accesses is encoded. This will make it difficult for a hacker to know what string of characters would actually execute the script they are trying to implement. 

Finally, ensure that all HTTP requests to the server must have a content header. Verify that you are setting the content-type header so that the browser interprets the data the way it was intended to be (instead of as executable JavaScript code).

Final Thoughts

There you have it, folks, we covered three different types of XSS and the best way to prevent them. In summary, there are three different types of XSS: stored XSS, reflective XSS, and DOM XSS.

The best way to prevent cross-site scripting attacks is to:

• Filter all inputs before going to the server.

• Use the correct response headers.

• Encode the data.

• Verify all data cleaning is occurring on the server and on the browser

By following these rules, you will save yourself a lot of headaches. A pound of cure is worth an ounce of prevention, after all.