Systematic vulnerability of sites created on CMS 1C-Bitrix

To write about the systematic vulnerabilities of sites created on commercial CMS, pushed the post , which described the risks of hacking "protected" CMS.

This article focuses on the compromise of resources due to the "human factor", and the topic of exploiting the vulnerabilities of sites and web attacks was overlooked by the existence of "invulnerable" CMS. The assumption of the existence of "invulnerable" CMS may have a right to exist, as an example, the security of the finished online store out of the box on the CMS 1C-Bitrix is ​​very high, and it is unlikely to find more or less serious vulnerabilities in the "boxed version" code .

Another thing is the security of the final product created on such a CMS, and most importantly, the systematics of the manifestation of high-level vulnerabilities in these sites. Based on our site security practices (InSafety), as well as the statistics we collect for platform vulnerabilities (CMS), at least fifty percent of the sites created on the 1C-Beatrix platform with personal user accounts have the option of using stored Xss attacks.

Platform: CMS 1C-Bitrix 15.0 and higher
Security Risk : Stored XSS Attack
Systematics: at least 50% of sites with personal user accounts

The vulnerability of the code, which allows the exploitation of XSS attack, is inadequate filtering of the data of the fields of the registration information form of the user's personal account of the resource, which are transmitted to the database.
')
Example

The developer saves data, for example, the username from $ _REQUEST, via the Bitrix API, they are not completely filtered, and tags are saved. For example, we pass a string in the form field “name” of the site user’s PK:

test"><a href='#'><img src='http://insafety.org/img/xss2.jpg'/></a><p 

Data is transmitted via normal input to $ _POST ['name'] and then to $ USER-> Update, for example, like this:

 $USER->Update($USER->GetID(),array( 'NAME' => $_POST['name'], )); 

The HTML code will not be sanitized and will be stored in the username "as is". Screenshot admin site:


Result:



This example clearly demonstrates the presence of a security threat.

In the proposed demonstration of the existence of a threat, the introduction of HTML code was shown, rather than JS, which suggests a typical XSS attack. This is due to the fact that most sites developed on the CMS 1C-Bitrix, an attempt to implement JS-code will block the proactive protection filter.

The introduction of most of the syntax tags of HTML code, proactive protection CMS 1C-Bitrix is ​​not filtered. Such a demonstration of the detection of code vulnerabilities is absolutely safe and intuitive. In the case when the 1C-Bitrix proactive protection filter is disabled for some reason, the code vulnerability described above allows exploiting stored XSS attacks in a “classic” implementation.

The level of security threat to the site from the introduction of any (whether JS or HTML) unauthorized code, as well as its output without proper filtering, is extremely high.

For obvious reasons, this article does not offer options for real-life attack, both with the proactive filter turned on and off.

XSS attack protection

Protecting your site from the possibility of using XSS attacks is quite simple. To do this, filter the input and output data by escaping characters and converting special characters into HTML entities. In php this can be done using the functions htmlspecialchars (), htmlentities (), strip_tags ().

Example:

 $name = strip_tags($_POST['name']); $name = htmlentities($_POST['name'], ENT_QUOTES, "UTF-8"); $name = htmlspecialchars($_POST['name'], ENT_QUOTES); 

In addition, the encoding of the site pages should be explicitly indicated:

 Header("Content-Type: text/html; charset=utf-8"); 

There are many ways to protect against XSS attacks, for example, there are options for banning quotes and parentheses (filtering data by blacklist) at the web server configuration level.

Example for NGINX: (write to configuration file)

 location / { if ($args ~* '^.*(<|>|").*'){ return 403; } if ($args ~* '^.*(%3C|%3E|%22).*'){ return 403; } } 

For the Apache web server, this will be an entry in the .htaccess file:

 RewriteEngine on RewriteCond %{HTTP_USER_AGENT} (<|>|"|%3C|%3E|%22) [NC,OR] RewriteRule ^{} 

Filtering data on the blacklist is applicable not for all sites. To use this method of protection against attacks, you should be very careful because you can block legal requests.

Conclusion

The above security threat to a web application is the most popular and well-known attack. About XSS attacks and protection against them, written thousands of articles and publications.

In the practice of our company, vulnerability to XSS attacks on user personal accounts was discovered in the fall of 2015. In the spring of 2016, our statistics on vulnerable sites on the CMS 1C-Bitrix clearly indicated that the attack could be exploited by more than 50% of the studied sites. In April 2016, realizing that the code vulnerability in this section is systemic in nature, we passed all the information about the security risk to the Bitrix company. Employees of the Bitrix company took the information, informing in feedback that they had taken action, correcting the documentation for the system. Despite the measures taken, the above-described security risk for sites on 1C-Bitrix remains extremely relevant today.

I hope that this information will be useful for developers and owners of sites created on the 1C-Bitrix platform.

It should be understood that experiments with the security of other sites, not to mention the exploitation of an attack for criminal purposes, may entail criminal liability. All information on the threat to the security of sites, in this post, is provided in order to increase the overall level of IS of end products on the 1C-Bitrix platform.