How to protect yourself from XSS attacks with UBIKA Cloud Protector?

What is Cross-Site Scripting (XSS) flaw?

The XSS vulnerability or Cross-site Scripting is a vulnerability, which affects a web application’s front-end.
This vulnerability has been named for the first time in January 2000 by Microsoft and it is one of the most common web application vulnerabilities (Cross-site scripting).
According to the OWASP website, it is present on two-thirds of the web (A7:2017-Cross-Site Scripting (XSS) | OWASP).
It’s pretty simple to understand how it works. A hacker injects some JavaScript code on a web application’s page and when this page is visited, the code gets executed in the user’s browser.

Despite its simplicity, it can be classified into three different forms.

What are the types of cross site scripting?

Stored vulnerability:

An explicit name because malicious content is saved in a database and it appears every time the web application’s page is visited.

Non persistent vulnerability

It uses the HTTP parameters (POST & GET). The server sends it to the user’s browser only once.

Document Object Model (DOM-based) attack:

Unlike the other two described above, the code is not sent to a server, but executed directly by the user’s browser.

With stored cross-site scripting attacks, the server keeps the script in the database and only returns it when a user’s browser visits the page, this type of attack is performed in two stages.
As a result, it is impossible for the victim to anticipate an attack before getting the page, making the stored XSS vulnerability probably the most dangerous of the XSS family.

The reflected and DOM-based XSS attacks must be placed in the parameters of a request, specifically in the URL.
This means that both of these XSS attacks can be present in links and are used by hackers in emails, using a little social engineering, it is possible to get their victim to click on a URL and the malicious script will be executed.

What are some examples of the impact of Cross-Site Scripting (XSS) attacks?

An XSS attack can have many negative consequences for the business.

  • Session hijacking: a hacker can redirect the victim’s browser with these cookies to their own server, and then steal their identity on the vulnerable website. If the victim is an administrator, the hacker will be able to commit all sorts of mischief: data theft, visual/textual changes to the site, changing the roles of other users, etc.
  • Downloading malware: the hacker can force the victim’s browser to download a malicious file (virus, Trojan horse, etc.).
  • Defacing: the hacker can also modify the content of a vulnerable website and add whatever he or she wants.
  • (Defacement – Wikipedia ( This technique can be used to add illegal content, propaganda messages or make the site completely unusable.

What are some examples of the impact of Cross-Site Scripting (XSS) attacks?

1. Basic use of a chat room

Let us use the practical case of an XSS attack with a stored XSS because it’s the easiest to understand but has huge implications for a web application and its users. Let us take a basic chat on a web application without particular protection. The page has a box where the message will be appended. There is a form where you can write some text.

We have two users: Loris the hacker and Paul the victim.
Loris’ goal is to redirect Paul’s browser to his web server to steal his cookies.
Let’s start: Paul starts the conversation and Loris replies with a simple “Hello”.

When Paul’s chat is updated, the server will send the message back, which will be inserted into the HTML code of the page.

When he clicks the “Post” button, the message will be sent to the server.
The server will then store it as is in the database.

Loris’ message will then be displayed normally on his browser, as intended by the site.

2. How to detect Cross-Site Scripting vulnerabilities

For his next message, Loris will surround “How are you?” with an HTML tag with a “style” attribute that is supposed to display the text in red.

In the same way as for the first message, the server will store the message and then send it back to Paul.

The “” tag will be considered HTML code and placed in the DOM like the other tags.

The message will be displayed in bold and red on the user’s browser.
This example was used by Loris to test whether the application was vulnerable to XSS.
He can now perform an XSS injection with malicious content.
This case represents a simple example of an XSS attack but the attacker is free to imagine the technique of his choice to achieve his goal (encoding, code obfuscation, …).

3. What could be an example of an XSS attack?

Loris now knows that the chat is vulnerable to stored XSS and will then decide to steal Paul’s cookies in order to log into his account.
The Javascript has 2 elements that will allow him to achieve his goal:

  • location allowing to redirect the browser running this code to the desired web page.
  • cookie containing all the user’s cookies on the current site.

With the above code, Loris will be able to redirect Paul’s browser to his own server while sending the latter’s cookies.

He then only needs to retrieve them to gain access to Paul’s account on the chat.
This case represents a simple example of XSS injection but the attacker is free to imagine the technique of his choice to achieve his goal (encoding, code obfuscation, etc.).

Owasp best practice example

The Open Web Application Security Project (OWASP) provides a list of rules to apply to protect your web applications:

  • Escape HTML, CSS and Javascript characters is probably the most sensible rule to apply, indeed, not checking user input in its code will lead them to contain content To implement this rule, you can use functions available in the various programming languages or use libraries designed to clean up user input.
  • It should be noted that most modern frameworks such as Angular, React or Vue implement these features natively.

  • Content Security Policy is a computer security standard used to prevent XSS attacks and code injections.
  • Thus, embedding a Content-Security-Policy header in HTTP requests is also a good way to protect users’ browsers as it allows them to use only the server’s resources.
    Content Security Policies must be well configured as they can lead to other security vulnerabilities
    Another interesting header is the X-XSS-Protection which automatically filters out certain XSS attacks, it is enabled by default

    You can read all the OWASP recommendations on XSS vulnerabilities here: Cross Site Scripting Prevention – OWASP Cheat Sheet Series

    How to protect yourself from XSS with UBIKA Cloud Protector

    To protect a web application against XSS attacks, UBIKA Cloud Protector can do two things:

    Blacklisting is used at all protection levels:

    If UBIKA Cloud Protector detects a pattern usually used to exploit an XSS flaw, the request will be immediately blocked and redirected.

    The active “Scoring List” on the Advanced and High levels of protection:
    UBIKA Cloud Protector will analyse the request and increment a score according to the malicious patterns encountered.
    At the end of the analysis, if the score is higher than the authorised limit, the request is blocked and redirected.

Posted ago by Camila

Digital Marketing & Channel Manager @ Ubika