What is cross site scripting (XSS) and how to fix it?

What is Cross-site scripting  (XSS) attack

what is cross-site scripting? XSS (cross-site scripting) is one of the varieties of attacks on web systems, which involves the introduction of malicious code on a specific page on a site and the interaction of this code with a remote attacker server when a user opens the page.

The term from English is deciphered as Cross-Site Scripting, but at the same time received the abbreviation XSS so that there is no confusion with CSS (cascading style sheets).

How cross-site scripting works

The main goal of cross-site scripting is to steal user cookies using a script built into the server with further fetching the necessary data and using it for subsequent attacks and hacks. An attacker does not directly attack users but exploits vulnerabilities in a website visited by victims and injects special JavaScript. In the browser, users of this code are displayed as a single part of the site. Moreover, the visited resource is in fact an accomplice of the XSS attack.

Compared with SQL injection, XSS is safe for the server, but it poses a threat to users of an infected resource or page. However, if the administrator gets access to the attacker, you can access the site control panel and its contents.

XSS attack technique

Running malicious JavaScript code is possible only in the victim’s browser, so the site that the user accesses must be vulnerable to XSS. To carry out an attack, an attacker initially checks resources for vulnerabilities through XSS using automated scripts or a manual search mode. Usually, these are standard forms that can send and receive requests (comments, search, feedback).

A complete collection of pages with input forms is carried out, and each is scanned for vulnerabilities. For example, we have a “Search” page on a site. To check the XSS vulnerability, just enter the query:

<script> alert ("cookie:" + document.cookie) </script>

If a notification appears on the screen, it means you have discovered a security breach. Otherwise, the system displays a page with the search results. The main popular CMSs have long lost such problems, but due to the possibility of expanding the functionality through modules and plug-ins created by third-party developers, the chances of using XSS vulnerabilities increase at times, especially in Joomla, DLE, Bitrix, Wordpress. Most often, XSS vulnerabilities are checked in Internet Explorer.

Another possible search option is to use pages that process GET requests. Suppose we have a link of the form: http://www.darkhackerworld.com/catalog?p=8

In the address bar, instead of identifier (8), add the script - "> <script> alert (" cookie: "+ document.cookie) </script> , as a result of which we get a link of this kind: http://www.darkhackerworld.com/catalog? p = "> <script> alert (" cookie: "+ document.cookie) </script> .

If the page has XSS vulnerabilities, a notification of the same plan will appear on the screen as in the first case.

To search for "holes" on the site there are a huge number of ready-made scripts and queries, and if none of them are suitable, then the resource is reliably protected from such attacks.

General XSS classification

There is no clear classification for cross-site scripting, but experts around the world have identified three main types.

Stored XSS (persistent). One of the most dangerous types of vulnerabilities, as it allows an attacker to gain access to the server and manage malicious code from it (delete, modify). Each time you access the site, a pre-loaded code is executed that works in automatic mode. Mostly, such vulnerabilities affect forums, portals, blogs, where there is the possibility of commenting in HTML without restrictions. Malicious scripts can easily be embedded both in text and in pictures and drawings.

Reflected XSS (fickle). In this case, the malicious line acts as the victim’s request to the infected website. This principle works as follows:

1. An attacker creates a URL link in advance that will contain malicious code and sends it to his victim.

2. She sends this URL request to the site (follow the link).

3. The site automatically takes data from the malicious line and substitutes the victim with a modified URL.

4. As a result, a malicious script is executed in the victim’s browser, which is contained in the response, and the attacker receives all the cookies from the user.

DOM models. In this embodiment, it is possible to use both stored XSS and reflected. The bottom line is this:

1. An attacker creates a URL that contains malicious code in advance and sends it by e-mail or in any other way to the user.

2. The person follows this link, the infected site accepts the request, excluding the malicious line.


3. A script is executed on the user's page, as a result of which a malicious script is downloaded and the attacker receives cookies.

Types of XSS by way of interaction

Since the main goal of the attacker is to run a malicious script on the victim’s computer, there are two main types of XSS attacks by the way of interaction.

Passive. A specific action is required from the victim in order to call the event handler and run the malicious script in the established form. For this, social engineering is used, for example, sending an e-mail with an appeal to follow the link and click on a specific area on the site. As soon as the user points to the desired object and clicks on it, a malicious script will be launched. If the victim is inactive, the code will not be activated.

Active. An attacker does not need to lure the victim through special links, as the code is embedded in databases or in some executable file on the server. No activity is required by the user. In input forms, as a rule, a special event handler is installed, which is automatically activated when it gets to this page. As a result, all users who click on this link will become victims of an attacker.

How to check a site for cross-site scripting vulnerabilities and fix it

To quickly check the site for XSS vulnerabilities, you can use specialized services that will automatically scan the page. It is imperative to check all URLs where it is possible to send data from the user (comment forms, feedback, search). You can use http://xss-scanner.com as an example, but you should not limit yourself to just one tool.

Such services do not give a full guarantee of success, therefore, we recommend that you check the pages found in manual mode and be sure to exclude all dangerous special characters, replacing them with safe ones. We are talking about brackets <and>, in which all Html-requests and tags reserved by the language are registered.

For example, for quick filtering and automatic replacement of special characters <and> you can use the following code on the site:

$ filter = array ("<", ">");

$ _GET ['q'] = str_replace ($ filter, "|", $ _GET ['q']).

Some tips to prevent the use of XSS on your site:

1. If the user input is enabled on your site, the encoding must be performed.

2. If coding is not possible or inappropriate in some situations, replace it or supplement it with validation.

3. Safe data processing should be performed in the code not only on the side of your web server but also on the user (client) side.

4. If you use popular CMS, for example, Wordpress, Bitrix, Joomla, regularly update the version of the engine and all installed modules and plugins. By default, most of the most common systems for managing sites are protected from using XSS, but third-party plugins from unverified sources may contain vulnerabilities.