Guide: Cross-Site Scripting (XSS) Basic Exploitation Techniques – Part 1


This is not an advanced guide for the discovery and mitigation of Cross-Site Scripting (hereinafter XSS). It is just a beginner’s guide in XSS with the goal to mitigate common client side injection attacks. We will have a second post regarding advanced XSS attacks but for now we need to build from the ground up.
Of course, everything described below is for educational purposes only. Unauthorise acts of the following information are illegal.

Before we begin, we need to explain what actually an XSS attack really is. XSS is one of the most common client side code injection attacks in web applications. An attacker can execute arbitrary JavaScript (hereinafter JS) in order to change the functionalities of the legitimate site and run the malicious scripts into the victim’s browser.

Testing for XSS vulnerabilities can be a vast field. I really cannot describe how boundless is to test injection attacks. There are countless misconfigurations that can lead to an XSS but in this post we are going to try to enumerate only some common places where a vulnerability can occure.

First, lets get the most common misconfiguration out of the picture. As you probably know, if you can reflect valid tags into the application, you can execute arbitrary JS. For example, if you can pass the left tag “<” followed by a letter and then followed by the right tag “>”, then you have an XSS. A typical example can be like the following.


If the page does not use a proper way to encode the special characters, then the arbitrary JS will be successfully executed. But what is “proper encoding”? Well, lets start with this example:

For the following example the domain has a search parameter called “q”. During the test, the penetration tester is going to try if the parameter can encode special characters. So the request can be the following:


If the response page has the word “<test>” inside, then he can probably change the test to a script tag in order to execute JS. So the next request can be like this:


Then, in the response page the new tag will be a valid tag and allow the user to execute JS.

Hmm, thats great so far but how a developer can mitigate this issue. Many developers apply hotfixes which are not properly tested. Lets say on the example above, a developer can try to forbid to the user to actually submit the <script> tag. Specifically, he will create a blacklist which some “bad tags” and if the parameter has these tag, then the request is invalid. Thats a classic mistake and one of the best examples why the developers should NOT use blacklists instead of whitelists and/or encoding of the special characters.

But why its so bad to forbid only the “<script>”. In theory the tags will be invalid so the JS will be invalid as well. Well, not really because the tester is not bound to use only the script tag. For example the following:


Okay, good enough! But what if we blacklist tags as well. Lets say that from now on, when the user sends a value with the tag character, then the request will be invalid. In theory, the user cannot execute JS if he cannot add a new tag. Well, we are wrong again. In the parameter above, the input is being reflected into the HTML document but not as an attribute on an existing HTML tag. But what if the value of a parameter q is reflected inside an input tag. For example:

<input type="search" class="search" value="test" name="s" />

Well on this example, the tester can use the classic value escape like is for in the server side injections (SQL injections). Specifically, what if instead of sending test, he sends test” test=1. Then the results will be the following.

<input type="search" class="search" value="test" test=1 name="s" />

Great! But what the tester has managed to succeed? He managed to pass an invalid attribure. Okay, lets make it valid then.

The following attack is not some weird/sci-fi XSS attack. Actually, there is a name for this attack which is “XSS with Event Handlers”. The attacker uses the quote in order to break out from the value of the attribute. Then, he can create a valid event in and execute JS on this event. For example the tester can use the onmouseover event by sending test” onmouseover=alert(document.domain). The response page will be the following:

<input type="search" class="search" value="test" onmouseover=alert(document.domain) name="s" />

Then, when the victim hover the HTML object with the cursor, the arbitrary JS will be executed. Before we continue, I want to point out that there is a great list of some available events that you can use on the following site:

Of course, XSS cannot be only occured inside the HTML tags like <input> <div> <img> etc. etc. Many times, the parameter value is reflected inside the website’s JS. For example, the search parameter can be inside the following code:

var q="[parameter_value]";

An attacker can execute arbitrary JS by escaping the default double code escaping mechanism, closing the JS command with the ; and the writing arbitrary JS. For example:


As a result the response page will render the following:

var q="\\";alert(document.cookie);//";

So, what we have covered so far?

  1. We explained how a simple XSS attack is being executed.
  2. Why we need to find an alternative way instead of using blacklists.
  3. How does an “XSS with Event Handlers” work.
  4. How we can escape JS handlers in order to execute XSS.

Is that all? Of course not. We have just started to explain basic concepts here. Part two will be available soon..