The Most Famous Vulnerabilities - Cross-Site Scripting (XSS)
Jozsef Konnyu

The Most Famous Vulnerabilities - Cross-Site Scripting (XSS)

It’s been a while since I wrote the previous episode of my blog series. If you are interested in Remote Code Execution, then I definitely recommend reading the previous part.

So, here we are again, the moment has come for my final article about cross-site scripting (XSS).

What is Cross-Site Scripting (XSS)?

Usually, XSS vulnerability occurs when there are untreated inputs and bad cookie usage. So, please let me tell you about a case that happened in 2005 on Myspace.

A MySpace user found an XSS vulnerability on the site, and he wrote a payload called „Samy Worm.” This payload was a stored XSS, which was first uploaded by him on his own profile. When a user visited his infected profile, then the visitors saw the following text: „but most of all, Samy is my hero.” Meanwhile, the vulnerability was able to copy itself to the victim's profile and the infection of „Samy Worm” continue to spread without being stopped. The creator had found it funny until his house was surrounded by police and he was arrested.

And it wasn't even an extreme case because Samy had no serious intentions. But it raises the question, what kind of problems can be caused by exploiting such a vulnerability like XSS?

An attacker can easily inject an XSS payload through an untreated input like GET parameter in URL, or POST parameter as a form input if you didn’t sanitize angle brackets, single or double quotes and he can infect your HTML or Javascript code, for example, by using this classic payload : 

<script>alert(1)</script>

Single and double quotes can cause XSS vulnerability because these can influence the closing and opening of the expression.

Example for HTML:

<input type="text" name="username" value="john" onfocus=alert(1) autofocus "">

Example for Javascript:

<script>
var name = ’john’;alert(1);'';
</script>

If your website is vulnerable to XSS, this short javascript code will cause an alert pop up on your site. If this is running, it means that anyone can run any javascript code on your webpage. In most cases, these payloads run on the client side so you can rightly ask, why is it causing more trouble?

If an attacker can run any javascript on a vulnerable page, among other things, he can steal certain data about the user. It's a classic case when the site uses cookies in the wrong way. If the httpOnly flag is not used for cookies on your site, then it means these can be read on the client side. An attacker can steal session information from cookies with an XSS which can be given access an account.

Types of XSS

Last but not least it is also worth mentioning the types of XSS:

  1. Stored XSS (AKA Persistent or Type I): We'll talk about this type when the payload has been stored in a database on the server side. In practice, anyone can trigger this XSS under the right conditions. The MySpace worm in the example was this type of payload.
  2. Reflected XSS (AKA Non-Persistent or Type II): This type immediately runs on the victim’s site, but it won't be saved anywhere else. This type is not a serious case, but it can also cause surprises.
  3. DOM Based XSS (AKA Type-0): This type is a special case. This incident occurs when the payload can build itself into the DOM. In this case, XSS can manipulate the structure of the page without making any changes to the source, in terms of the server side.

How can you defend it?

Most of all, we have to pay attention to cookie handling. If we can, use the httpOnly flag to store confidential data (e.g., sessionID). If you are careful and do this it means that these cookies can’t be read with this flag on the client side.

And last but not least filtered the inputs. Pay attention to HTML tags, opening and closing signs.

How can BitNinja protect against it?

Our ultimate WAF solution with ModSecurity could be just what you need to solve all of your XSS problems. We have a whole set of rules to protect you against this vulnerability. Before you start turning all these rules, remember these are atomic and can cause false positive results if you turn them on when you’re on a badly written webpage. But if you are confident and you know what you are doing, then just go ahead. The Ninja has been with you :)


Need a little help to get familiar with our WAF? Check out our article serious about How to use BitNinja WAF (especially on WordPress but it contains useful information in general). Do you still have questions or need assistance? Contact our ninjas at info@bitninja.io



Did you miss the previous parts? Catch up now:

Share your ideas with us about this article

Previous posts

Manual Malware Scan – It's now available on the Dashboard
As a server owner, have you ever had an experience where one or more of the websites hosted by you were reported as a phishing website? Another common issue to get blacklisted on different lists or getting abuse reports which inform you that your servers are attacking other nodes. Perhaps this fact that we’re telling you isn’t new, which is the source of the outgoing attacks is an infection. A lot of hosting providers are frightened when they hear the word „malware,” and they have the reason for getting afraid. Malware is in the spotlight ELK Cloner was the very first malware (previou...
New security feature against phishing sites
Cybercriminals can easily attempt to break into shared hosting environments to use their resources for different types of attacks. Phishing is one of the most irritating forms, where the provider, the website owner and all of their visitors are affected. These attacks also highlight the responsibility of hosting providers, and that’s why we have just launched BitNinja’s new anti-phishing feature, to give a new weapon in your hands for fighting the hackers. Why phishing? Phishing is quite an old-school hacker technique, which seems to never go out of fashion. Since the technique simply...