|
Table of contents
• How cross-site scripting works
• XSS attack technique
• General classification of XSS
• Types of XSS by the method of interaction
• How to check a site for XSS vulnerabilities and protect it
XSS (cross–site scripting) is one of the types of attacks on web systems, which involves the introduction of malicious code on a specific page of the site and the interaction of this code with a remote server of attackers when the user opens the page. The term stands for Cross-Site Scripting, but at the same time it received the abbreviation XSS so that there would be no confusion with CSS (cascading style sheets).
How cross-site scripting works
The main purpose of cross–site scripting is to steal user cookies using a script embedded on the server with further sampling of the necessary data and using them for subsequent attacks and hacks. The attacker does not attack users directly, but uses vulnerabilities of the website visited by the victims and implements special JavaScript. In users' browsers, this code is displayed as a single part of the site. At the same time, the visited resource is in fact an accomplice of the XSS attack.
When compared with SQL injections, XSS is safe for the server, but poses a threat to users of the infected resource or page. However, if the attacker gets the administrator's cookies, you can gain access to the site's control panel and its contents.
XSS attack technique
Malicious JavaScript code can only be run in the victim's browser, so the site the user visits must have a vulnerability to XSS. To carry out an attack, an attacker initially checks resources for vulnerabilities via XSS, using automated scripts or manual search mode. These are usually standard forms that can send and receive requests (comments, search, feedback).
A complete collection of pages with input forms is carried out, and each one is scanned for vulnerabilities. For example, we have a "Search" page on the site. To check the XSS vulnerability, it is enough to enter a request:
<script>alert("cookie: "+document.cookie)</script>
If a notification appears on the screen, it means that you have discovered a security breach.
Otherwise, the system will display you a page with search results. The main popular CMS have long lost such problems, but due to the possibility of expanding functionality through modules and plugins created by third-party developers, the chances of using XSS vulnerabilities increase significantly, especially in Joomla, DLE, Bitrix, Wordpress. Most often, XSS vulnerabilities are checked in the Internet Explorer browser.
Another possible search option is to use pages that process GET requests. Let's say we have a link like this: https://site.ru/catalog?p=8 In the address bar, instead of the identifier (8),
add the script – "><script>alert("cookie: "+document.cookie)</script>, as a result of which we get a link of this type:
https://site.ru/catalog?p="><script>alert("cookie: "+document.cookie)</script>.
If the page has XSS vulnerabilities, a notification will appear on the screen with the same plan 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 is suitable, then the resource is reliably protected from such attacks.
General classification of XSS
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, which works in automatic mode. Forums, portals, blogs, where there is an opportunity to comment in HTML without restrictions, are mainly subject to such vulnerabilities. Malicious scripts can easily be embedded in text, as well as in pictures and drawings.
Reflected XSS (non-permanent). In this case, the malicious string acts as the victim's request to the infected website. This principle works according to the following scheme:
1. The attacker creates a URL link in advance that will contain malicious code and sends it to his victim.
2. Link sends this URL request to the site (clicks on the link).
3. The site automatically takes data from the malicious string and substitutes it as a modified URL response to the victim.
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 of this user.
DOM models. In this case, it is possible to use both stored XSS and reflected ones. The essence is as follows: The attacker creates a URL that contains malicious code in advance and sends it by email or any other way to the user. A person clicks on this link, the infected site accepts the request, excluding the malicious string. A script is executed on the user's page, as a result of which a malicious script is loaded and the attacker receives cookies.
Types of XSS by the method of interaction
Since the attacker's main goal is to run a malicious script on the victim's computer, there are also two main types of XSS attacks based on the method of interaction.
Passive. A certain action is required from the victim to call the event handler and run the malicious script in the set form. To do this, social engineering is used, for example, sending an email encouraging you to click on a link and click on a specific area on the site. As soon as the user hovers over the desired object and clicks on it, a malicious script will run. If the victim is inactive, the code will not be activated.
Active. The attacker does not need to lure the victim using special links, since the code is embedded in databases or in some executable file on the server. No activity is required from the user. As a rule, input forms have a special event handler installed, which is automatically activated when you get to this page. As a result, all users who clicked on this link will become victims of an attacker.
How to check a site for XSS vulnerabilities and protect it
To quickly check the site for XSS vulnerabilities, you can use specialized services that automatically scan the page. It is mandatory to check all URLs where it is possible to send data from the user (comment forms, feedback, search). As an example, you can use https://xss-scanner.com but do not limit yourself to just one tool. Such services do not provide a full guarantee of success, so we recommend checking the found pages manually and be sure to exclude all dangerous special characters, replacing them with safe ones. We are talking about brackets < and >, in which all html queries and tags reserved by the language are written.
For example, to quickly filter and automatically replace 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 user input is enabled on your site, encoding must be performed.
2. If coding is not possible or inappropriate in some situations, replace it or supplement it with validation. Secure data processing should be performed in the code not only on the side of your web server, but also on the side of the user (client).
3. If you use popular CMS such as Wordpress, Bitrix, Joomla, regularly update the versions of the engine and all installed modules and plugins. By default, most of the most common site management systems are protected from using XSS, but third-party plugins from unverified sources may contain vulnerabilities.
|
