Cross Site Scripting y- How Hackers Capture Your Site

Tobias Schüring Last updated 15.01.2020
6 Min.
Cross-Site Scripting_XSS

XSS, SQL injection, XMLrpc - when a WordPress security update is released, the update reports contain mostly cryptic acronyms. Even if it is clear that these updates are necessary and the plus in security is very pleasing, it is important to understand what is behind these security vulnerabilities. Because only if you understand what gaps the updates close, you can also make an informed decision. That's why today we're turning our attention to cross-site scripting, or XSS, which is by far the most common complex attack on WordPress sites .

Hacker attacks can be compared to burglars. Brute Force Attacks are more similar to the crowbar method. The criminal resists the tool until the door or window breaks open. Attacks on XSS vulnerabilities, on the other hand, are sophisticated: The burglar knows exactly where to start and gains targeted access to site .

In the course of cross-site scripting, security holes in websites are thus exploited in a targeted manner. Hackers smuggle harmful scripts into a trustworthy context (your sites !). Similar to a stowaway on a ship, this malicious code uses your site as a vehicle to pursue its own goals.

In the worst case, attackers thus gain confidential information or access to the computer of the victimized user. Such attacks are not exactly rare: A good half of the vulnerabilities found by the security provider Wordfence in 2015 and 2016 were cross-site scripting vulnerabilities in Plugins .. Often, an XSS attack then forms the "basis" for further attacks, such as spam, phishing or DDoS attacks. That's why I'll show you today how exactly cross-site scripting works, what types of attacks there are and how dangerous the attacks are.

Cross-site scripting always works in a similar way: malicious code gets onto your site

Cross-site scripting is a danger whenever a web application forwards entered user data to the web browser without checking for any script code. A good example of such a web application is a support chat.

Via the web application itself the malicious scripts can reach the server. From there, the malicious code sooner or later ends up on the affected clients. A good example of such an XSS vulnerability is the bug discovered in July 2016 in the image meta-infos in WooCommerce 2.6.2. A bug made it possible for attackers to inject HTML code into the meta descriptions of images from the outside. Every customer who would have taken a closer look at the image in question (e.g. by clicking on the image) would run the risk of being attacked. For example, a hacker could have infected your customers' computers with a virus.

Popular trick for cross-site scripting: manipulated forms

XSS can also allow hackers to replace harmless forms with manipulated ones. These forms then collect the victims' (your site visitors'!) data. DBy the way, even SSL encryption cannot protect you from this. HTTPS "only" means that the connection between server and client is encrypted. However, if the form itself has been manipulated, even an encrypted connection is useless.

As with other types of attacks, the goal of hackers is most often to monetize their machinations. In concrete terms, this means that attackers either want to steal data that they later sell or infect sites in order to integrate it into a so-called botnet that is then rented out.

3 types of XSS: reflected, persistent and local XSS

Cross-site scripting attacks can be roughly divided into three types:

Roughly speaking, XSS attacks work as follows: Malicious code is injected where user input is expected (e.g. in a page-internal search). As part of the server's response, the malicious code is then executed on the client, i.e. in the user's browser. And this is exactly where the damage is done, e.g. user data is stolen.

Reflective cross-site scripting

Some inputs, such as search queries, are reflected by the server. This means that, for example, after entering "test" in the search field, the site outputs "You searched for test". So what the user enters becomes part of the server's response.

This is exactly what the attackers cleverly exploit: If a malicious script is sent to the web server instead of a search term, the site can be manipulated to ultimately execute it. This type of attack is also known as non-persistent referred to as non-persistent. This means that the malicious code is only temporarily injected at the respective site , but not stored.

In July, such a vulnerability was found in Plugin WP Statistics (and fixed on the same day!). An input value on the site 'wps_visitors_page' was forwarded unchecked, which led to a vulnerability through reflected XSS. Thus, a site could be hacked if an admin had previously clicked on an appropriately manipulated link.

