XSS for dummies

Today, we're going to take a look at the origin of one of the most common and exploited vulnerability on the Internet: The XSS also known as cross site scripting. If you are not familiar with web security, don't worry, I'll explain everything ! Let's get going !

How the web works

But before we explain what an XSS is, we need to understand how a web page works to get the basics.

Schema explaining how does the web works

Javascript and global XSS definition

In this introduction, I talked about javascript, a web language for adding dynamic functionality to a page. This is where our XSS attack comes in. To give a general definition :

The malicious code is then executed by the browser of the users visiting the page. This can enable the attacker to steal confidential information such as passwords, session cookies or even banking data. More on the impact later.

How a basic XSS injection works

XSS works on the principle of injection: an attacker provides an untrusted input to a program, which then executes it, inducing a malicious action. Injections are a common attack vector in cybersecurity, always top 3 in the OWASP top 10 (a standard awareness document for developers and Web application security).

There are 3 types of XSS:

1. Stored XSS,
2. Reflected XSS,
3. DOM-based XSS

We'll review each type, let's go !

Stored XSS

Let's imagine that you're behind your screen, using a website that let you post comments on articles.

If the site doesn't have sufficient protection against stored XSS attacks, an attacker can post a comment containing a malicious script that will be stored on the server (in the comments database, for example).

How stored XSS works

It occurs when an attacker manages to insert malicious code (usually in the form of a JavaScript script) into a Web page stored on the server, which is then executed on the browsers of users accessing the page.

Reflected XSS

Let's imagine that, once again, you're using a website that let you search for products by entering search terms in a search bar.

When you open the results page, your browser automatically executes the malicious script without you being aware of it.

How reflected XSS works

If you've understood correctly, you're probably thinking that this XSS requires user interaction to work, as it is not stored. And you're right. That's why attackers often use phishing with malicious links featuring reflected XSS to make the victim execute the payload.

DOM-Based XSS

Small disclaimer, it is the most complicated XSS to understand. But before talking about the XSS itself, a point on what the DOM is necessary.

What's DOM ?

Simply put, the DOM is a hierarchy of objects that represent HTML elements (e.g.<p>, <div>, <img> tags, etc.) and can be manipulated using methods and JavaScript properties.

DOM tree

Normally with this sentence you should start to understand where the vulnerability comes from.

Indeed, who says dynamic modification of the DOM with JavaScript says possibility of abusing these dynamic modifications.

When the user opens the web page, the malicious code is executed directly on the user's browser.

For example, if an HTML page contains this piece of vulnerable code:

<script>
    document.write(“Site is at:” + document.location.href + “.”);
</script>

An attacker can add the JavaScript code to the URL pointing to this vulnerable page.

#<script>alert(document.cookie)</script>

A pop-up is then displayed on the browser of the victim who will have carelessly clicked on this URL link.

How stored XSS works

Impacts

What can XSS be used for ?

• Executing arbitrary code on a victim's browser can enable an attacker to perform cookie theft (when cookies are not secure, attackers can steal them and use them to authenticate themselves as victims without needing to know their password).
• Keylogging (attackers can spy on victims and retrieve their keystrokes).
• Phishing (attackers can modify the appearance and behavior of the site, encouraging victims to send sensitive information to the attackers' servers).

Remediation

• Filter incoming data. When user input is received, filter as strictly as possible on the basis of what is expected or valid input.
• Encode data on exit (depending on the context). When user-controllable data is sent in HTTP responses, encode the output to prevent it from being interpreted as active content.
  • < converts to : &lt
  • > converts to : &gt
  • < converts to : \u003c
  • > becomes : \u003e
• Use appropriate response headers. To avoid XSS in HTTP responses that aren't supposed to contain HTML or JavaScript, you can use Content-Type and X-Content-Type-Options headers to ensure that browsers interpret responses as you intend.
• Content Security Policy (CSP) - is the last line of defense that can be used to mitigate the severity of XSS vulnerabilities that still occur. CSP allows you to control various elements, such as loading external scripts and executing inline scripts.
  To deploy CSP, you need to include an HTTP response header called "Content-Security-Policy" with a value containing your policy.

  
  An example of CSP is as follows:
  
  default-src 'self'; script-src 'self'; object-src 'none'; frame-src 'none'; base-uri 'none';
  
  This policy specifies that resources like images and scripts can only be loaded from the same origin as the main page. Therefore, even if a hacker manages to inject an XSS payload, they can only load resources from the current origin. This significantly reduces the chances of an attacker exploiting the XSS vulnerability.

How CSP works

Resources