XSS Polyglot

A polyglot is a person who speaks many languages. But the term matters also in contex of security issues.

Today, in from 0 to pentesting hero, about polyglots files that speed up the testing of web applications.

Let's consider a simple XSS attack - in other words, malicious code execution on our website.

It happens if displaying of data from the user is not handled properly by the programmer.

The data can be displayed on the site in various places - so-called contexts.

The easiest way to consider this is by example.

The content from the user can be displayed in the form. It is created using the input tag in HTML.

The displayed value is stored in the value attribute between double quotes.

So if the quotes are not converted into entities in the text coming from the user - the attacker will be able to close the value attribute and append his javascript code to it.

The simplest payload, which will test if the site is vulnerable, may look something like this.

"><script>alert(1);</script>

However, some programmers can use a single quote - which is still treated as a valid HTML code.

Then, we need to modify our payload - so that it closes the value attribute with a single quote.

As you can see, to test such a simple case on the page, we need two different paylods to test two different contexts.

But there can be a bunch of such potential contexts - that is, a lot of places where the programmer could made a mistake.

Hence, the so-called polyglots are used to save time.

These are special strings that have been specially prepared to work in many contexts simultaneously.

Let's look at the shortest polyglot competition page¹, with polyglots that are able to test up to 20 different contexts at once.

As you can see, for this string it doesn't matter if the tested string is going to be displayed between the title, script or iframe tags

In any case it will work the same - that is, it will display a simple window.

But XSS attacks are not the only area where polyglots can be useful.

SQL Injection is a situation when database query is not handled properly and allows for unexpected execution of any query by the user.

And here, just like in the forms - the input from the user can be enclosed between single or double quotes - usually in the context of the WHERE clause.

It can also be placed directly in the SELECT part - when we allow the user to display one specific column.

To test these 3 combinations - we would therefore need 3 different strings.

Thanks to polyglot - we can achieve the same by sending only one payload.

But there is nothing stopping you from creating a single polyglot that will look for XSS and SQL Injection errors at the same time².

The one shown here on the screen is also a valid PHP file that can execute any command that will be passed to it as an A parameter.

The idea of this kind of files is not only related to security.

There is a thread on Stack Exchange³ forum with a file that is properly supported by more than two hundred different programming languages.

Depending on the language in which we run the above-mentioned code, it will display the appropriate number - which will indicate the specific language used to run this code.

Impressive, isn't it? It is worth getting acquainted with the whole thread where users explain what tricks they used to fit that many languages into one piece of code.

The examples depend only on our imagination and good knowledge of the formats we want to connect with each other.

Let's take a look at the third edition of the Proof-of-Concept magazine⁴.

This file can be opened as pdf, zip, or jpg image - and each of these formats contains other data.

Most of the issues of this magazine are a real repository of knowledge.

Issue 13⁵ is a valid PDF/ZIP as well as PostScript.

Issue 12⁶ is a pdf, zip and an Android application.

Current browsers have more and more built-in mechanisms to protect against attacks.

One of such mechanisms is CSP - Content Security Policy, which allows site owners to define domains from which the scripts can be run by the browser.

This significantly impedes the XSS attack - this time, besides finding the vulnerability, we also need to find a way to pass the policy.

Typically, the creators of the site allow for execution of JS code from their own domain - which is obvious - because the owners control their code on the server.

Some of more creative attackers found a way to omit this restriction - most modern websites allow for sending a graphic file - for example our avatar.

This file is saved on a server that is accepted by the CSP policy.

So instead of the image, we send our javascript code - which allows you to bypass the policy.

That's why some websites check its correctness before saving the graphic file.

This time, they will not allow you to send any file with the jpg extension. or gif and will check exactly whether it is actually a photo.

And here polyglots will help us again. We can create a valid JPG file which at the same time will be a valid JS file.

The same applies to the .gif file, which is not as popular as it was a few years ago⁷.

The last curiosity that I would like to mention are the differences in parsing given formats depending on the software we use.

The names in the zip archive can be stored in at least three different places.

Different ZIP-opening software will show different names.

Depending on the tool we use, we can get different results on the same file.

For those who would like to explore this topic, I recommend presentation: Ten thousand pitfalls.

And that's all in today's episode. I encourage you to leave a comment and subscribe my channel.

See you in the next episode. Bye!

=TenThousandSecurityPitfalls_theZIPfileFormat.pdf