For example, a reflected cross-site scripting attack might look like this.
For example, a reflected cross-site scripting attack might look like this.

It works like thisThe attacker distributes links with manipulated parameters to his potential victims. Without knowing it, the user sends a "manipulated" request to the server by clicking on the link, and the malicious code is executed together with the server's response. Since the code - unlike persistent XSS - is not stored anywhere, the hacker must distribute it en masse to potential victims. This can happen via mails or social networks, for example.

persistent cross-site scripting

With persistent XSS, the malicious scripts are stored on the web server and delivered each time they are called by a client. Predestined for this are web applications that store user data on the server and then output it without verification or coding (e.g. forums). This type of scripting can be particularly dangerous for highly frequented blogs and forums, as the malware can spread quickly here due to the large number of users.

This graphic shows a possible sequence of a persistent cross-site scripting attack.
Flow of a persistent cross-site scripting attack. Source: Blog SAP

Example: In a forum, posted contributions are stored in a database. It is not uncommon for these to be stored unchecked and unencrypted. Attackers take advantage of this opportunity and add a malicious script (e.g. with the help of a comment) to a normal forum post. a normal forum post with a malicious script (e.g. with the help of a comment). Users either receive the relevant link to the post by email or arrive at the corresponding entry by chance and execute the script when they call up the post. The advantage for the hacker is that he can now "spy" on affected clients or add them to his botnet for further attacks.

DOM-based or local cross-site scripting

Unlike persistent and reflected XSS, DOM (Document Object Model) based cross-site scripting works by executing client-side scripts. This means that the server is not aware of such an attack and server-side security measures do not help either.

A well-known example of such a vulnerability is the case of the genericon package. The genericon package is an icon set that is used by many Plugins, including Jetpack. It was possible to inject malicious code via an HTML file in this icon set.

After entering this URL, a javascript alert appeared. This is proof that the javascript code entered could be used to manipulate the respective site  .
After entering this URL, a JavaScript alert appeared. This is evidence that JavaScript code entered could be used to manipulate the particular site . Source: securityaffairs.co

However, a prerequisite for a DOM-based XSS attack is that the user clicks on a manipulated URL. By calling this URL, the malicious code can be executed through a gap in a client-side script. Among other things, the fact that a link must first be clicked makes DOM-based XSS a somewhat more difficult and thus less likely type of attack.

The graphic shows a possible sequence of a local cross-site scripting attack.
Example of a local cross-site scripting attack. Source: heise.de

Example: The user clicks on the manipulated URL and sends a request to the web application. The web application responds by passing the script code (which is incorrect but not manipulated) to the browser to start the execution of the script. The manipulated parameters from the URL are now interpreted and executed in the user's browser as part of the script. The web page displayed in the browser is thus changed and the user now sees - without noticing it - the manipulated site .

Conclusion: Quite frequent and not without danger, therefore appropriate protection is important.

XSS vulnerabilities are among the most common gateways for malicious code. And a corresponding attack often forms the basis for further attacks, such as spam, phishing or DDoS attacks. Attackers hijack your site and abuse it to achieve their own goals.

Reflected and persistent XSS are particularly common, as local cross-site scripting is more elaborate and difficult to implement. sites , which forward user data to the web browser without checking for malicious code are particularly vulnerable. Finding such gaps, however, is not that easy. In principle, this is precisely the task of security providers such as sucuri and others, who are constantly developing their security measures.

But of course there is also a way for normal WordPress users to protect themselves from these attacks. Updates of all WordPress components, for example, are a simple but very effective measure. How you as a site operator, but also as an Internet user, can prevent cross-site scripting, we explain in our next article on the subject.

You still have comments or questions? Then just leave a comment!

As a system administrator, Tobias watches over our infrastructure and finds every possible way to optimize the performance of our servers. His tireless efforts mean he can often be found on Slack in the early hours.

Related articles

Comments on this article

Post a comment

Your email address will not be published. Required fields are marked with *.