• Experts Explain: Cross Site Scripting

    This is the second part in a series of posts here at StopTheHacker where we describe the various methods that malicious hackers use to infect benign and legitimate websites with web-malware.

    This time, we will discuss one of the most prolific techniques used to compromise millions of websites: Cross Site Scripting. Cross Site Scripting attacks have been seen for many years now and remains a continuing threat. In fact, by the latest statistics, more than 75% of websites have at least one Cross Site Scripting vulnerability.

    It is no wonder that thousands of sites are compromised every single day, only to infect their unsuspecting visitors and end up on blacklists. In this article, we will delve into detail on Cross Site Scripting, how to identify vulnerabilities, how to stop them from being exploited, and more.

    What is Cross Site Scripting?
    Cross Site Scripting is a an attack wherein a hacker exploits vulnerabilities in the software powering a website to launch an attack on the user. The attack can range from the display of a fake Anti-Virus advertisement to an unsuspecting user, all the way to a sophisticated port scan run using an injected toolkit.

    Cross Site Scripting is primarily used to forward users to a URL that looks genuine, and is in fact pointing to a legitimate business website. However, when the user visits the URL in a browser, the content displayed is from a malicious source that can compromise and infect the visitor.

    An important point to understand: Cross Site Scripting is not the same as Phishing. Phishing is the attempt to deceive someone that a web page actually belongs to a bank (or a similarly important institution), when it does not, in order to steal credentials.

    Cross Site Scripting attacks direct users to a legitimate website with malicious content loaded from malicious sources. Cross Site Scripting attacks help hackers set up phishing campaigns and can be used as a tool to enable these malicious activities.

    What is XSS?
    XSS is an abbreviation for Cross Site Scripting. Some people also refer to Cross Site Scripting as CSS, though this conflicts with the more popular abbreviation of CSS, Cascading Style Sheets, a widely used term in web technology. XSS is less ambiguous abbreviation for Cross Site Scripting.

    What is a code injection attack?
    A code injection attack is an unwarranted effort to load malicious computer code onto a website, by exploiting weaknesses in the software that is powering the website or by other means, such as compromised passwords (FTP etc).

    This attack usually manifests itself when a malicious hacker identifies a particular weakness in the way a website handles user input and exploits that weakness to load the malicious computer code, infecting the web pages on the website. This allows the malicious hacker to (1) steal information from the compromised website (2) infect visitors visiting the compromised website and more.

    What kind of vulnerabilities allow XSS attacks to happen?
    XSS attacks occur primarily due to improper sanitization of user input. Consider the case where a hypothetical website has a form on a webpage that accepts a user’s email address to send a newsletter to them.

    The web application that process the email address might not have been well constructed. Due to defects in the computer code that accepts the input from the user and processes it, a hacker may be able to run their own malicious computer code. It is very important to ensure that user input is not trusted implicitly. Validation must be performed on all user input to verify that the data is benign.

    What are the major types of XSS attacks?
    There are two primary types of XSS attacks: Persistent XSS and Reflected XSS. Persistent XSS attacks lead to the injection of malware onto the webpages of a weakly secured website where it is stored. Reflected XSS attacks are often used to make the weakly protected website act as a vehicle for malicious actions, while there is no real malware stored on the webpages (hence the name reflected).

    Persistent XSS Attack Example
    A malicious hacker realizes that an input form, such as a password field is not properly sanitizing its input, tries to exploit it, succeeds and then is able to permanently store malware on the website by infecting its webpages.

    Consider that the input form might be expecting the user to provide an email address for a newsletter subscription, but the hacker puts in a email address and then also attaches computer commands to the email address. Weakly secured code in the web application analyzes this input, stores the email address, and then runs the other commands that the hacker included. This can allow the hacker to load malware onto the webpages.

    Reflected XSS Attack Example
    A malicious hacker identifies the various fields accepted as user input and attaches malicious commands as the values to be submitted for some or all of the fields in order to cause the web server to display (reflect) the malware back to the unsuspecting user who clicked the malware laced link.

    In this scenario, the malware is self-contained inside a HTTP link. This attack succeeds since most users are used to clicking on link URLs without checking the actual contents of the URL. Malicious hackers are banking on this. These malicious links can be distributed via email, and once a user clicks on the link, the web server of the legitimate, but insecure website, is used to display the malware contained in the link to the user via the browser that the user is using to view the malicious link.

    Another XSS Attack Example
    Consider a website that has URLs of the following type:


    Let us say the parameter “name” is used to define name values for the user. The website uses this value to say “Hello Alex” on the webpage. In this example, a malicious hacker can exploit the parameter “name” by attaching malware information to the parameter “name” instead of the expected name as below:

    http://www.yoursite.com/index.html?name=<script>alert('XSS vulnerability')</script>

    This shows a message box to the user displaying the words ‘XSS vulnerability’, but in reality, actual malware code could have been loaded via this exploit on a website employing the same technique.

    This attack succeeds because the web application that analyzes this URL and powers the website, incorrectly trusts the user to always input safe data. It is not be prepared for threats like this. In this case, a malicious hacker has used a benign website to launch a malware attack on an unsuspecting customer, and the website owner usually has no idea that his or her website was exploited.

    How to detect if your site is vulnerable to XSS attacks?
    There are many ways to check if your website is vulnerable to XSS attacks:

    1. Find out if any of the software powering your website takes user input directly and uses it directly, without sanitizing it. For example: can a user attach a semicolon, colon, or bracket symbol in the text they are providing to the website as input, and have these special characters displayed back to them un-escaped?
    2. Find out if the software that powers your website is out of date. If it is, apply all recommended patches or upgrade to the latest version of the software.
    3. Find out if the third party plugins that your website employs, are at risk to XSS attack vulnerabilities.
    4. Conduct a vulnerability assessment scan of your website to find out if there are any XSS vulnerabilities that are identified. Any vulnerabilities should be fixed as soon as possible.
    5. Use a Web Application Firewall (WAF) and a Firewall to prevent malicious access to the website.

    XSS is a popular vector for malicious hackers to exploit and infect websites. We have seen what XSS is, how it is used by hackers, and how to protect your website.

    StopTheHacker.com customers have access to resources and services that protect them against these kind of threats and help them recover from compromises should they occur. If you want to protect your website right now visit our services page.

    This article is has been translated by a StopTheHacker fan and is also available in Serbian.