After our article summarizing and describing the TOP 10 OWASP attacks, we will focus on each of them and explain what has been set up within our very high security Cloud CerberHost to overcome them. One of the greatest plagues on the web is Cross Site Scripting attacks, often called XSS.

The different kinds of Cross Site Scripting (XSS)

XSS - Cross Site ScriptingCross Site Scripting (XSS) is one of the principal scourges on the web, in terms of both volume and consequences. These attacks are very widespread and an IP is often “scanned” many times a day, in search of vulnerabilities of this kind.

There are many types of XSS, the most common of which are:

  1. Stored
  2. Reflected

… which are detailed below.

The underlying concepts of XSS attacks

There are many ways to exploit “XSS” vulnerabilities.

The underlying principle stays the same for the different kinds: to make a browser execute Javascript/HTML language (or sometimes other languages) to get it to adopt a behavior that will be useful for the pirate. “Cross Site Scripting” literally consists in putting code into the targeted website.

Most XSS attacks manage to see the light of day based on the same vulnerability: users’ entry control. For instance, in a website’s form, if the programmer (or his/her framework, like Sympfony or Zend do) took care to control the data sent by the user, the XSS cannot take place. However, most of the time, these entries are not properly controlled, or even not at all.

In the end, if a pirate sends JavaScript in a field that is only supposed to accept a surname, this JavaScript might, under some conditions, be exploited by a pirate. The programmer should have checked that only letters that can compose a surname could be accepted by his form, and not specific characters of JavaScript like < > ‘ % “ etc.

If the programmer did not do it, a WAF (Web Application Firewall) can deal with it if it is properly configured.

Reflected XSS

A very simple explanation for the reflected XSS is the example of a website with a search engine and which, when “ABC” is typed into the search bar, will display a message “Results for your search ABC”. Then, if the filter or encoding of dangerous characters is not set up, a pirate will be able to type in the search bar and search “A<script>alert(1)</script>”. Here, the effect of the Javascript charge is harmless, but this language can be used for instance to steal a user’s cookie (authentication token of the website). The attacker (as part of a reflected XSS) must then manage to convince his victim to follow a tailor-made link. In an e-Commerce context, this step is often trivial.

Stored XSS

The stored XSS is in all ways similar to reflected XSS. However, a stored XSS is persistant, which makes it even more dangerous. A typical case might be the one of a forum or any other community website, in which the pirate would find a way to inject HTML/JavaScript language into his message. He will then be able to execute HTML/JavaScript in the browser of any victim that will visit the subject(s) he posted.

L’utilité du WAF dans le cas des XSS

A WAF (Web Application Firewall) like NAXSI is a tool capable of cleaning the traffic and banning dangerous GET or POST requests. This cleaning is essential to protect a website whose source code can be vulnerable.

Its job mainly consists in studying if dangerous characters are used in convergence with some words. For instance, if one finds “Robert<script>alert(document.cookie)</script>” in a name field of a form, it is abnormal.

Traditional WAFs (not including NAXSI) generally use a signature system and thus are likely to be deceived if an attack’s signature is new or modified, but if they detect a signature that has the trace of a malicious action, they block it even if it is known.

CerberHost’s answers to Cross Site Scripting attacks

cerberhostCerberHost naturally has a set of advanced rules allowing to filtrate most XSS attacks.

Before every production launch, websites are subject to an intrusive applicative audit, which also allows to reveal its potential vulnerabilities and to generate a set of even stricter rules in order to protect it at best.

CerberHost also enables, thanks to NAXSI, to do what we call Virtual Patching. . This method consists in correcting, upstream, bugs or applicative flaws on reverse proxies or on the WAF, without correcting the code itself. All there is to do is to set up rules systematically protecting the access to this vulnerability.

NAXSI being very light, it can filtrate all requests, GET or POST; an action that WAFs relying on signatures and not rules cannot always do.

The typical example is the XML-RPC flaw that Magento experienced a few months ago. By applying an upstream protection rule on all of our machine park, we were able to give our clients and web agencies time to correct the bug, without being at risk in the meantime.

Découvrir CerberHost

video de présentation de CerberHost

CerberHost protects your website against all Top 10 OWASP attacks, and much more.

To discover CerberHost in pictures, watch its presentation video HERE

 

Lucie Saunois
Lucie Saunois
IT aficionado, specifically when it comes to cybersecurity, since she joined OT Group in 2015, Lucie specializes in making technical, and often complex, topics understandable by anyone.