XSS attacks are particularly sneaky. And especially popular with hackers. We show how you can protect yourself against the hijacking of your site - as a website operator and as a user.

1599 WordPress -Plugins were analyzed by the security provider Wordfence over a period of 14 months, and the most frequent vulnerabilities of all were so-called XSS vulnerabilities. Almost 47 percent of the gaps found had to do with cross-site scripting - XSS for short. Reason enough to take a closer look at this type of attack, in which hackers inject malicious code into your site and virtually hijack it. In this way, the attackers use your blog, your shop or your company website as a vehicle for their illegal activities.

XSS vulnerabilities are always dangerous when user input is forwarded to the web server without being checked, for example in contact forms or comment fields. Once exploited, the hackers can steal data, integrate your site into a botnet or infect your visitors' computers. Fortunately, there are some very simple protective measures against XSS attacks.

XSS is relevant for visitors and site operators alike

It is important to understand that XSS vulnerabilities on WordPress sites are equally relevant to site operators and visitors. Site operators are exploited to fulfill the hackers' baser goals and site visitors are often the aggrieved parties, for example through data theft or malicious code distribution.

In principle, XSS attacks start where users send data to the web server of the site operator. Code is injected at these neuralgic points, which - if the user input is not checked critically, e.g. by a firewall - can infect the site . The different types of XSS attacks are summarized in our background article on the topic.

Most important: Regular WordPress updates

The vulnerabilities that hackers use to inject malicious code are located either in the WordPress core, in Plugins or in Themes. This is exactly why regular updates of all these components are so important. The vulnerabilities that have been found to date are fixed in these updates.

It also makes sense to regularly read the update details of the respective manufacturers to get a feeling for which security gaps are regularly closed via the updates. For the maintenance and security updates of the WordPress core, this information is documented in the WordPress blog, for example. The best example of this is the latest security update, WordPress 4.7.5.

Firewalls and whitelists against simple XSS attacks

Another simple protective measure against XSS attacks are so-called web application firewalls, or WAF. These firewalls are the heart of large securityPlugins and are fed with the latest vulnerabilities by the respective research team of the manufacturer. A WAF is generally a procedure that protectsweb applications from attacks via the Hypertext Transfer Protocol (HTTP).

However, even these protection mechanisms have their limits. For some XSS attacks, the attack takes place via the database. Therefore, checking user input for malicious code is one of the central security mechanisms in the fight against XSS attacks. For example, the content of comments is scanned for suspicious character strings and sorted out if necessary.

The data output should also be secured

Regelmäßige Updates schließen vorhandene XSS-Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Seite infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass “problematische” HTML-Metazeichen (z. B. <, > und &) durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sog. sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in deinen Seitenquellcode eingebunden. Der folgende Code-Schnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

Programming skills are required to implement this. This data output protection can be easily implemented by a developer or CTO, for example.

A healthy dose of scepticism: How users protect themselves

But not only page operators, also page visitors are affected by XSS attacks. Many XSS attacks can already be prevented by a critical and careful handling in connection with "foreign" links. For example, users have the option of using NoScript add-ons .These prevent the execution of scripts, i.e. the harmful lines of code that steal data, for example.

If you want to be on the safe side, you can also avert client-side cross-site scripting simply by switching off JavaScript support in the browser. Because if this so-called active scripting is deactivated, certain types of XSS attacks no longer stand a chance, as the malicious applications are not even started. However, most modern websites then no longer "work" properly - or in the worst case, no longer work at all. Here it is therefore necessary to weigh up the security and usability aspects.

Conclusion: XSS attacks are sometimes very complex, but protection is sometimes quite simple.

XSS is a danger for you as a website operator as well as for your visitors and customers. Again and again vulnerabilities in Plugins or Themes become known. For example, the Plugin WP Statistics, with more than 400,000 active installations, or WooCommerce and Jetpack, each with more than three million active installations.

If you keep your Plugins and Themes up to date and use a WAF, you have already taken a big step in the right direction. If you also use whitelists for incoming and outgoing code, you have already secured your site excellently. However, the last two measures in particular are not easy to implement without programming knowledge.

Compared to the quite primitive Brute Force attacks the more complex XSS attacks are unfortunately still relatively often successful. However, there are significantly fewer of these so-called complex attacks than there are Brute Force attacks on WordPress sites .. Nevertheless, you should make it as difficult as possible for attackers. A successful hack not only costs time and money for the removal of the scripts, but can also endanger your position in search engines.

Maybe you've already had experiences with XSS attacks? What do you do to protect yourself from them?